crash in ni488.2 ibrd

[dgholstein]

I've written a LabView-callable DLL that calls the ibrd() function to retrieve 1601 complex points (X4) from an 8720, it works well from my 1.6 GHz Core 2 Duo laptop but crashes randomly from P4 machine running around 3 GHz.   How do I fix this?

   ...Dan

[Steven_T]

Hello dgholstein,

Is there a reason why you are not using the built in GPIB Reads or VISA Reads for your LabVIEW application?  They interface directly with the gpib-32.dll and also make a call to ibrd(). 

This Knowledgebas goes through many of the reasons why LabVIEW would crash because of a dll call. 

Let us know if you find the problem or if you are able to eliminate the possibility of one of these problems.

Steven T.

[dgholstein]

Yes, the reason I wrote my own in C is because I need speed and I need (freely available) scientific libraries for processing the data quickly.  Besides, LabView calls those same DLLs, why can't I do the same?

I did finally figure out why it is crashing (or more accurately, I figured out how to stop it from crashing).  This old programmer figured he'd be conservative and declared the buffers in global, when I moved the buffers to local variables, it stops crashing.  I understand modern OSes and compilers merely allocate new memory for local variables for every entry into a DLL (often putting that on the stack, too).  I learned this when making adjustments to my codes in order to make them reentrant.

I would hope I could re-use statically-declared global memory space as buffers, I can live with the (less-efficient) alternatives.  I hail from a time when CPU time and memory had value (and you'd actually look at compiler reports).

   ...Dan