Only hex traceback/callstack for glibc runtime error

[fa_framatome-anp]

Hello,
I get a glibc error at runtime but the traceback is only in hex. And idbreportsthe error but from the callstack I can also not determine where the error occurs in the code. Do you have any hints how I can determine the location of the code which triggers the glibc error ?
I'm using ifort 11.0.074 on RedHat 5 (x86-64) with glibc 2.5-24.el5_2.2
The compiling options include "-g -debug extend -traceback".

Thanks,
H.W.

At runtimeI get:
*** glibc detected *** /project/artemis/main/artemis/x86_64-linux.intf-gnuc.debug/artemis_exe: double free or
corruption (!prev): 0x000000002ef01d20 ***
======= Backtrace: =========
[0x331386e]
[0x3317f57]
[0x3273abb]
[0x1e03db9]
[0x1e03c96]
[0x17e4b99]
[0x152de4f]
[0x412133]
[0x44594d]
[0x5a6079]
[0x4bb7c1]
[0x406d37]
[0x402054]
[0x40031c]
[0x32e8460]
[0x4001e9]
======= Memory map: ========
00400000-03fd0000 r-xp 00000000 68:11 58589352 /vol1/vstore/bol_rc1/.s/00025/800022b
...

In idb the callstack is only:
0x00000000032f0dcf in abort () in /vol1/vstore/bol_rc1/.s/00025/800022bd499e697cartemis_exe
0xffffffffffffffff

[TimP]

If you applied -g in the compilation of all your functions in the call stack, and also in the link step, you should get better information than this. It's worth while to try gdb in case it helps you more than idb. You might also attempt with -static link.
When people say RedHat 5, it often means they have 5.0, which is definitely deficient compared to current versions, even though the glibc version hasn't changed. I haven't seen a glibc for this built with -g enabled, unfortunately.

[Ron_Green]

the key point to Tim's reply, you must compile AND link with -g -traceback. Use ifort as your linker.

ron

[fa_framatome-anp]

I did not use the -g -traceback for linking.
But adding this did not solve the problem, since I still got no readable traceback.
And I am using ifort as linker and building a static executable.

ButI finally was able toget sufficient information aftersetting the MALLOC_CHECK_=1 env variable.

Thanksfor the feedback which finally lead me to the solution.

H.W.