Okay full disclosure. :) I filed this bug back in 2009 so I undoubtedly
ran into a failure where this guard was causing the useful error
information to be lost, and so I filed the bug.
Now I am so much older and wiser I'm wondering about the original reason
for the guard again. ;-)
David
On 20/02/2013 2:23 PM, David Holmes wrote:
The one-reporter only logic in report_and_die has been there for a very
long time, pre-dating the addition of the check in
report_vm_out_of_memory. So I have to wonder what prompted the inclusion
of that guard originally? No doubt there was some failure case where we
were getting recursive errors that just totally broke the error reporting.
So while I can give this the Reviewer's tick if still needed. I suspect
that this will be a case of fixing one specific example, but in the
process potentially breaking others.
David
On 20/02/2013 9:48 AM, Daniel D. Daugherty wrote:
Greetings,
I'm sponsoring this code review request from Ron Durbin. This change
is targeted at JDK8/HSX-25 in the RT_Baseline repo.
Dan
I have a proposed fix for the following bug:
6799919 Recursive calls to report_vm_out_of_memory are handled
incorrectly
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6799919
https://jbs.oracle.com/bugs/browse/JDK-6799919
This is one of those bug fixes where the commit message nicely describes
the change:
6799919: Recursive calls to report_vm_out_of_memory are handled
incorrectly
Summary: report_vm_out_of_memory() should allow VMError.report_and_die()
to handle multiple out of native memory errors.
Reviewed-by: dcubed, <other-reviewers>
Contributed-by ron.dur...@oracle.com
Here is the webrev URL:
http://cr.openjdk.java.net/~dcubed/for_rdurbin/6799919-webrev/0-hsx25
Testing:
- See the READ_ME file attached to the JDK-6799919 for the gory
details
of the testing needed to reproduce this failure and verify the fix
- regular JPRT test job is in process
Comments, questions and suggestions are welcome.
Ron
