I’m seem to be having a problem with my java installation in F39, where if I type java into the terminal, I immediately get,
Segmentation fault (core dumped)
as the only output. I ran the same command in gdb and got the following backtrace,
#0 0x00007ffff6a8baa0 in ?? () from /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so #1 0x00007ffff7fce237 in call_init (env=0x7fffffffdf28, argv=0x7fffffffdf18, argc=1, l=) at dl-init.c:74 #2 call_init (l=, argc=1, argv=0x7fffffffdf18, env=0x7fffffffdf28) at dl-init.c:26 #3 0x00007ffff7fce32d in _dl_init (main_map=0x5555555595b0, argc=1, argv=0x7fffffffdf18, env=0x7fffffffdf28) at dl-init.c:121 #4 0x00007ffff7fca5c2 in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7ffff7fd4f50 <call_dl_init>, args=args@entry=0x7fffffff9710) at dl-catch.c:211 #5 0x00007ffff7fd4eec in dl_open_worker (a=a@entry=0x7fffffff98c0) at dl-open.c:829 #6 0x00007ffff7fca523 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffff98a0, operate=operate@entry=0x7ffff7fd4e50 <dl_open_worker>, args=args@entry=0x7fffffff98c0) at dl-catch.c:237 #7 0x00007ffff7fd52e4 in _dl_open (file=0x7fffffff9d20 “/usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so”, mode=, caller_dlopen=0x7ffff7fb31c5 <LoadJavaVM+53>, nsid=, argc=1,
argv=0x7fffffffdf18, env=0x7fffffffdf28) at dl-open.c:905 #8 0x00007ffff7e38664 in dlopen_doit () from /lib64/libc.so.6 #9 0x00007ffff7fca523 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffff9ab0, operate=0x7ffff7e38600 <dlopen_doit>, args=0x7fffffff9b70) at dl-catch.c:237 #10 0x00007ffff7fca679 in _dl_catch_error (objname=0x7fffffff9b18, errstring=0x7fffffff9b20, mallocedp=0x7fffffff9b17, operate=, args=) at dl-catch.c:256 #11 0x00007ffff7e38143 in _dlerror_run () from /lib64/libc.so.6 #12 0x00007ffff7e3871f in dlopen@GLIBC_2.2.5 () from /lib64/libc.so.6 #13 0x00007ffff7fb31c5 in LoadJavaVM () from /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/bin/…/lib/libjli.so #14 0x00007ffff7fb0d26 in JLI_Launch () from /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/bin/…/lib/libjli.so #15 0x00005555555552c6 in main ()
Any assistance in resolving this is greatly appreciated.
Could you get a backtrace with debuginfod enabled (set debuginfod enabled on in GDB)? Or at least post the crash address (from the first entry of the backtrace) and the load address of libjvm.so via info shared libjvm.so? This has to be from the same session due to ASLR.
@jakfrost , this is indeed an upgraded system that began with F37, but I couldn’t tell you if I previously had a working JDK as this is the first time I’ve ever had to run the java command.
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/conf/security/java.security
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/conf/security/nss.fips.cfg
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/security/default.policy
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/security/public_suffix_list.dat
…5… /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/modules
…5… /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/classes.jsa
…5… /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/classes_nocoops.jsa
…5… /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so
…5… d /usr/share/doc/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/NEWS
Sorry, I wanted to see the crash site in libjvm.so (without the up), so either its address (along with the libjvm.so load address), or the symbol information if available.
Sorry to be a bother, but would you be able to guide me through the procedures for getting this information? I’m not very familiar with the debugging process,
@jd13386 After you enable debuginfod, you should be able to run bt again, this time with symbols, similar to what you quoted initially. I’m interested in the #0 line.
Here’s the procedure I’m using. Please let me know if I’m making a mistake.
In the terminal, I type gdb, then at the prompt type,
(gdb) file java
At this point, I get the question,
Enable debuginfod for this session? (y or [n])
to which I type y which downloads some files. I think this is enabling the debuginfod that you requested, but just to be sure, I repeat the set debuginfod enabled on command.
Then I run with
(gdb) run
which generates the crash. If I then type bt, for #0 I only get
#0 0x00007ffff6a8baa0 in ?? ()
from /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so
Java is working for me, but gdb gives similar results here:
~% gdb
GNU gdb (Fedora Linux) 14.1-1.fc39
[...]
(gdb) file java
Reading symbols from java...
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/bin/java
Reading symbols from /home/gnw3/.cache/debuginfod_client/89eed4d491b2ea0c472694f08312df216143ae89/debuginfo...
Downloading separate debug info for /home/gnw3/.cache/debuginfod_client/89eed4d491b2ea0c472694f08312df216143ae89/debuginfo
(gdb) set debuginfod enabled on
(gdb) run
Starting program: /usr/bin/java
Downloading separate debug info for system-supplied DSO at 0x7ffff7fc7000
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/bin/../lib/libjli.so
Downloading separate debug info for /lib64/libc.so.6
Downloading separate debug info for /home/gnw3/.cache/debuginfod_client/788cdd41a15985bf8e0a48d213a46e07d58822df/debuginfo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so
Downloading separate debug info for /lib64/libm.so.6
[New Thread 0x7ffff7cc46c0 (LWP 396182)]
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/libjimage.so
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/libjava.so
Thread 2 "java" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7cc46c0 (LWP 396182)]
0x00007fffe053762d in ?? ()
(gdb) bt
#0 0x00007fffe053762d in ?? ()
#1 0x0000000000000246 in ?? ()
#2 0x00007fffe0537724 in ?? ()
#3 0x00007ffff7b67590 in ?? () from /usr/lib/jvm/java-17-openjdk-17.0.9.0.9-3.fc39.x86_64/lib/server/libjvm.so
#4 0x00007ffff7cc33b0 in ?? ()
#5 0x00007ffff776949d in VM_Version::get_processor_features () at src/hotspot/cpu/x86/vm_version_x86.cpp:630
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
Per Why does java app crash in gdb? try adding handle SIGSEGV nostop noprint pass. With that change, I get the normal usage message.
!