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

2018-10-12 Thread Bill York
Thanks Sergey.

On 10/11/18, 5:43 PM, "Sergey Bylokhov"  wrote:

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can 
become non-valid at any time therefore methods, which is using this id should 
be ready to it.

And this bug found a few places which does not take care about the rule 
above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, 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:
> 
> 
http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
> 
> 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.
> 
> Bill
> 


-- 
Best regards, Sergey.





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

2018-10-12 Thread Bill York
Excellent. That looks like the same bug. Note that it also affects JDK8.

Bill

On 10/11/18, 5:43 PM, "Sergey Bylokhov"  wrote:

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can 
become non-valid at any time therefore methods, which is using this id should 
be ready to it.

And this bug found a few places which does not take care about the rule 
above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, 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:
> 
> 
http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
> 
> 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.
> 
> Bill
> 


-- 
Best regards, Sergey.





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

2018-10-11 Thread Sergey Bylokhov

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can 
become non-valid at any time therefore methods, which is using this id should 
be ready to it.

And this bug found a few places which does not take care about the rule above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, 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:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html

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.

Bill




--
Best regards, Sergey.


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

2018-10-11 Thread Bill York
Hey Phil,

As an update on this discussion, I pulled the latest OpenJDK 8 and got it to 
build on an OSX 10.75 Mac we have here.

To verify that an early return of 0 from getBPPFromModeString works without 
crashing, I forced getBPPFromModeString to return 0 every 5th call and then, 
while our app is running, I changed the display configuraton.

Through use of PRINTF, I verified that getBPPFromModeString got called and did 
an early return.

At first glance, it appears that a check for NULL with an early return of 0 
could prevent the crash we are seeing.

While I can’t force the conditions that demonstrate the customer reported bug, 
it appears that this fix will help.

Bill

From: Bill York 
Date: Thursday, October 11, 2018 at 7:00 AM
To: Phil Race 
Cc: "2d-dev@openjdk.java.net" <2d-dev@openjdk.java.net>, Bill York 

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

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

Bill

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

Hi,

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
https://bugs.openjdk.java.net/browse/JDK-8146329<https://bugs.openjdk.java.net/browse/JDK-8146329>
https://bugs.openjdk.java.net/browse/JDK-8133783<https://bugs.openjdk.java.net/browse/JDK-8133783>
which look different.

-phil.
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] 0x601c5848   
+
[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920
 
CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+0024
[  9] 0x0001351a80f7 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>+0032
 (see line 32)
[ 10] 0x0001351a819f 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>+0053
 (see line 130)
[ 11] 0x0001351a841e 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>+0031
 (see line 267)

Example code:


#import 



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;

getBPPFromModeString(mode);


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

2018-10-11 Thread Bill York
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

Bill

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

Hi,

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
https://bugs.openjdk.java.net/browse/JDK-8146329<https://bugs.openjdk.java.net/browse/JDK-8146329>
https://bugs.openjdk.java.net/browse/JDK-8133783<https://bugs.openjdk.java.net/browse/JDK-8133783>
which look different.

-phil.
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] 0x601c5848   
+
[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920
 
CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+0024
[  9] 0x0001351a80f7 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>+0032
 (see line 32)
[ 10] 0x0001351a819f 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>+0053
 (see line 130)
[ 11] 0x0001351a841e 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>+0031
 (see line 267)

Example code:


#import 



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;

getBPPFromModeString(mode);

NSLog(@"Hello, World!");

}

return 0;

}


From: Philip Race <mailto:philip.r...@oracle.com>
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York <mailto:bill.y...@mathworks.com>
Cc: "2d-dev@openjdk.java.net"<mailto:2d-dev@openjdk.java.net> 
<2d-dev@openjdk.java.net><mailto:2d-dev@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 ?

-phil.

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

I work on a p

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

2018-10-10 Thread Phil Race

Hi,

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
https://bugs.openjdk.java.net/browse/JDK-8146329
https://bugs.openjdk.java.net/browse/JDK-8133783
which look different.

-phil.

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] 0x601c5848 +

[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920CFStringCompare 
<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+0024


[  9] 0x0001351a80f7 
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>+0032 
(see line 32)


[ 10] 0x0001351a819f 
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>+0053 
(see line 130)


[ 11] 0x0001351a841e 
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>+0031 
(see line 267)


Example code:

#import 

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;

}

elseif(CFStringCompare(mode, CFSTR(IO32BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {


return 32;

}

elseif(CFStringCompare(mode, CFSTR(IO16BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {


return 16;

}

elseif(CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {


return 8;

}

return0;

}

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

@autoreleasepool{

// insert code here...

CFStringRef mode;

getBPPFromModeString(mode);

NSLog(@"Hello, World!");

}

return0;

}

*From: *Philip Race 
*Organization: *Oracle Corporation
*Date: *Wednesday, October 10, 2018 at 12:03 PM
*To: *Bill York 
*Cc: *"2d-dev@openjdk.java.net" <2d-dev@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 ?


-phil.

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:


http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html

<http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>

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
tho

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

2018-10-10 Thread Bill York
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] 0x601c5848   
+
[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920
 
CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+0024
[  9] 0x0001351a80f7 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>+0032
 (see line 32)
[ 10] 0x0001351a819f 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>+0053
 (see line 130)
[ 11] 0x0001351a841e 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>+0031
 (see line 267)

Example code:


#import 



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;

getBPPFromModeString(mode);

NSLog(@"Hello, World!");

}

return 0;

}


From: Philip Race 
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York 
Cc: "2d-dev@openjdk.java.net" <2d-dev@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 ?

-phil.

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:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html<http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>

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.

Bill


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

2018-10-10 Thread Philip Race

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
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 ?


-phil.

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:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html 



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.


Bill



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

2018-10-10 Thread Bill York
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:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html

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.

Bill