Segmentation fault with java command

Hi Everyone

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-
#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-”, 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/
#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/
#12 0x00007ffff7e3871f in dlopen@GLIBC_2.2.5 () from /lib64/
#13 0x00007ffff7fb31c5 in LoadJavaVM () from /usr/lib/jvm/java-17-openjdk-…/lib/
#14 0x00007ffff7fb0d26 in JLI_Launch () from /usr/lib/jvm/java-17-openjdk-…/lib/
#15 0x00005555555552c6 in main ()

Any assistance in resolving this is greatly appreciated.

Hello @jd13386 ,
Welcome to :fedora: !
Is this an upgraded system that did have a working JDK?

Can you please provide the output of rpm -V $(rpm -qf $(which java))?

$ rpm -qf $(which java) ; java -version
openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment (Red_Hat- (build 17.0.9+9)
OpenJDK 64-Bit Server VM (Red_Hat- (build 17.0.9+9, mixed mode, sharing)

Typing java for me gives the help context.

1 Like

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 via info shared This has to be from the same session due to ASLR.

Thanks everyone for your input.

@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.

@vwbusguy , the output you requested is,

S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-
S.5…T. c /etc/java/java-17-openjdk/java-17-openjdk-
…5… /usr/lib/jvm/java-17-openjdk-
…5… /usr/lib/jvm/java-17-openjdk-
…5… /usr/lib/jvm/java-17-openjdk-
…5… /usr/lib/jvm/java-17-openjdk-
…5… d /usr/share/doc/java-17-openjdk-

Continuing on a separate post as I’m only allowed to address 2 members at a time.

@fweimer , I enabled debuginfod as instructed, then through the up command after the crash, I get,

#1 0x00007ffff7fce237 in call_init (env=0x7fffffffdf58, argv=0x7fffffffdf48,
argc=1, l=<optimized out>) at dl-init.c:74
Downloading source file /usr/src/debug/glibc-2.38-14.fc39.x86_64/elf/dl-init.c
74 ((dl_init_t) addrs[j]) (argc, argv, env);

Hopefully this is what you’re after. For the load address of, the output is,

From To Syms Read Shared Object Library
0x00007ffff6a540e0 0x00007ffff77f6a02 Yes /usr/lib/jvm/java-17-openjdk-

Sorry, I wanted to see the crash site in (without the up), so either its address (along with the 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-

which appears to be the same as before.

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:
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-
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-                                                                      
Downloading separate debug info for /lib64/                                                                                                                                
Downloading separate debug info for /home/gnw3/.cache/debuginfod_client/788cdd41a15985bf8e0a48d213a46e07d58822df/debuginfo                                                          
[Thread debugging using libthread_db enabled]                                                                                                                                       
Using host libthread_db library "/lib64/".
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-
Downloading separate debug info for /lib64/                                                                                                                                
[New Thread 0x7ffff7cc46c0 (LWP 396182)]                                                                                                                                            
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-
Downloading separate debug info for /usr/lib/jvm/java-17-openjdk-                                                                            
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-
#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?)

Per Why does java app crash in gdb? try adding handle SIGSEGV nostop noprint pass. With that change, I get the normal usage message.

Hello @jd13386 ,
Just out of curiosity, what is the java application you are trying to run? The actual file I mean.
[Good catch @vgaetera ]

You have checksums mismatch for the files owned by the RPM package.

sudo dnf reinstall java-17-openjdk-headless

Hi @jakfrost , it’s the AutoFirma program from the Spanish government,

They issue us with a certificate that we can use to legally sign documents in lieu of handwritten signatures.

Thanks to @gnwiii for further input. @vgaetera fixed the issue for me, many thanks.

1 Like

This may be part of a larger problem, so I recommend to perform a filesystem check, then verify all installed packages and reinstall the affected ones if any.

1 Like