??Compiler error. bad dsoffset, dso=-1

[MartinLiu]

After I finished the Subvi program, I wanted to save the program. When I clicked the 'save' in the file menu, the following imformation appeard"Compiler error. Report the problem to NI Tech Support. bad dsoffset,dso=-1". I do not know what it means exactly.

[mikeporter]

Don't feel bad, they probibly don't know what it means either...

Seriously though, if you go through the same steps and the problem doesn't reoccur the system was probibly just suffering from some sort of glitch.

If it happens everytime you try and build certain functionality try doing the locically identical operation in a different way and see if you can get the problem go away.

If it happens with some frequency, but not every time, try and keep track of what your were doing when the error occurred. For example, were certain programs open at the time? Had you just finished certain operations? Does it happen at a particular time of day? If you try to build the subvi with nothing open but the subvi do you get the same error?

And don't forget the
standard support question:

"Has it always done this? If not, what has changed on your computer?"

Sorry I can't give specifics but these types of problems can be a pain to troubleshoot. Unfortunately if you can't get the problem to occur repeatedly you will be the only one troubleshooting it...

Mike...

[Kenneth]

This problem can be duplicated with a TCP Write VI and not wiring the 'Data In' terminal.  Terminal is recommended.

Following up on this specific instance with Tech Support.  This is repeatable.

[Eli_S]

MartinLiu,

As mentioned above, it is really hard for us (if not impossible) to troubleshoot something if it cannot be repdroduced. Does this happen everytime you try to save or did it happen only once. If it something that can be repdroduced, can you post the VI that is causing this?

Also, what version of LabVIEW are you using?

[Kenneth]

As the original posting was in 2002, when MartinLiu posted the problem originally, s/he was using version 7.x

I added to the posting as it seems there is some assertion in LabVIEW that results in an internal error that needs history of documentation. I added to the existing thread rather that start a new thread.  I submitted a service request for the issue with code that isolated the behavior.

I was teaching the LabVIEW Intermediates II class using LabVIEW 8.5.  It was not repeatable with just the TCP Write function.  The exercise demonstrates an FTP operation where any file is passed over TCP/IP via chunks.  The exercise included additional code to calculate the number of chunks based on the selected file size and a chunkiness size.  When the number of chunks is calculated, LV coerces the integers to doubles for the division, rounds to the largest integer, and sends that value to a for loop (to send each chunk) and to the TCP receiver. 

The combination of the unwired terminal and the coercion indicated a the compiler error.
As for repeatability, it happens the first time the wires are disconnected consistently.

Regards,
Kenneth

[Ya-hoo]

This doesn't often happen to me but it happened quite a few times when I loaded my cRIO application code. I have PC application and cRIO application code in one project, I could load the PC code but not cRIO code. Once this happened, I have to abort labVIEW from Task Manager.

[Ya-hoo]

Got message when I relaunch labVIEW "The last time you ran LabVIEW, an internal error or crash occurred at clumper.cpp, line 411."

[Ya-hoo]

More comments on this issue.

If I load cRIO code first, it can be loaded without error but I'll get broken PC code which says Invoke Node contains unwired terminal; if I load PC code first, it's loaded properly and no broken vi but get dso=-1 error when load cRIO code.