Debug / Release libraries

[nick_jakeman]

Has anyone else experienced the problem where the Debug version of a static library functions absolutely fine, but the Release version generates run-time errors?

Nick Jakeman

[nijhuis]

That is a problem as old as the debugging mode exists. You should be aware of the fact that the compiled code is not the same in Debug mode and Release mode.

A well-known cause of such a problem is the exceeding of array bounds. It can happen that inDebug mode a memory address is overwritten which holds for example a program instruction, while with the same incorrect array bound inRelease mode an address is overwritten,which does no harm at that moment.

I think there are surely other causes of different actions inboth modes.

If not set yet: enable array bounds checking for the Debug mode.

In many cases this will show you the problem while executing the program in Debug mode.

Guus

[lklawrie1]

Yes, I'm having this problem (IVF) right now but it's not array bounds. Most of my developers are using CVF. I had neglected to do "/fpe:0" with my port to IVF but it shows a lot of files not running whereas the debug (IVF) runs them fine as does CVF.

How far do we have to match the compilation parameters to assure a decent trip up in debug version (as I have turned off all debug in the release version and it shows nothing but "float invalid")

Linda

[nijhuis]

Linda,

I'm afraid I can't help you at this moment. The only thing I want to make clear is, that it is not so surprising that Release mode fails while Debug mode runs well and the reverse also. Often it is an intensive search to locate such a problem, when it it not related to array bound errors.

Some causes I remember are: argument mismatches and overwriting a constant value by passing it to a subroutine and give it an other value within the routine. But , I assume there are much more causes for errors.

Guus

[aliho]

Check particularly fixed length character arguments to ensure that the length in the call instruction is equal to the declared length.

CHARACTER*20 STRING

CALL DUMMY(STRING)

.....

SUBROUTINE DUMMMY(STRING)

CHARACTER*80 STRING

STRING=" "
END SUBROUTINE

[lklawrie1]

I thought I would try working backwards from the one that fails, gradually adding more debug information to get at the real spot.

Adding "lines" -- still fails, but no traceback.

"Full" -- now it works.

Steve, how can I trace this as there is a crash that was missed in my "normal" one w/o debug but added more crashes. The 'release' version with full debug crashes on the appropriate ones but doesn't give me any line information (optimization is still on...)

Linda

[Steven_L_Intel1]

Linda,

Traceback is a separate option.

Are you sayijng that simply changing the debug level changes the operation of the program? That shouldn't happen. I'd ask that you report this to Premier Support and attach a reproducible example. We'd like to look at it.

[lklawrie1]

Steve, You will remember this is a "big" program, yes? I don't believe I can "dumb" it down to just where it is crashing as I can't seem to determine where that is!

Yes, changing my "release" version from no debug to lines to full changed it from crashing on 1 input file to running (which it should have done, according to other compilers and the full debug version of IVF).

Linda

[Steven_L_Intel1]

Try selectively changing the debug level on certain files. You may find that you can identify one source file which, when the debug level is changed, changes the behavioir. Full debug does sometimes change the generated code. You should also be able to enable traceback independently.

[lklawrie1]

That would be a lot of source files.....

Issue submitted.

Linda

[lklawrie1]

Traceback, which I believe I have enabled, does not give me any information. Do I need more than the exe on the target machine to have the traceback? (i.e. Map file, pdb file?)

Linda

[lklawrie1]

I did not have traceback enabled -- trying that now with the "lines" option which was crashing previously.

Linda