+++ 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