Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid jacop-related crashes due to destructor execution order #133

Merged
merged 1 commit into from
May 7, 2021
Merged

Avoid jacop-related crashes due to destructor execution order #133

merged 1 commit into from
May 7, 2021

Conversation

jamesjer
Copy link
Contributor

When Fedora switched from building with OpenJDK 8 to OpenJDK 11 a few months ago, the mp package started failing its tests. The jacop-test binary, in particular, started segfaulting. I finally got around to diagnosing the issue.

In solvers/jacop/java.h, there is a class named JVM which contains a JavaVM pointer (jvm_) and an environment (env_). There is also a static instance of this class, named instance_, which is initialized on the fly when it is first accessed. The JVM destructor is in solvers/jacop/java.cc:

JVM::~JVM() {
  if (jvm_)
    jvm_->DestroyJavaVM();
}

After the jacop tests have run, the test program exits. This triggers execution of destructors for static and global objects. At some point, the ImageFileReaderTable destructor is run. This is an object in OpenJDK's libjimage.so. After that, the destructor for the static instance_ object is run, which results in a call to DestroyJavaVM(), which then loads java.lang.Shutdown. Part of the class loading process is to check for image resources associated with the class. This check accesses the already destroyed ImageFileReaderTable, thereby causing a segfault. See https://bugzilla.redhat.com/show_bug.cgi?id=1858054 for more information.

This commit is probably not the best solution, but it does avoid the segfault. The trick is that atexit-registered functions are run before global object destructors. Consider this more of a bug report with an ugly workaround attached than a real pull request. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants