harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3731) [DRLVM] FinalizeStackTest failed in opt/srv mode on Win32
Date Tue, 24 Apr 2007 20:52:15 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491445

Rana Dasgupta commented on HARMONY-3731:

Hardware NPE's are not JIT safepoints either?  So they are susceptible to some enumeration
errors as well ( like push in this case), and these failures can be a broader problem. 
Though I think the JIT disables h/w NPE for some code regions like synchronized() etc.

For SOE, we can ignore this problem now( just keep the bug ), it is a very rare case, and
I also don't know what the user can do with a SOE :-) We could even unexclude the test I think,
unless the failure happens more frequently? The test does check SOE on finalization code paths
and has been running for months.

Doing stuff like this in the prolog is a creative idea. It is somewhat similar to how we fail
the compile currently if we can't predict enough stack space in check_available_stack_size().
But I think that it needs more thought.

> [DRLVM] FinalizeStackTest failed in opt/srv mode on Win32
> ---------------------------------------------------------
>                 Key: HARMONY-3731
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3731
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Win32, opt/srv mode
>            Reporter: Xiao-Feng Li
>         Attachments: h3731.patch
> This test case breaks from time to time, but hard to be reproduced. We suggest to keep
it in JIRA and exclude it for opt/srv modes test.
> Pavel Afremov has following comments, which are helpful for people fixing the bug:
>   1. In this case, fast asm helpers aren't used, because allocation of
>   finalizable objects always goes throw slow path.
>   2. It will be very nice to found what returns 3 error code. Correct me
>   if I wrong, this code is returned when top level thread exception handler
>   catch unprocessed java exception. It's a different situation. When VM
>   crashed with unprocessed SOE in fast path asm helpers it returns 128 error
>   code.
>   3. It looks very strange that test works in client mode and doesn't
>   work in server. For VM side (exception handling and helpers) there is no
>   difference between these two modes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message