Code Review fix for 6799919 Recursive calls to report_vm_out_of_memory are handled incorrectly (original) (raw)

David Holmes david.holmes at oracle.com
Tue Feb 19 20:41:49 PST 2013

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 reportanddie has been there for a very long time, pre-dating the addition of the check in reportvmoutofmemory. 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 RTBaseline repo. Dan

I have a proposed fix for the following bug: 6799919 Recursive calls to reportvmoutofmemory are handled incorrectly http://bugs.sun.com/bugdatabase/viewbug.do?bugid=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 reportvmoutofmemory are handled incorrectly Summary: reportvmoutofmemory() should allow VMError.reportanddie() to handle multiple out of native memory errors. Reviewed-by: dcubed, Contributed-by ron.durbin at oracle.com Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/forrdurbin/6799919-webrev/0-hsx25 Testing: - See the README 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

More information about the serviceability-dev mailing list