harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4068) [drlvm]Jetty scenario fails on DRLVM with access violation exception
Date Fri, 15 Jun 2007 14:20:26 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Xiao-Feng Li updated HARMONY-4068:
----------------------------------

    Assignee:     (was: Xiao-Feng Li)
     Summary: [drlvm]Jetty scenario fails on DRLVM with access violation exception  (was:
[drlvm][gc_gen] Jetty scenario fails on DRLVM with access violation exception)

Investigation shows this is not a GC bug.But I am not sure which component
causes this bug. 

Although the break sometimes happens in GC, it is caused by an incorrect dead object before
entering GC, and the object became incorrect between two collections (instead of inside a
collection). It's just exposed by GC.

Then why GCv4.1 doesn't have the break? That's because GCv4.1 uses different algorithm that
doesn't traverse the heap linearly for live objects. GCv5 goes through the heap one byte by
another to identify live objects - it checks next object from current object's end, and next
next object from next object's end. This has no problem in cases of the next object is alive
or dead, since its contents are not destroyed, thus we can always compute its size from its
vtable field. However, if the vtable is destroyed, GCv5 will break. But this dead broken object
is destroyed by the mutator already. GCv4.1 doesn't work this way. It discovers live objects
with markbit table, so it never needs to touch dead object.

Specifically, the destroyed object header vt field is filled with a native pointer pointing
to a sequence of ASCIIs something like "The socket is marked as nonblocking ...". This ASCII
string is outside of GC heap. In my understanding, it is impossible for GC to know a native
pointer, and a native ASCII string. GC verifier can always catch this wrong object before
starting a collection.

This dead object looks like a long array [J field of Java/Net/SocketException object. This
long array is dead when GC happens, and its vt field is filled with a native pointer.

Moreover, the object vt header field is written by <init> method of "org/apache/harmony/luni/util/ErrorCodeException",
which is a created object by API native function throwJavaNetSocketException, which in turn
is called in Java_org_apache_harmony_luni_platform_OSNetworkSystem_writeSocketDirectImpl.

> [drlvm]Jetty scenario fails on DRLVM with access violation exception
> --------------------------------------------------------------------
>
>                 Key: HARMONY-4068
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4068
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Windows XP, ia32
>            Reporter: Ivaschenko, Aleksei V
>
> Hello,
> the Jetty scenario intermittently fails (chance to fail is up to 70%) on DRLVM with access
violation exception in VM which runs the Jetty server. Exception is thrown from gc_gen module
(gc_for_class.h file, line 198):
>     gc_gen.dll!vtable_get_gcvt_raw(Partial_Reveal_VTable * vt=0x00021b08) Line 198
>     gc_gen.dll!obj_get_gcvt_raw(Partial_Reveal_Object * obj=0x20d87cc1) Line 213
>     gc_gen.dll!object_is_array(Partial_Reveal_Object * obj=0x20d87cc1) Line 243
>     gc_gen.dll!vm_object_size(Partial_Reveal_Object * obj=0x20d87cc1) Line 279
>     gc_gen.dll!obj_end(Partial_Reveal_Object * obj=0x20d87cc1) Line 122
>     gc_gen.dll!next_marked_obj_in_block(Partial_Reveal_Object * cur_obj=0x20d87cc1, Partial_Reveal_Object
* block_end=0x20d87ff...
>     gc_gen.dll!block_get_next_marked_object(Block_Header * block=0x20d80000, void * *
start_pos=0x0213fee0) Line 203
>     gc_gen.dll!mspace_move_objects(Collector * collector=0x01d36448, Mspace * mspace=0x01c12f20)
Line 102
>     gc_gen.dll!move_compact_mspace(Collector * collector=0x01d36448) Line 199
>     gc_gen.dll!collector_thread_func(void * arg=0x01d36448) Line 181
>     hythr.dll!thread_start_proc(void * arg=0x00426a90) Line 711
>     hythr.dll!_threadstartex(void * ptd=0x00426728) Line 241
>     kernel32.dll!7c80b683()
> The scenario for reproducing could be taken from SVN:
> /harmony/enhanced/buildtest/branches/2.0/adaptors/JettyScenario
> Thanks.

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


Mime
View raw message