Bug 130423
Summary: | gdb can't debug pie when attaching to process | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Joe Orton <jorton> |
Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | cagney, goeran, pertusus, redhat-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | gdb-6.6-2.fc7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-01-31 01:04:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 150591 | ||
Bug Blocks: | 136451 |
Description
Joe Orton
2004-08-20 13:11:34 UTC
hmmm, can you try 6.1post-1.20040607.22? I don't remember if I had the pie fixes in the .8 rpm. I can break on main when starting a fresh gdb with that version. Attaching to the running httpd is still not giving a good backtrace, though: (gdb) where #0 0x00ee6402 in __kernel_vsyscall () #1 0x003a3a7b in semop () from /lib/tls/libc.so.6 #2 0x0058c6b8 in ?? () from /usr/lib/libapr-0.so.0 #3 0x0058cbf4 in initialized () from /usr/lib/libapr-0.so.0 #4 0x09bdbde0 in ?? () #5 0xfef1fb68 in ?? () #6 0x00584f36 in proc_mutex_sysv_acquire (mutex=0x58cbf4) at proc_mutex.c:263 Previous frame inner to this frame (corrupt stack?) Yes, atttaching to a pie executable doesn't work. It's a design limitation, there needs to be work done in bfd. We have a fix in progress in the FSF tree, but the binutils people didn't like it. So it's stalling. But if you don't attach (i.e. run under gdb from the beginning) it should work. modified summary and assign to Andrew, since he was doing the bfd part. Maybe we can get a RH only patch to put in the rpm. I can't get a backtrace when following a child. Is it the same issue ? [dumas@chapelle bug_reports]$ gdb gfortran GNU gdb Red Hat Linux (6.3.0.0-1.24rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set follow-fork-mode child (gdb) run -c -o truc.o cqm.f Starting program: /usr/bin/gfortran -c -o truc.o cqm.f Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x622000 Attaching after fork to child process 25703. Program received signal SIGSEGV, Segmentation fault. [Switching to process 25703] 0x0809caf2 in ?? () (gdb) bt #0 0x0809caf2 in ?? () #1 0x00000000 in ?? () (gdb) I have tried to reproduce comment #2 with gdb in devel. It may be right now since I get: (gdb) where #0 0xb7fb0402 in __kernel_vsyscall () #1 0x0020eecd in ___newselect_nocancel () from /lib/libc.so.6 #2 0x00e7ad59 in apr_sleep () from /usr/lib/libapr-1.so.0 #3 0x00ce0086 in ap_wait_or_timeout (status=0xbfe55f94, exitcode=0xbfe55f90, ret=0xbfe55f80, p=0x96564f8) at /usr/src/debug/httpd-2.2.3/server/mpm_common.c:345 #4 0x00cea0a3 in ap_mpm_run (_pconf=0x96564f8, plog=0x96845b0, s=0x9658398) at /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:1007 #5 0x00cc11b7 in main (argc=157631856, argv=0x0) at /usr/src/debug/httpd-2.2.3/server/main.c:717 Shouldn't this bug be closed? I got a backtrace failure of "-fpie -pie" compiled executable. There is a new `gdb.base/bt-ppc.exp' testcase for it. To be evaluated more. |