[jira] Updated: (HARMONY-4068) [drlvm]Jetty scenario fails on DRLVM with access violation exception

["Xiao-Feng Li (JIRA)" <ji...@apache.org>]

     [ 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　ｂｕｇ．Ｂｕｔ 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.