- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In my release version, I get an access violation but instead of any stack I get 'Stack trace terminated abnormally'. How do I fix the stack trace so I can find the problem?
Including a couple extra flags I turned on trying to improve feedback (which didn't affect behavior) my compile command is:
/nologo /Zi /Ob0 /G5 /QaxT /assume:buffered_io /include:"Release/" /debug-parameters:all /iface:cvf /module:"Release/" /object:"Release/" /traceback /check:all /libs:qwin /c
The debug version runs correctly on the test case using:
/nologo /Zi /Od /include:"Debug/" /warn:all /debug-parameters:all /Qauto /fpe:0 /iface:cvf /module:"Debug/" /object:"Debug/" /asmattr:source /asmfile:"Debug/" /traceback /check:bounds /libs:qwin /c
It isn't my code andthere are 865 files of F77 full of COMMON and EQUIVALENCE, so manual methods probably aren't an option.
Thanks,
Art
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Stack tracing isn't guaranteed to succeed or to reveal anything useful.
In switching configurations make sure that frame pointers stay on. You
know that you can debug a release configuration?
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I notice that you don't have the same switches between the DEBUG and RELEASE versions,
most notably Qauto and fpe:0 (missing in the release) but that the release version has
assume:buffered_io.
What happens if they all match?
- Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you mean I'm barking up the wrong tree by trying to 'fix' the stack trace, and that Ineed togo print out the IDB manual if I want to get useful information?
I'm sure you can debug the release version, but I was hoping not to get that far from my comfort zone. Oh well, how different can it be from the Matlab debugger ;-)
Thanks,
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can't 'fix' a track trace that you never got. The pros and pitfalls of traceback are very clearly and succinctly explained in the IVF .chm help (specifically, Tradeoffs and Restrictions in Using Traceback). An access violation is the kiss of death for a Windows app and it might be tricky to pinpoint the cause. Use the MS debugger (NOT idb) to debug by setting Fortran debug to Full and the linker debug to Yes no matter what the version. Debug F5 and continue until your program fails. You still wont get a traceback but you'll now have some idea as to where your program bombed. It's reallysimple, honestly.
Gerry

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page