Bug 1339862

Summary: gdb returns an incorrect back trace when applying a debuginfo
Product: Red Hat Enterprise Linux 6 Reporter: Hisanobu Okuda <hokuda>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED ERRATA QA Contact: Arjun Shankar <ashankar>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.8CC: ashankar, gdb-bugs, hokuda, jan.kratochvil, mcermak, ohudlick, sergiodj
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: gdb-7.2-91.el6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-21 09:01:04 UTC Type: Bug
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:    
Bug Blocks: 1269194, 1361283    

Description Hisanobu Okuda 2016-05-26 02:00:18 UTC
Description of problem:
gdb returns an incorrect back trace when applying a debuginfo.

Without a debuginfo, the bt command returns:

(gdb) bt
#0  0x00007fe094f05625 in raise () from /lib64/libc.so.6
#1  0x00007fe094f06e05 in abort () from /lib64/libc.so.6
#2  0x00007fe0948a3165 in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101.x86_64/jre/lib/amd64/server/libjvm.so
#3  0x00007fe094a1785f in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101.x86_64/jre/lib/amd64/server/libjvm.so
#4  0x00007fe094a17f2b in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101.x86_64/jre/lib/amd64/server/libjvm.so
#5  0x00007fe0956877e0 in __libc_sigaction () from /lib64/libpthread.so.0

Installing debuginfo, the bt command returns:

(gdb) bt
#0  0x00007fe094f05625 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fe094f06e05 in abort () at abort.c:92
#2  0x00007fe0948a3165 in ?? ()
#3  0x00007fe094eae783 in ?? ()
#4  0x00007fddde5b72f0 in ?? ()
#5  0x00007fddde5b7260 in ?? ()
#6  0x00007fe094a1785f in ?? ()
#7  0x0000000000000000 in ?? ()

I downloaded the gdb 7.11 code from [1], untared it, ./configure, did make, did make install, then confirmed it works fine as follows:

(gdb) bt
#0  0x00007fe094f05625 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fe094f06e05 in *__GI_abort () at abort.c:92
#2  0x00007fe0948a3165 in os::abort (dump_core=true)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1640
#3  0x00007fe094a1785f in VMError::report_and_die (this=0x7fddde5b72f0)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1075
#4  0x00007fe094a17f2b in crash_handler (sig=11, info=0x7fddde5b74b0, ucVoid=0x7fddde5b7380)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm/vmError_linux.cpp:106
#5  <signal handler called>
#6  Klass::layout_helper (this=0x10) at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/oops/klass.hpp:346
#7  oopDesc::size_given_klass (klass=0x10, this=0x4508dd058)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:435
....

[1] https://www.gnu.org/software/gdb/download/

Version-Release number of selected component (if applicable):

Name        : gdb                          Relocations: (not relocatable)
Version     : 7.2                               Vendor: Red Hat, Inc.
Release     : 90.el6                        Build Date: Fri 11 Dec 2015 05:34:48 PM JST
Install Date: Wed 11 May 2016 08:34:28 PM JST      Build Host: x86-027.build.eng.bos.redhat.com
Group       : Development/Debuggers         Source RPM: gdb-7.2-90.el6.src.rpm
Size        : 5545845                          License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPLv2+ with exceptions and GPL+ and LGPLv2+ and GFDL and BSD and Public Domain
Signature   : RSA/8, Thu 14 Apr 2016 01:58:44 AM JST, Key ID 199e2f91fd431d51


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jan Kratochvil 2016-06-08 21:46:28 UTC
Sorry for the late check but it is not reproducible for me.  That is I need a more specific reproducer:

gdb-7.2-90.el6.x86_64
java-1.7.0-openjdk-1.7.0.99-2.6.5.1.el6.x86_64
java-1.7.0-openjdk-debuginfo-1.7.0.99-2.6.5.1.el6.x86_64
java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.1.el6.x86_64

Minor version differs but this is what RHEL-6.8 provides.

cat >HelloWorld.java <<EOH
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World");
	for (;;);
    }
}
EOH
javac HelloWorld.java
java HelloWorld &
gdb -p `pidof java`
(gdb) b abort
(gdb) signal SIGSEGV

without debuginfo:
(gdb) bt
#0  0x00007f00f620fc50 in abort () from /lib64/libc.so.6
#1  0x00007f00f5998835 in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/lib/amd64/server/libjvm.so
#2  0x00007f00f5b0c1af in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/lib/amd64/server/libjvm.so
#3  0x00007f00f599d3d2 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/lib/amd64/server/libjvm.so
#4  <signal handler called>
#5  0x00007f00f69892fb in pthread_join () from /lib64/libpthread.so.0
#6  0x00007f00f677cab5 in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/bin/../lib/amd64/jli/libjli.so
#7  0x00007f00f6776574 in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/bin/../lib/amd64/jli/libjli.so
#8  0x00007f00f67790a8 in JLI_Launch () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99.x86_64/jre/bin/../lib/amd64/jli/libjli.so
#9  0x0000000000400766 in ?? ()
#10 0x00007f00f61fad1d in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400629 in ?? ()
#12 0x00007ffecddf3ed8 in ?? ()
#13 0x000000000000001c in ?? ()
#14 0x0000000000000002 in ?? ()
#15 0x00007ffecddf61a1 in ?? ()
#16 0x00007ffecddf61a6 in ?? ()
#17 0x0000000000000000 in ?? ()

with debuginfo:
(gdb) bt
#0  abort () at abort.c:54
#1  0x00007f4e768b4835 in os::abort (dump_core=true)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1640
#2  0x00007f4e76a281af in VMError::report_and_die (this=0x7ffebffa4160)
    at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1075
#3  0x00007f4e768b93d2 in JVM_handle_linux_signal (sig=11, info=0x7ffebffa4330, ucVoid=0x7ffebffa4200, 
    abort_if_unrecognized=-1074118432) at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:531
#4  <signal handler called>
#5  0x00007f4e778a52fb in pthread_join (threadid=139974994056960, thread_return=0x7ffebffa4840) at pthread_join.c:89
#6  0x00007f4e77698ab5 in ContinueInNewThread0 (continuation=0x7f4e77692ef0 <JavaMain>, stack_size=1048576, args=0x7ffebffa48a0)
    at ../../../src/solaris/bin/java_md_solinux.c:1056
#7  0x00007f4e77692574 in ContinueInNewThread (ifn=0x7ffebffa8a10, threadStackSize=<value optimized out>, argc=0, argv=0x2539090, 
    mode=<value optimized out>, what=<value optimized out>, ret=0) at ../../../src/share/bin/java.c:1866
#8  0x00007f4e776950a8 in JLI_Launch (argc=0, argv=0x2539090, jargc=<value optimized out>, jargv=0x0, appclassc=1, 
    appclassv=<value optimized out>, fullversion=0x400898 "1.7.0_99-mockbuild_2016_03_29_22_14-b00", dotversion=0x400888 "1.7", 
    pname=0x40088c "java", lname=0x40088c "java", javaargs=0 '\000', cpwildcard=1 '\001', javaw=0 '\000', ergo=0)
    at ../../../src/share/bin/java.c:295
#9  0x0000000000400766 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../../../src/share/bin/main.c:125

Comment 15 errata-xmlrpc 2017-03-21 09:01:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0572.html

Comment 16 Red Hat Bugzilla 2023-09-14 03:23:17 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days