When valgrind finds an error by hooking into a system call (such as when memcheck detects an invalid free(), or when halgrind detects a potential deadlock), GDB generates a broken stack trace. I suppose this is because it doesn't have sufficient debug info for helgrind's overriding function, which is on the top of the stack. I'm using 3.3.0 on Ubuntu Gutsy x86_64, compiled with default options (except --prefix)
Created attachment 23620 [details] Script that reproduces the problem for me. This gives the following output; note that the second GDB invocation has a broken backtrace: ==25197== Memcheck, a memory error detector. ==25197== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==25197== Using LibVEX rev 1804, a library for dynamic binary translation. ==25197== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==25197== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==25197== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==25197== For more details, rerun with: -v ==25197== ==25197== Invalid write of size 1 ==25197== at 0x40050B: foo (foo.c:7) ==25197== by 0x400526: main (foo.c:13) ==25197== Address 0x5181030 is 0 bytes inside a block of size 1 free'd ==25197== at 0x4C21B2E: free (vg_replace_malloc.c:323) ==25197== by 0x400506: foo (foo.c:5) ==25197== by 0x400526: main (foo.c:13) ==25197== ==25197== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==25197== starting debugger with cmd: gdb -x gdb-cmd --batch /proc/25198/fd/1014 25198 Using host libthread_db library "/lib/libthread_db.so.1". 0x000000000040050b in foo () at foo.c:7 7 *p = 0; #0 0x000000000040050b in foo () at foo.c:7 #1 0x0000000000400527 in main () at foo.c:13 $1 = (void *) 0x7ff000480 $2 = (void *) 0x7ff000490 0x7ff000478: 0x0000000000400507 0x0000000000400540 0x7ff000488: 0x0000000005181030 0x00000007ff0004a0 0x7ff000498: 0x0000000000400527 0x0000000000000000 0x7ff0004a8: 0x0000000004e43b44 0x0000000000400430 0x7ff0004b8: 0x00000007ff000588 0x0000000100000000 0x7ff0004c8: 0x0000000000400519 0x000000000421cc00 0x7ff0004d8: 0x1fbcf06cc199fe14 0x0000000000000000 0x7ff0004e8: 0x00000007ff000580 0x0000000000000000 0x7ff0004f8: 0x0000000000000000 0x1fb30e6cc8f9fe14 0x7ff000508: 0x1fbcf9a4b467fe14 0x0000000000000000 0x7ff000518: 0x0000000000000000 0x0000000000000000 0x7ff000528: 0x0000000000400540 0x00000007ff000588 0x7ff000538: 0x0000000000000001 0x0000000000000000 0x7ff000548: 0x0000000000000000 0x0000000000400430 0x7ff000558: 0x00000007ff000580 0x0000000000000000 0x7ff000568: 0x0000000000400459 0x00000007ff000578 ==25197== ==25197== Debugger has detached. Valgrind regains control. We continue. ==25197== ==25197== Invalid free() / delete / delete[] ==25197== at 0x4C21B2E: free (vg_replace_malloc.c:323) ==25197== by 0x400516: foo (foo.c:9) ==25197== by 0x400526: main (foo.c:13) ==25197== Address 0x5181030 is 0 bytes inside a block of size 1 free'd ==25197== at 0x4C21B2E: free (vg_replace_malloc.c:323) ==25197== by 0x400506: foo (foo.c:5) ==25197== by 0x400526: main (foo.c:13) ==25197== ==25197== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==25197== starting debugger with cmd: gdb -x gdb-cmd --batch /proc/25203/fd/1014 25203 Using host libthread_db library "/lib/libthread_db.so.1". 0x0000000004c21b2e in _start () from /lib64/ld-linux-x86-64.so.2 #0 0x0000000004c21b2e in _start () from /lib64/ld-linux-x86-64.so.2 #1 0x0000000000001102 in ?? () #2 0x0000000038002500 in ?? () #3 0x0000000005181030 in ?? () #4 0x0000000000000000 in ?? () $1 = (void *) 0x7ff000420 $2 = (void *) 0x7ff000470 0x7ff000418: 0x000000000421cc00 0x0000000000001102 0x7ff000428: 0x0000000038002500 0x0000000005181030 0x7ff000438: 0x0000000000000000 0x0000000000000000 0x7ff000448: 0x0000000000000000 0x0000000005181030 0x7ff000458: 0x0000000000000001 0x000000000400e1a0 0x7ff000468: 0x000000000421cc00 0x00000007ff000490 0x7ff000478: 0x0000000000400517 0x0000000000400540 0x7ff000488: 0x0000000005181030 0x00000007ff0004a0 0x7ff000498: 0x0000000000400527 0x0000000000000000 0x7ff0004a8: 0x0000000004e43b44 0x0000000000400430 0x7ff0004b8: 0x00000007ff000588 0x0000000100000000 0x7ff0004c8: 0x0000000000400519 0x000000000421cc00 0x7ff0004d8: 0x1fbcf06cc199fe14 0x0000000000000000 0x7ff0004e8: 0x00000007ff000580 0x0000000000000000 0x7ff0004f8: 0x0000000000000000 0x1fb30e6cc8f9fe14 0x7ff000508: 0x1fbcf9a4b467fe14 0x0000000000000000 ==25197== ==25197== Debugger has detached. Valgrind regains control. We continue. ==25197== ==25197== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 8 from 1) ==25197== malloc/free: in use at exit: 0 bytes in 0 blocks. ==25197== malloc/free: 1 allocs, 2 frees, 1 bytes allocated. ==25197== For counts of detected errors, rerun with: -v ==25197== All heap blocks were freed -- no leaks are possible. x86_64 gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) GNU gdb 6.6-debian valgrind-3.3.0
I can't reproduce this on openSUSE 11.0 running V svn trunk. For the second gdb-attach, I get the following stack: (gdb) where #0 0x0000000004c2464f in ?? () #1 0x0000000000001102 in ?? () from /lib64/ld-linux-x86-64.so.2 #2 0x000000000040059b in foo () at foo.c:8 #3 0x00000000004005ab in main () at foo.c:12 so at least there are source locations inside foo.c.
Given the age and lack of reproducibility, I will close this.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!