Why does my test application quit (disappear) during testing?

[Robert_Mensah]

Hello,

I wrote test application using CVI2009 under WinXP. The application runs fine but when I repeat test, the application quits around the 9th or 10th repeat. When I reload and run the application it would quit again around the 9th or 10th repeat. I do not have a clue of what is going on. I have attached error logs A80428Error.bmp and A80428ErrorLog.bmp. Would someone please help?

Than you.

Robert Mensah

[ebalci]

Hi Robert,

This Windows crash window appears when your code performs an invalid operation.

Did you try running the debug version of your application?

Try running it from within the CVI editor.

I believe you will get a runtime error at the point your app crashes and you may see which part of your code was executing when it does. 

[RobertoBozzolo]

Hello Robert,

a couple of hints on your problem :

1. Are you shure the system you are running on is stable? In the event viewer screenshot you have posted  I noticed *a lot* of Application hang errors on several different programs (cvi.exe -which by the way appears to be release 8.51- , explorer.exe, your app, NI Example finder and so on. Maybe you should reconsider reinstalling the system and see if this fixes some of the errors

2. Did you happen to develop your application in CVI 2009 evaluation version? If so, keep in mind that every executable built in eval versions will hang after approx. 10 minutes running (more or less the difference between records on 3/3/2010 12:03 and 3/3/2010 12:14 in system log)

3. If none of the above applies, you could recompile the application checking "Generate map file" checkbox in Build >> Target settings panel: this will generate a report inside cvibuild directory with mappings for all function calls inside your application. By searching the fault address shown in the error log inside the map file, you can narrow down the faulty condition to some specific function in your program

Message Edited by Roberto Bozzolo on 03-05-2010 09:34 AM

[Robert_Mensah]

Hello,

When I ran my application in editor (or debug) mode, the error I got was "An attempt to write beyond end of string. Need more than 1024 bytes".

The string in question that was highlighted was the array "msg".  In my code I have it defined as    char msg[1024]={"\0"};

To avoid this error I doubled the size of the array to   char msg[2048]={"\0"};   which seems to work.

One other question I have is how do I empty the content of the array  "msg" in the middle of my code? Would "memset(msg, NULL, 2048);" work?

Also, if one defines the input queue size of serial port to = 512 bytes  and output queue size to = 512 bytes, is it possible to read data more than 700 bytes from the serial output port? In other words in the function  BytesRead=ComRd(COM1, ReadBuffer, StringLength); if output queue size is 512 can BytesRead be more that 512?

Thank you.

Robert Mensah

[ebalci · Accepted solution]

If you see the control panel help of "Input Queue Size" on OpenComConfig function panel, you will see an explanation about this.

Microsoft serial driver imposes a minimum 4096 bytes for the input queue.

So even if you specify 512 you get 4096.

That is why you can have more than 512 bytes in your input queue.

Hope this helps, 

[RobertoBozzolo]

Hi Robert, regarding the first question in your post, using memset will effectively fill the entire string with null bytes thus deleting all prior content but if you are not likely to fill your buffer with non-null-terminated strings a simple strcpy (msg, ""); may be enough to let all string-oriented functions consider the buffer as empty.

[ebalci]

This sentence from Roberto's post is important: "...if you are not likely to fill your buffer with non-null-terminated strings a simple strcpy may be enough..."

Beware that, C searches for a null byte to decide the end of a string.

If you use strcpy (msg, "") you will see an empty string as its value as you put a null at the 0th position the char array..

But, if another function like ComRd or ComRdTerm overwrites this null at the 0th position and if you do not appended a null after the meaningful part of the data you will see some unexpected bytes after your real data.

You should track the number of bytes you write into the string and append a null at the appropriate position yourself.

This problem shows itself only if you display the string. If you process it internal to your code and know what you are doing, everything is OK.

[Robert_Mensah]

Thanks very much Ebalci and Roberto. That answers my questions.

Robert Mensah