Bug 453688 - Valgrind doesn't work with GDB properly
Valgrind doesn't work with GDB properly
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
:
Depends On: 454404
Blocks: 483262
  Show dependency treegraph
 
Reported: 2008-07-01 18:57 EDT by Alex Chernyakhovsky
Modified: 2009-07-15 04:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 483262 (view as bug list)
Environment:
Last Closed: 2009-07-15 04:15:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Core dump from GDB (1.42 MB, application/octet-stream)
2008-07-01 18:57 EDT, Alex Chernyakhovsky
no flags Details

  None (edit)
Description Alex Chernyakhovsky 2008-07-01 18:57:58 EDT
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
Comment 1 Alex Chernyakhovsky 2008-07-01 18:57:58 EDT
Created attachment 310735 [details]
Core dump from GDB
Comment 2 Matěj Cepl 2008-07-02 12:33:55 EDT
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) 
Comment 3 Jan Kratochvil 2008-07-24 02:36:58 EDT
* Thu Jul 24 2008 Jan Kratochvil <jan.kratochvil@redhat.com> - 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).
Comment 4 Fedora Update System 2008-07-24 02:48:27 EDT
gdb-6.8-12.fc9 has been submitted as an update for Fedora 9
Comment 5 Alex Chernyakhovsky 2008-08-13 10:50:03 EDT
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.
Comment 6 Bug Zapper 2009-06-09 21:52:32 EDT
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
Comment 7 Bug Zapper 2009-07-15 04:15:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.