LV memory corruption when data is passed to a subvi

[m3nth]

I am passing a string to a subvi which at times (1 time in 20 perhaps) is being corrupted. Specifically (the last time it happened), I had a control set to "127.0.0.1" on the front panel of the main.vi. When that value is passed to a control on a subvi, it appears as "127.0.0. " on the subvi front panel, with a corresponding number of spaces for data that is missing. This has happened with other things as well, part of the hostname is blanked out and then an error is returned that cannot be resolved, when it should have been www.1234567890.com I am wondering if anyone has seen symptoms of this before or perhaps what this type of corruption is indicative of.

To further characterize the beha
vior, it doesn't happen most of the time, but when it does happen, it is repeatable. Meaning, that if I don't close anything or change the configuration of anything, I can run the program over and over to reduplicate the error. If I close stuff or restart LabVIEW or something like that though the problem will go away till I see it again.

The program this is part of does involve low level calls to winsock functions which is why I'm wondering if I'm doing something wrong... however, all functions appear to be operating normally.

Would it be possible to corrupt data in between the main.vi and when it gets passed to the subvi, by having previously called a low level function in a bad way?

[Greg_McKaskle2]

>
> The program this is part of does involve low level calls to winsock
> functions which is why I'm wondering if I'm doing something wrong...
> however, all functions appear to be operating normally.
>
> Would it be possible to corrupt data in between the main.vi and when
> it gets passed to the subvi, by having previously called a low level
> function in a bad way?

Yes, it is possible. Most common is passing a string of size M to a DLL
that treats it as if it has N bytes allocated. No problem if M >= N,
but when M < N, the C DLL can crash or corrupt memory leading to a later
crash or incorrect result. One of the problems that makes this
difficult to track down is that it is often dependent on the calling
parameters and will work fine until the r
ight data set provokes the bug.

It is also possible that LV has made a mistake and isn't protecting a
buffer from the C code or that you have more than one thread calling
into a nonreentrant DLL as if it were reentrant. If you believe this to
be the case, try making the DLL be marked as nonreentrant, and if it
comes to it, please include the version of LV with any bug reports you
need to make.

Greg McKaskle

[Nirmal_Sharma]

Hi,

Happy New Year!!!

I am attaching 2 vi where main vi passes a string to sub vi. Here I am getting the right string in the sub vi. I have tried it 20 times also.

You try this. Still if you face the same problem, attach your vi.

Regards,
Nirmal

[Nirmal_Sharma]

Hi,

Happy New Year!!!

I am attaching 2 vi where main vi passes a string to sub vi. Here I am getting the right string in the sub vi. I have tried it 20 times also.

You try this. Still if you face the same problem, attach your vi.

Regards,
Nirmal