+++ This bug was initially created as a clone of Bug #614028 +++ Created an attachment (id=431479) Old Backtrace, New Backtrace and Binary to reproduce Description of problem: gdb produces invalid backtraces. for example stackframe of threads: #12 0x0000000001db3818 in ?? () #13 0x00000000477c3c01 in ?? () #14 0x00000000477c3c50 in ?? () Cannot access memory at address 0x2f1b16068d234f5 Version-Release number of selected component (if applicable): 7.0.1-23.el5 (gdb-6.8-37.el5 - RHEL 5.4 - works perfectly) How reproducible: (Attachment) Steps to Reproduce: 1. Call Binary "BinaryToReproduce" 2. Binary will crash automatically with signal 6 3. Analyze coredump with gdb - following steps: 3.1 bt 3.2 info threads 3.3 thread apply all backtrace Actual results: see gdb.BinaryToReproduce_7.0.1-23.el5.txt in attached zip-archive. Expected results: see gdb.BinaryToReproduce_gdb-6.8-37.el5.txt in attached zip-archive. Additional info: Binary compliled with gcc version 4.1.2 20080704 (Red Hat 4.1.2-48). --- Additional comment from jan.kratochvil on 2010-07-14 22:34:33 CEST --- Fix + testcase at: http://sourceware.org/ml/archer/2010-q3/msg00028.html
gdb-7.1-29.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gdb-7.1-29.fc13
gdb-7.0.1-49.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gdb-7.0.1-49.fc12