How to identify the FATAL RUN TIME ERROR in release mode

[Joesam]

How we can know where the error happened if the application is running in Release mode?
For example, I am getting an error at one instane as follows.
"FATAL RUN-TIME ERROR: Unknown source position, thread id 0x00000124, function id 1: The program has caused a 'General Protection' fault at 001B:004EEA2A."
How I will go to the appropriate line of code where the error occurs.
I cannot run the debug mode and see it because it will take alomost a day for it.
In Microsoft Visual C++, there is an option in "Settings" to log the errors in to a log file.
In LabWindows, is there any options like that?
Please let me know about it

Joesam

[Wendy L]

Hello Joesam,

You can create a map file for your application by going to Build >> Target Settings and selecting Generate Map File. This map lists the address of every function and variable and the name of the function or variable. This option is useful if your program crashes and provides an address where the failure occurred. You can view the map file to check which function or variable the crash occurred in.

Refer to your post here.

Thanks.

[WGutsche]

Hallo,

I have got the same problem. I had build the mapfile an now I know the function where the error occurse.

The Address of my function is 0x00449964 and the Adress of the error is 0x00449ad7.

There is a differenz of 173 bytes.

Is it possible to locate with this information the exact line of code in my function where the error occurse?

With best regards

Wolfgang

[NicoLeach]

You can use a disassembler (open watcom's one for example) to disassemble the .niobj file that contains the faulty function.
Using the offset of 173 bytes, find the error in the asm/lst file generate.
Match the asm and the C code. (thats the hard part).

You need of course the obj and the c file used to build the exe that crashed.

Best regards,
Nicolas

[LuisG]

Wolfgang,

If the crash happens every time, and always at the same address, but only in release mode, the fastest way for you to find the crash, is probably to sprinkly some logging messages throughout your function. That way you can very quickly find the line that is causing the crash. (If you use fprintf, remember to call fflush after each message, or your program might crash before the contents of the io buffer are synced with the file).

Luis

[WGutsche]

Hello.

Thanks for your tips.

I have decided to use the watcom disassembler - wdis. You find all needed information in the "Tools User's Guide Help". Search for Disassembler. The -s option doesn't work, perhaps there are no line numbering information in the niobj-file.

Wolfgang