Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 453688

Summary: Valgrind doesn't work with GDB properly
Product: [Fedora] Fedora Reporter: Alex Chernyakhovsky <achernya>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: mcepl, mcepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 483262 (view as bug list) Environment:
Last Closed: 2009-07-15 08:15:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 454404    
Bug Blocks: 483262    
Description Flags
Core dump from GDB none

Description Alex Chernyakhovsky 2008-07-01 22:57:58 UTC
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):
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>

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== 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== ---- 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 <>
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== Debugger has detached.  Valgrind regains control.  We continue.
==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== 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 22:57:58 UTC
Created attachment 310735 [details]
Core dump from GDB

Comment 2 Matěj Cepl 2008-07-02 16:33:55 UTC
This is from analysis of core file in the similar situation:

Loaded symbols for /lib/
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

Comment 3 Jan Kratochvil 2008-07-24 06:36:58 UTC
* Thu Jul 24 2008 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).

Comment 4 Fedora Update System 2008-07-24 06:48:27 UTC
gdb-6.8-12.fc9 has been submitted as an update for Fedora 9

Comment 5 Alex Chernyakhovsky 2008-08-13 14:50:03 UTC
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-10 01:52:32 UTC
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:

Comment 7 Bug Zapper 2009-07-15 08:15:47 UTC
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.