Discussion:
RFR (S): 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops
(too old to reply)
Roland Westrelin
2012-05-15 12:38:33 UTC
Permalink
http://cr.openjdk.java.net/~roland/7167254/webrev.00/

Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks.

Roland.
Dmitry Samersoff
2012-05-15 13:13:39 UTC
Permalink
Roland,

Could you fix comments as well? Otherwise looks good for me.

-Dmitry
Post by Roland Westrelin
http://cr.openjdk.java.net/~roland/7167254/webrev.00/
Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks.
Roland.
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
Roland Westrelin
2012-05-15 13:22:43 UTC
Permalink
Hi Dmitry
Post by Dmitry Samersoff
Could you fix comments as well? Otherwise looks good for me.
You're right. Here it is again with a comment:

http://cr.openjdk.java.net/~roland/7167254/webrev.01

Roland.
Dmitry Samersoff
2012-05-15 13:34:56 UTC
Permalink
Looks good for me.
Post by Roland Westrelin
Hi Dmitry
Post by Dmitry Samersoff
Could you fix comments as well? Otherwise looks good for me.
http://cr.openjdk.java.net/~roland/7167254/webrev.01
Roland.
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
Daniel D. Daugherty
2012-05-15 13:48:47 UTC
Permalink
Post by Roland Westrelin
Hi Dmitry
Post by Dmitry Samersoff
Could you fix comments as well? Otherwise looks good for me.
http://cr.openjdk.java.net/~roland/7167254/webrev.01
Roland.
Thumbs up.

src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
No comments

Dan
Rickard Bäckman
2012-05-15 13:15:10 UTC
Permalink
Roland,

the change looks good.

/R
Post by Roland Westrelin
http://cr.openjdk.java.net/~roland/7167254/webrev.00/
Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks.
Roland.
Vladimir Kozlov
2012-05-15 15:44:41 UTC
Permalink
Looks good. So other places where we check SIGSEG/SIGBUS signal are fine?

Thanks,
Vladimir
Post by Roland Westrelin
http://cr.openjdk.java.net/~roland/7167254/webrev.00/
Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks.
Roland.
Roland Westrelin
2012-05-15 15:44:55 UTC
Permalink
Post by Vladimir Kozlov
Looks good. So other places where we check SIGSEG/SIGBUS signal are fine?
Other places where SIGSEGV is tested for in this method already has a test for SIGBUS.

Roland.
Vladimir Kozlov
2012-05-15 15:49:08 UTC
Permalink
Post by Roland Westrelin
Post by Vladimir Kozlov
Looks good. So other places where we check SIGSEG/SIGBUS signal are fine?
Other places where SIGSEGV is tested for in this method already has a test for SIGBUS.
Good.

Vladimir
Post by Roland Westrelin
Roland.
David Holmes
2012-05-16 03:22:38 UTC
Permalink
Post by Roland Westrelin
Post by Vladimir Kozlov
Looks good. So other places where we check SIGSEG/SIGBUS signal are fine?
Other places where SIGSEGV is tested for in this method already has a test for SIGBUS.
Is there any possibility we will mistake a real SIGBUS for a
NullPointerException ?

David
Post by Roland Westrelin
Roland.
Roland Westrelin
2012-05-16 14:21:12 UTC
Permalink
Post by David Holmes
Is there any possibility we will mistake a real SIGBUS for a
NullPointerException ?
A SIGBUS caused by a bug in generated code for instance? Yes, there is a risk, the same way there is a risk a SIGSEGV becomes a NPE.
A SIGBUS that should be caught by the VM rather than be converted to a NPE. It doesn't look possible to me.

Roland.
Karen Kinnear
2012-05-15 17:52:54 UTC
Permalink
Roland,

Does this fix either of the following SIGBUS on Mac bugs?

7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred,
which is where my other question came from - is there a place where we look for
SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code
path yet)
Test name: gc/gctests/JumbleGC002 ( see the jira link)

7129716 (probably just a duplicate of the one you just fixed)

Hotspot regression tests compiler/6865031/Test.java
fails on MacOS if run with -Xcomp:

Any chance you could run these tests with your new fix?

thanks very much,
Karen
Post by Roland Westrelin
http://cr.openjdk.java.net/~roland/7167254/webrev.00/
Crashes were reported for 64 bit VMs on OSX running in "compressed oops with base" mode. The crash is caused by a SIGBUS on a correctly aligned access to the first page of the heap which is used for implicit null checks. With this change hotspot on OSX expects either a SIGBUS or SIGSEGV for implicit null checks.
Roland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120515/de3b2655/attachment.html
Roland Westrelin
2012-05-15 18:40:49 UTC
Permalink
Hi Karen,
Post by Karen Kinnear
Any chance you could run these tests with your new fix?
Sure. I'll see if they still reproduce.

Roland.
Roland Westrelin
2012-05-16 13:49:02 UTC
Permalink
Hi Karen,
Post by Karen Kinnear
Does this fix either of the following SIGBUS on Mac bugs?
7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred,
which is where my other question came from - is there a place where we look for
SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code
path yet)
Test name: gc/gctests/JumbleGC002 ( see the jira link)
This one still reproduces with my change.
Post by Karen Kinnear
7129716 (probably just a duplicate of the one you just fixed)
Hotspot regression tests compiler/6865031/Test.java
This one is a duplicate of my bug. I closed it.

Roland.
Karen Kinnear
2012-05-16 18:42:18 UTC
Permalink
Roland,

Many thanks for testing and closing 7129716.

I did look at the code path for stack overflow and there is no obvious place
where we look for SEGV and also need to look for SIGBUS.
We will follow up on 7129715.

many thanks,
Karen
Post by Roland Westrelin
Hi Karen,
Post by Karen Kinnear
Does this fix either of the following SIGBUS on Mac bugs?
7129715 (this is the one where it also lists "An irrecoverable stack overflow has occurred,
which is where my other question came from - is there a place where we look for
SIGSEGV for stack overflow and also need to look for SIGBUS" - I didn't track the code
path yet)
Test name: gc/gctests/JumbleGC002 ( see the jira link)
This one still reproduces with my change.
Post by Karen Kinnear
7129716 (probably just a duplicate of the one you just fixed)
Hotspot regression tests compiler/6865031/Test.java
This one is a duplicate of my bug. I closed it.
Roland.
Roland Westrelin
2012-05-16 14:25:30 UTC
Permalink
One more webrev:
http://cr.openjdk.java.net/~roland/7167254/webrev.02/

I forgot to cast the MacroAssembler::needs_explicit_null_check() argument to intptr_t rather than int.

Roland.
Vladimir Kozlov
2012-05-16 15:44:24 UTC
Permalink
Good.

Vladimir
Post by Roland Westrelin
http://cr.openjdk.java.net/~roland/7167254/webrev.02/
I forgot to cast the MacroAssembler::needs_explicit_null_check() argument to intptr_t rather than int.
Roland.
Loading...