Description of problem: Attempting to use valgrind with --db-attach=yes on a program that triggers an error, and then attaching gdb causes gdb to error, and is unusable. Once gdb exits, valgrind resumes control, and the program (seems to) continue normally. Version-Release number of selected component (if applicable): valgrind-3.3.0, GNU gdb Fedora (6.8-10.fc9) How reproducible: Every time Steps to Reproduce: 1. Create a program that causes valgrind to detect an error, such as an invalid read or write. The following example is sufficient #include <stdlib.h> int main() { int* arr = (int*)malloc(8); int j = arr[30]; return 0; } 2. Compile the example program (gcc -g3 -Wall val-db.c -o val-db) 3. Run valgrind with the following options "valgrind --db-attach=yes ./val-db" Actual results: GDB freaks out, and cannot debug. The following occurs on-screen: dragon ~/hackarea/val-db> valgrind --db-attach=yes ./val-db ==21247== Memcheck, a memory error detector. ==21247== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==21247== Using LibVEX rev 1804, a library for dynamic binary translation. ==21247== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==21247== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==21247== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==21247== For more details, rerun with: -v ==21247== ==21247== Invalid read of size 4 ==21247== at 0x4004EA: main (val-db.c:6) ==21247== Address 0x4c2f0a8 is not stack'd, malloc'd or (recently) free'd ==21247== ==21247== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y ==21247== starting debugger with cmd: /usr/bin/gdb -nw /proc/21248/fd/1014 21248 GNU gdb Fedora (6.8-10.fc9) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"... Attaching to program: /proc/21248/fd/1014, process 21248 Redelivering pending Segmentation fault. valgrind: m_signals.c:1154 (default_action): Assertion 'VG_(is_running_thread)(tid)' failed. Redelivering pending Segmentation fault. Program process 21248 exited: Unknown signal 0 (terminated) A program is being debugged already. Kill it? (y or n) n Program not killed. (gdb) bt Couldn't get registers: No such process. Couldn't get registers: No such process. (gdb) p j Couldn't get registers: No such process. (gdb) q The program is running. Quit anyway (and detach it)? (y or n) y ../../gdb/linux-nat.c:808: internal-error: iterate_over_lwps: Assertion `!is_lwp (inferior_ptid)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y ../../gdb/linux-nat.c:808: internal-error: iterate_over_lwps: Assertion `!is_lwp (inferior_ptid)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y ==21247== ==21247== Debugger has detached. Valgrind regains control. We continue. ==21247== ==21247== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1) ==21247== malloc/free: in use at exit: 8 bytes in 1 blocks. ==21247== malloc/free: 1 allocs, 0 frees, 8 bytes allocated. ==21247== For counts of detected errors, rerun with: -v ==21247== searching for pointers to 1 not-freed blocks. ==21247== checked 64,632 bytes. ==21247== ==21247== LEAK SUMMARY: ==21247== definitely lost: 8 bytes in 1 blocks. ==21247== possibly lost: 0 bytes in 0 blocks. ==21247== still reachable: 0 bytes in 0 blocks. ==21247== suppressed: 0 bytes in 0 blocks. ==21247== Rerun with --leak-check=full to see details of leaked memory. dragon ~/hackarea/val-db> Expected results: GDB attaches properly, and developer is able to debug the process. Additional info: Core dump attached
Created attachment 310735 [details] Core dump from GDB
This is from analysis of core file in the similar situation: Loaded symbols for /lib/libthread_db-1.0.so Core was generated by `/usr/bin/gdb -nw /proc/14930/fd/1014 14930'. Program terminated with signal 6, Aborted. [New process 14931] #0 0x00110416 in __kernel_vsyscall () (gdb) thread apply all backtrace Thread 1 (process 14931): #0 0x00110416 in __kernel_vsyscall () #1 0x0046a660 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0046c028 in abort () at abort.c:88 #3 0x080880fd in internal_vproblem (problem=0x83539c0, file=0x8271e40 "../../gdb/linux-nat.c", line=<value optimized out>, fmt=0x8269c6b "%s: Assertion `%s' failed.", ap=0xbfe1b5dc "�3'\b�\036'\b�P\204\b\b���F�J") at ../../gdb/utils.c:783 #4 0x08085323 in internal_verror (file=0x8271e40 "../../gdb/linux-nat.c", line=808, fmt=0x8269c6b "%s: Assertion `%s' failed.", ap=0xbfe1b5dc "�3'\b�\036'\b�P\204\b\b���F�J") at ../../gdb/utils.c:798 #5 0x08085356 in internal_error (file=0x8271e40 "../../gdb/linux-nat.c", line=808, string=0x8269c6b "%s: Assertion `%s' failed.") at ../../gdb/utils.c:807 #6 0x0809fa0f in iterate_over_lwps (callback=0x809f0b0 <kill_callback>, data=0x0) at ../../gdb/linux-nat.c:808 #7 0x0809fa50 in linux_nat_kill () at ../../gdb/linux-nat.c:2668 #8 0x0814c713 in target_preopen (from_tty=1) at ../../gdb/target.c:1686 #9 0x08097fe7 in core_open (filename=0xbfe1d3d1 "14930", from_tty=1) at ../../gdb/corelow.c:319 #10 0x0812f192 in catch_command_errors ( command=0x80822a0 <core_file_command>, arg=0xbfe1d3d1 "14930", from_tty=1, mask=6) at ../../gdb/exceptions.c:528 #11 0x0807c457 in captured_main (data=0xbfe1b8d4) at ../../gdb/main.c:760 #12 0x0812f22b in catch_errors (func=0x807b940 <captured_main>, func_args=0xbfe1b8d4, errstring=0x8273c84 "", mask=6) at ../../gdb/exceptions.c:513 #13 0x0807b8f1 in gdb_main (args=0xbfe1b8d4) at ../../gdb/main.c:893 #14 0x0807b8b5 in main (argc=Cannot access memory at address 0x3a53 ) at ../../gdb/gdb.c:33 (gdb)
* Thu Jul 24 2008 Jan Kratochvil <jan.kratochvil> - 6.8-12 - Temporarily disable attaching to a stopped process (BZ 453688) - To be reintroduced after a fix of the kernel BZ 454404. It has now the behavior of upstream gdb-6.8. After the Bug 454404 fix a modified patch needs to be introduced to fix the stopped processes attachment (and related pending signals being lost now).
gdb-6.8-12.fc9 has been submitted as an update for Fedora 9
GDB can now be used from within valgrind without crashing, and some debugging (inspecting variables, doing some assignments) works correctly. However, functions can't be called, and this immediately raises a SIGSTOP. Unless I am mistaken, calling functions from gdb inside valgrind was acceptable in Fedora 8 and earlier. I believe that this behaviour is a result of bug #454404 not being fixed yet.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.