GtkLookAndFeel fatal crash on Oracle Jre

I am having an issue where the JRE crashes whenever I check if the GtkLookAndFeel is supported. Surprisingly, this bug only appears to show up on Oracle JREs.

So far I have tested the behavior on three JREs:

(I am using the 64 bit version of all of these)

OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-4) -> Runs fine
Java(TM) SE Runtime Environment (build 1.7.0_67-b01) -> Crashes
Java(TM) SE Runtime Environment (build 1.8.0_20-b26) -> Crashes

Here is code to trigger this bug:

import javax.swing.LookAndFeel;
public class Test
{
    public static void main(String[] args)
    {
      LookAndFeel currLAF = new com.sun.java.swing.plaf.gtk.GTKLookAndFeel();
      currLAF.isSupportedLookAndFeel();
      System.out.println("I am exiting main");
    } 
}

Here is the resulting output:

I am exiting main
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f91fe0fdbe0, pid=332, tid=140265730119424
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x00007f91fe0fdbe0
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/ethan/fail/hs_err_pid332.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Note that the program only crashes after it exits main.

For reference, I am developing on a 64-bit debian testing machine and I have verified that other GTK+ apptications work.

Should I report this to Oracle or am I doing something wrong?

I would definitely file a bug report with Oracle. I remember something similar occurring to me many years ago. You've done your due diligence and tested on multiple runtime environments, and have identified (at least on an upper level) where the bug occurs. I would tell them everything you've done as listed here, and to be safe, run the same code on a couple different machines if you can. I know that Java should run the same either way, it's designed that way, but do it anyways so you can at least say you did that in the bug report.

Make sure you follow these guides here to collect the right information, crash dumps, system info, runtime info, etc: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/bugreports.html

And grab the core dump if you can. The core dump will be extremely helpful (to an almost required degree) to the Oracle people for debugging what's actually happening. Here's a link to the Oracle page, but you may have to find the specific information for your machine: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/bugreports004.html#CHDJJAJE

From the above link:

On the Linux operating system, unhandled signals such as segmentation violation, illegal instruction, and so forth, result in a core dump. By default, the core dump is created in the current working directory of the process and the name of the core dump file is core.pid, where pid is the process id of the crashed Java process.

The ulimit utility is used to get or set the limitations on the system resources available to the current shell and its descendants. Use the ulimit -c command to check or set the core file size limit. Make sure that the limit is set to unlimited; otherwise the core file could be truncated.

And this is the link to the Java Oracle Bug Reporting Site: https://bugreport.java.com/

Recommended topics

Hot tags