LV 2012 crash during finite pulse generation (integer divide by zero)

[OriginalP]

LabVIEW randomly crashes during finite pulse generation with X-series board (PCI-e 6320) under Windows 7 64 bit and LV 2012 SP1 f3 32-bit.

Exception: Integer divide by zero (0xC0000094) at EIP=0x09F11544 (see attached image)

Do anyone encounter this error?

I can attach source code, but the project is very large. I'm trying to reproduce crash with a smaller program.

[OriginalP]

Crash also generates a dump of memory (file .dmp) but i am not able to debug this information.

Finite pulse generation subVI

Init pulse generation subVI with DAQmx Task Start

[OriginalP]

I discovered that if I provide the data to the counter in a static way the crash does not occur

[OriginalP]

I thought I had found a workaround, generating pulse trains once at program start, storing them in multiple global variables and then selecting the right global variable on demand. So a static way to supply data seemed to be the key, since no labview crash appeared with two ouput counters. But i have just added the third ouput counter and now the crash occurs again.

Every idea is welcome. Thanks

[Kevin_Price]

Just bouncing over here from your other thread.  I've got a suspicion that the problem you reported there is at least part of what's causing your trouble here.  The fact you can make this code work when you have valid constant values for your pulse params, but gives you errors when wiring dynamiclly calc'ed/manipulated values suggests that the data within those pulse params is to blame.  

I'm not sure how the pulse params get calc'ed, but you may need to guard against other invalid pulse param values like Inf, NaN, and negative numbers as well as guarding against zeros.

-Kevin P

[OriginalP]

Thank you again for the answer, your advices are welcome!
I will check how pulse train data are generated with more attention.

At the moment, this is the way frequencies are calculated:

[Kevin_Price]

Just from the visible parameter values and function calls that affect the inputs to your freq calculation, I can see several scenarios that could lead to "bad" freqs.  The 1/x function is unbounded if x approaches 0 and produces a 0 frequency if x approaches infinity.  The acos function is undefined if its argument goes outside of [-1,1] and it sure looks like it will.   Just look what happens when A is as small as 5 steps.  i is going to iterate from 0 to 5.  The acos() argument will go from 0 to -2*i/(A+1).  The last iteration when i==A==5 will result in an acos() argument of -10/6, well outside the legal bounds.    

I can't say for sure that cleaning up the calcs to prevent all possibility of illegal function arguments will solve your crash problem.  But I wouldn't spend a lot of time hunting for other causes until *after* guarding your calcs against illegal inputs.  You need to do it anyway, and it might clear up the crash.

-Kevin P

[OriginalP]

Surely I have to improve the validation of input data, but no crash has occurred since I use the "round to nearest" function and "to long integer" function before for loop iteration. Fingers crossed.

Btw, thank you very much for your advices