[OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Bill York Bill.York at mathworks.com
Thu Oct 11 11:00:13 UTC 2018

Thanks Phil,

All the 61 reports I mentioned below have the same stack. In the same 30 days we also received:

  *   120 reports about https://bugs.openjdk.java.net/browse/JDK-8146329 or https://bugs.openjdk.java.net/browse/JDK-8133783
     *   I can’t tell the difference between those two bug reports
     *   Note this is fixed in the JetBrains OpenJDK here: https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz


From: Phil Race <philip.race at oracle.com>
Date: Wednesday, October 10, 2018 at 4:34 PM
To: Bill York <Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m


I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
which look different.

On 10/10/2018 10:56 AM, Bill York wrote:
Thanks for the response Phil, here’s what I know.

Reports show:

  *   Mac OS – many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 u152-release-1136-b5 – JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the stack trace.
  *   I am on a mac and product crashes very often when I put my computer to sleep.
  *   Woke up computer after connecting to two external monitors.

I’ve annotated the function names with links to code I found on the OpenJDK site and the Apple site.

As an experiment, I created a simple X-Code project to examine how CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x00006000001c5848                                   <unknown-module>+00000000
[  8] 0x00007fff3cc4e678 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920 CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+00000024
[  9] 0x00000001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 getBPPFromModeString<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000032 (see line 32)
[ 10] 0x00000001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 createJavaDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000053 (see line 130)
[ 11] 0x00000001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000031 (see line 267)

Example code:

#import <Foundation/Foundation.h>

static int getBPPFromModeString(CFStringRef mode)


    if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

        // This is a strange mode, where we using 10 bits per RGB component and pack it into 32 bits

        // Java is not ready to work with this mode but we have to specify it as supported

        return 30;


    else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 32;


    else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 16;


    else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 8;


    return 0;


int main(int argc, const char * argv[]) {

    @autoreleasepool {

        // insert code here...

        CFStringRef mode;


        NSLog(@"Hello, World!");


    return 0;


From: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York <Bill.York at mathworks.com><mailto:Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net"<mailto:2d-dev at openjdk.java.net> <2d-dev at openjdk.java.net><mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing https://bugs.openjdk.java.net/browse/JDK-7124247<https://bugs.openjdk.java.net/browse/JDK-7124247>
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that reproduces this crash ?


On 10/10/18, 8:45 AM, Bill York wrote:
2d-dev folks,

I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m

Please let  me know if this is the right way to report a crash and discuss getting it resolved.

Here are the details:

CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode

While I can’t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user’s laptop opens or closes.

Looking at this source code:


I see a direct call to CFStringCompare without a check for a NULL CFStringRef.

  *   (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)

I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/ca9d6c81/attachment-0001.html>

More information about the 2d-dev mailing list