harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HARMONY-4262) [drlvm][shutdown][thread] On shutdown finalizer thread may hold bootstrap class loader lock which leads to its crash
Date Mon, 08 Oct 2007 15:40:50 GMT

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

Gregory Shimansky closed HARMONY-4262.

    Resolution: Cannot Reproduce
      Assignee: Gregory Shimansky

I ran this test 1000 times on JIT and interpreter, there were no hangs. So it looks like this
bug is no longer reproducible.

> [drlvm][shutdown][thread] On shutdown finalizer thread may hold bootstrap class loader
lock which leads to its crash
> --------------------------------------------------------------------------------------------------------------------
>                 Key: HARMONY-4262
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4262
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Gregory Shimansky
>            Assignee: Gregory Shimansky
> The test smoke gc.RunFinalizersOnExitTest crashed on failed assertion for me (although
it crashed on interpreter, I think that this bug is not related to execution mode that is
used to run the test).
> 1st thread is executing DestroyJavaVM because main thread is shutting down. But 2nd thread
which is finalizers thread tries to load some class at the same moment (for me it tried to
load com/ibm/icu4jni/charset/CharsetEncoderICU) with bootstrap class loader.
> 1st thread already executes BootstrapClassLoader destructor, and tries to destroy its
mutex, but pthread_mutex_destroy returns an error if this mutex is busy, so hymutex_destroy
crashes on assertion since this mutex is held by the 2nd finalizer thread. I want to also
note that even without failed assertion it seems wrong to me to execute BootstrapClassLoader
destructor while some other thread actively uses BootstrapClassLoader in its work.
> Thread stacks look like this:
> #4  0x405b3511 in raise () from /lib/tls/libc.so.6
> #5  0x405b4d9f in abort () from /lib/tls/libc.so.6
> #6  0x405acce3 in __assert_fail () from /lib/tls/libc.so.6
> #7  0x40bc05b6 in ~Lock_Manager (this=0x808c474)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/thread/lock_manager.cpp:40
> #8  0x40b2cdda in ~JarFile (this=0x808c458) at jarfile_support.h:170
> #9  0x40b28751 in ~BootstrapClassLoader (this=0x808ba78)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1195
> #10 0x40b01357 in ~Global_Env (this=0x807c618)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/Environment.cpp:227
> #11 0x40b65c27 in DestroyJavaVM (vm=0x807c600)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/jni/jni.cpp:1479
> #12 0x08049c75 in invocation (portLibrary=0xbffff1a0, argc=7, argv=0xbffff5e4, handle=134655848,
>     ignoreUnrecognized=1 '\001', mainClass=0xbffffd3b "gc.RunFinalizersOnExitTest", classArg=6,
>     propertiesFileName=0x806ae58 "/nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/default/harmonyvm.properties",
isStandaloneJar=0, vmdllsubdir=0xbffff0c8 "default")
>     at ../shared/main.c:756
> #13 0x080491e5 in gpProtectedMain (args=0xbffff180) at ../shared/main.c:389
> #14 0x0804b632 in main (argc=7, argv=0xbffff5e4, envp=0xbffff604) at ../shared/cmain.c:146
> #4  0x4062e07c in sched_yield () from /lib/tls/libc.so.6
> #5  0x4003ef66 in hythread_yield ()
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/thread/src/thread_native_basic.c:329
> #6  0x40b2d1ea in ClassLoader::LoadingClass::WaitLoading (this=0x81025b4) at classloader.h:122
> #7  0x40b2620c in ClassLoader::StartLoadingClass (this=0x808ba78, env=0x807c618, className=0x864f31c)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:600
> #8  0x40b291b9 in BootstrapClassLoader::DoLoadClass (this=0x808ba78, env=0x807c618, className=0x864f31c)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1427
> #9  0x40b2907b in ClassLoader::LoadClass (this=0x808ba78, env=0x807c618, className=0x864f31c)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1402
> #10 0x40b24f1e in ClassLoader::LoadVerifyAndPrepareClass (this=0x808ba78, env=0x807c618,
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:367
> #11 0x40b40a08 in Objects_To_Finalize::is_class_ignored (this=0x40de5020, test=0x85bea50)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/init/finalize.cpp:297
> #12 0x40b414d6 in Objects_To_Finalize::do_finalization (this=0x40de5020, quantity=0)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/init/finalize.cpp:502
> #13 0x40b41e7f in vm_do_finalization (quantity=0)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/init/finalize.cpp:630
> #14 0x40b43272 in finalizer_thread_func (args=0x85d4ec8)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/vmcore/src/init/finalizer_thread.cpp:241
> #15 0x4003f7cb in thread_start_proc (arg=0x85c6f58)
>     at /nfs/ims/proj/drl/mrt2/users/gregory/suse/trunk/working_vm/vm/thread/src/thread_native_basic.c:714
> #16 0x40798a13 in start_thread () from /lib/tls/libpthread.so.0
> #17 0x406439da in clone () from /lib/tls/libc.so.6

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

View raw message