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 Fri, 27 Apr 2007 19:06:15 GMT

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

Rana Dasgupta commented on HARMONY-3731:

I poked around in the debugger with this and I am not sure that this problem is that push
is not a safepoint ( though that itself is a valid issue ) and failure of the Jit to unwind.
I don't think that the exception itself is being raised from managed code.

I saw the overflow exception being raised from the slow allocation path in vm_malloc_with_thread_pointer()
...possibly from gc_alloc(). It is an unwindable VM state and the exception is raised and
later rethrown when unwindable. It is being thrown and handled correctly ( as also in Vladimir's
output ). 

However, during the shutdown path, somehow, the VM is getting set to unwindable state when
it should not. And exec_shutdown_sequence() in vm_destroy when trying to do something trivial
, jni_env->findclass("java/lang/system") hits the assert in FindClass() ( see Vladimir's
output ). Since I could not repro, I could not find exactly where the wrong state is getting
set during shutdown.

We have to find a way to debug these rare failures on the test machines immediately when they

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