Solved Java, frequent segfaults

I have been noticing I am having frequent segfaults when I run a utility to format my java code. I am using a shell script that wraps google java format and runs 10 processes in parallel via xarg. I am guessing that by running 10 processes in parallel that use the same jar file, I am having this problem.

If the jar file is opened read-only, why would it matter if I'm accessing it 10 times in parallel? All of my java code formats are done on different files, so they shouldn't be interfering with one another.
Code:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000080118ddae, pid=22778, tid=993361
#
# JRE version: OpenJDK Runtime Environment (15.0.2+7) (build 15.0.2+7-1)
# Java VM: OpenJDK 64-Bit Server VM (15.0.2+7-1, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libc.so.7+0xc8dae]  localeconv_l+0xbe
#
# No core dump will be written.
#
# An error report file with more information is saved as:
# <HOME_DIR>/projects/localhost/programming/java/parent/hs_err_pid22778.log

[error occurred during error reporting ((null)), id 0xb, SIGSEGV (0xb) at pc=0x000000080118ddae]
 
If the jar file is opened read-only, why would it matter if I'm accessing it 10 times in parallel?
Because it might not be designed to run concurrently. You can run into all sorts of race or locking issues.
All of my java code formats are done on different files, so they shouldn't be interfering with one another.
Sure, but the code that does the parsing might keep track of various things in a way that makes it impossible to run concurrently. One process might be interfering with the data of another.
 
Good points, after thinking about it more, the limit will likely be disk I/O anyways so, multiple threads may not help anyways.
 
Can you link to the code of that utility? It might still be interesting to see what exactly is causing it to crash. It might be easily fixable, or maybe not. But without looking at the actual code we can only guess what the problem might be. The issues I mentioned are common issues you might run into. It may not be the problem with this particular utility.
 
Anything of interest in the hs_err_pid22778.log? The JVM should not segfault like that. You may have found a bug in it.
 
This happens to me fairly regularly when I run a maven test build. The build is parallelized and will spawn 24 jvms to run tests on. The Finalizer is always the offending thread and the stack trace is always the same.
 

Attachments

  • hs_err_pid84286.log.txt
    86.2 KB · Views: 204
This happens to me fairly regularly when I run a maven test build. The build is parallelized and will spawn 24 jvms to run tests on. The Finalizer is always the offending thread and the stack trace is always the same.
That does look like a jvm bug. Maybe file it here?

You probably should have a new thread for this.
 
This happens to me fairly regularly when I run a maven test build. The build is parallelized and will spawn 24 jvms to run tests on. The Finalizer is always the offending thread and the stack trace is always the same.
Did you figure this out? Getting SIGSEGV at random locations during anything jdk-related (maven build, running intellij). No matter which version or whether ASLR is on/off.
 
These problems would happen to me (always the exact same stack trace) if I run a mvn test with multiple jvms (24) on openjdk 8, 11 and 16. I changed my maven configuration to send test output to individual test files and they have never happened since then. Seems to me the issue is related to contention on the terminal output.
 
Seems completely unrelated then. I'm having some other issues with the machine as well so a clean reinstall might just be what it needs. Thank you anyways. I'll report back in if the issue persist.

Edit #01: A reinstall fixed my issue, no idea yet what caused the segfault. Will build world with my config and see if anything in there was the culprit.
 
Last edited:
Back
Top