You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexey Varlamov (JIRA)" <ji...@apache.org> on 2006/10/12 06:55:36 UTC
[jira] Created: (HARMONY-1833) [DRLVM] deadlock during finalization
[DRLVM] deadlock during finalization
------------------------------------
Key: HARMONY-1833
URL: http://issues.apache.org/jira/browse/HARMONY-1833
Project: Harmony
Issue Type: Bug
Components: DRLVM
Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
gcc 3.3.3 drlvm debug build
Reporter: Alexey Varlamov
The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
1) MT performs classloading, it grabs ClassLoader::_lock;
2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12441618 ]
Alexey Varlamov commented on HARMONY-1833:
------------------------------------------
1) I believe this scenario can be fixed via separating locks for classloading and loader-pool allocations.
2) Chances for deadlock can be lowered a bit if Java_java_lang_VMClassRegistry_getSystemPackages() does not hold bootstrap classloader lock while allocating in Java heap (say copies table of system packages in native heap and releases the lock).
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12444471 ]
Geir Magnusson Jr commented on HARMONY-1833:
--------------------------------------------
Pavel, do you agree with patch?
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12445649 ]
Pavel Pervov commented on HARMONY-1833:
---------------------------------------
Now the patch is ok.
Still, to my thinking, malloc'ing small local blocks is not a good practice.
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12441616 ]
Alexey Varlamov commented on HARMONY-1833:
------------------------------------------
Thread 2: compiles java/util/zip/ZipFile.finalize()
#11 0x40b7f3bc in Lock_Manager::_lock (this=0x8083098)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/thread/lock_manager.cpp:62
(gdb) p ((apr_thread_mutex_t *)lock)->mutex
$8 = {
__m_reserved = 2,
__m_count = 1,
__m_owner = 0x61e7,
__m_kind = 1,
__m_lock = {
__status = 1,
__spinlock = 0
}
}
Thread 1: compiles java/lang/FinalizerThread.spawnBalanceThreads()
#9 0x414e9e18 in Jitrino::Mutex::lock (this=0x417aaca8) at mkernel.h:111
111 void lock(void) { pthread_mutex_lock(&m_handle); }
(gdb) p m_handle
$10 = {
__m_reserved = 2,
__m_count = 1,
__m_owner = 0x61f9,
__m_kind = 1,
__m_lock = {
__status = 1,
__spinlock = 0
}
}
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12444601 ]
Pavel Pervov commented on HARMONY-1833:
---------------------------------------
Almost.
I would made two changes here:
1) (insist) change "size_t name_len = strlen(name);" to "size_t name_len = (*it).first->len;", as package name length is already available and there is no need to calculate it once again.
2) (recommend) change "char* buf = (char*)STD_MALLOC(buf_len + 1);" to "char* buf = (char*)STD_ALLOCA(buf_len + 1);" and remove corresponding "STD_FREE(buf);". Although, it is called only once, but there is no need to defragment heap. :)
Other than that everything is ok.
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-1833) [DRLVM] deadlock during finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Alexey Varlamov updated HARMONY-1833:
-------------------------------------
Attachment: H-1833.patch
Fixed the deadlock and corrected OOME handling in the loop.
JNDI tests seems to pass now.
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12441617 ]
Alexey Varlamov commented on HARMONY-1833:
------------------------------------------
Java stack of Thread 1
[junit] [0x80a9f58] 0x538b6a18(m): java/lang/FinalizerThread.startFinalization(Z)V
[junit] [0x80a9f58] 0x40b0fdc5(n): java/lang/VMClassRegistry.getSystemPackages(I)[[Ljava/lang/String;
[junit] [0x80a9f58] 0x41162c57(m): java/lang/ClassLoader$BootstrapLoader.updatePackages()V
[junit] [0x80a9f58] 0x41162a7b(m): java/lang/ClassLoader$BootstrapLoader.getPackage(Ljava/lang/String;)Ljava/lang/Package;
[junit] [0x80a9f58] 0x41162812(m): java/lang/ClassLoader.getPackage(Ljava/lang/String;)Ljava/lang/Package;
[junit] [0x80a9f58] 0x411508e4(m): java/net/URLClassLoader.findClassImpl([Ljava/net/URL;Ljava/lang/String;)Ljava/lang/Class;
[junit] [0x80a9f58] 0x4114ea08(m): java/net/URLClassLoader$4.run()Ljava/lang/Class;
[junit] [0x80a9f58] 0x4114e961(m): java/net/URLClassLoader$4.run()Ljava/lang/Object;
[junit] [0x80a9f58] 0x410e6b69(m): java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
[junit] [0x80a9f58] 0x4114e8cb(m): java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
[junit] [0x80a9f58] 0x4114e637(m): java/net/URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;
[junit] [0x80a9f58] 0x41147b69(m): java/lang/ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;
[junit] [0x80a9f58] 0x411479d5(m): java/net/URLClassLoader$SubURLClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;
[junit] [0x80a9f58] 0x4114780a(m): java/lang/ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;
[junit] [0x80a9f58] 0x411394c1(m): java/lang/Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;
[junit] [0x80a9f58] 0x538b67ef(m): javax/naming/spi/NamingManager$1.run()Ljava/lang/Class;
[junit] [0x80a9f58] 0x538b6701(m): javax/naming/spi/NamingManager$1.run()Ljava/lang/Object;
[junit] [0x80a9f58] 0x410e6b69(m): java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12441667 ]
Pavel Pervov commented on HARMONY-1833:
---------------------------------------
The root cause is holding native DRLVM internal lock while calling to JNI. Should be fixed there.
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Geir Magnusson Jr reassigned HARMONY-1833:
------------------------------------------
Assignee: Geir Magnusson Jr
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Assigned To: Geir Magnusson Jr
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-1833) [DRLVM] deadlock during finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Alexey Varlamov updated HARMONY-1833:
-------------------------------------
Attachment: H-1833.patch
Agreed about #1, fixed.
As for the #2, I'm not for premature optimization - let's leave it as is for now.
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-1833) [DRLVM] deadlock during finalization
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Geir Magnusson Jr closed HARMONY-1833.
--------------------------------------
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Assigned To: Geir Magnusson Jr
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Geir Magnusson Jr resolved HARMONY-1833.
----------------------------------------
Resolution: Fixed
r471196
Ubuntu 6 - smoke, c-unit-, ~kernel
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Assigned To: Geir Magnusson Jr
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-1833) [DRLVM] deadlock during finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=all ]
Alexey Varlamov updated HARMONY-1833:
-------------------------------------
Patch Info: [Patch Available]
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
> Attachments: H-1833.patch, H-1833.patch
>
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1833) [DRLVM] deadlock during
finalization
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1833?page=comments#action_12441614 ]
Alexey Varlamov commented on HARMONY-1833:
------------------------------------------
Some more details with gdb:
3 Thread 1083587504 (LWP 25067=0x61eb) 0xffffe410 in __kernel_vsyscall ()
2 Thread 1390042032 (LWP 25081=0x61f9) 0xffffe410 in __kernel_vsyscall ()
1 Thread 1080381568 (LWP 25063=0x61e7) 0xffffe410 in __kernel_vsyscall ()
Thread 3 (Thread 1083587504 (LWP 25067)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x40469eae in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2 0x40466c6c in _L_mutex_lock_88 () from /lib/tls/libpthread.so.0
#3 0x4000ce56 in fixup () from /lib/ld-linux.so.2
#4 0x4003dbf3 in hymutex_lock (mutex=0x805d148)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/thread/src/thread_native_mutex.c:72
#5 0x4003cf2d in hythread_monitor_enter (mon_ptr=0x805d110)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/thread/src/thread_native_fat_monitor.c:96
#6 0x4002656d in asynchSignalReporter ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so
#7 0x4003c9e4 in thread_start_proc (thd=0x80626a8, p_args=0x8062698)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/thread/src/thread_native_basic.c:713
#8 0x40042ac1 in dummy_worker (opaque=0xfffffffc) at thread.c:138
#9 0x40465a13 in start_thread () from /lib/tls/libpthread.so.0
#10 0x405279da in clone () from /lib/tls/libc.so.6
Thread 2 (Thread 1390042032 (LWP 25081)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x40469eae in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2 0x40466c6c in _L_mutex_lock_88 () from /lib/tls/libpthread.so.0
#3 0x00000003 in ?? ()
#4 0xffffff2c in ?? ()
#5 0x40d76900 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so
#6 0x52da4cfc in ?? ()
#7 0x417f4dd8 in Jitrino::Jet::Stats::locals_max_name ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default//libjitrino.so
#8 0x52da3ab4 in ?? ()
#9 0x4003dbf3 in hymutex_lock (mutex=0x805d5d4)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/thread/src/thread_native_mutex.c:72
#10 0x4003dbf3 in hymutex_lock (mutex=0x805d5d0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/thread/src/thread_native_mutex.c:72
#11 0x40b7f3bc in Lock_Manager::_lock (this=0x8083098)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/thread/lock_manager.cpp:62
#12 0x40acdfd2 in ClassLoader::Lock (this=0x8083070) at classloader.h:215
#13 0x40acc9bc in ClassLoader::Alloc (this=0x8083070, size=236) at classloader.h:262
#14 0x40ac06bc in Class_Member::Alloc (this=0x52e6dee0, size=236)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/Class_File_Loader.cpp:610
#15 0x40b83a73 in Method::create_code_chunk_info_mt (this=0x52e6dee0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/method.cpp:407
#16 0x40b83b4e in Method::get_chunk_info_mt (this=0x52e6dee0, jit=0x80912b8, id=0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/method.cpp:437
#17 0x40b8381c in Method::allocate_code_block_mt (this=0x52e6dee0, size=136, alignment=16, jit=0x80912b8,
heat=1, id=0, action=CAA_Allocate)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/method.cpp:346
#18 0x40ab56cf in method_allocate_code_block (m=0x52e6dee0, j=0x80912b8, size=136, alignment=16, heat=1,
id=0, action=CAA_Allocate)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/C_Interface.cpp:307
#19 0x41666830 in Jitrino::Jet::Compiler::compile (this=0x52da4cfc, ch=0x52da51fc, method=0x52e6dee0,
params=@0x52da4ea8)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/jet/compiler.cpp:440
#20 0x416c154a in Jitrino::Jet::compile_with_params (jit_handle=0x80912b8, ch=0x52da51fc,
method=0x52e6dee0, params=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/jet/jet.cpp:508
#21 0x414e7f1d in JIT_compile_method_with_params (jit=0x80912b8, compilation=0x52da51fc,
method_handle=0x52e6dee0, compilation_params=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/vm/drl/DrlJITInterface.cpp:277
#22 0x40b08519 in Dll_JIT::compile_method_with_params (this=0x80912b8, compilation=0x52da51fc,
method=0x52e6dee0, flags=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0}) at dll_jit_intf.h:86
#23 0x40b0018d in compile_do_compilation_jit (method=0x52e6dee0, jit=0x80912b8)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:700
#24 0x40ababf1 in vm_compile_method (jit=0x80912b8, method=0x52e6dee0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/C_Interface.cpp:2538
#25 0x410b2b11 in DrlEMImpl::compileMethod (this=0x80911c8, mh=0x52e6dee0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/DrlEMImpl.cpp:520
#26 0x410cb3e6 in CompileMethod (method_handle=0x52e6dee0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/em_intf.cpp:49
#27 0x40b0054d in compile_do_compilation (method=0x52e6dee0, flags=
{insert_write_barriers = 0, opt_level = 4, dynamic_profile = 0})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:780
#28 0x40b008f3 in compile_jit_a_method (method=0x52e6dee0)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:828
#29 0x410d0172 in ?? ()
#30 0x52e6dee0 in ?? ()
#31 0x52da56cc in ?? ()
#32 0x086498e8 in ?? ()
#33 0x00000000 in ?? ()
#34 0x00000000 in ?? ()
#35 0x00000082 in ?? ()
#36 0x00000000 in ?? ()
#37 0xdeadbeef in ?? ()
#38 0x418d7a80 in ?? ()
#39 0x40d76900 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so
#40 0x52da548c in ?? ()
#41 0x40b0fdc5 in vm_invoke_native_array_stub () at jvmti_direct.h:61
#42 0x40b0f79f in JIT_execute_method_default (jit=0x0, methodID=0x52e6dee0, return_value=0x0,
args=0x52da5634)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/util/ia32/base/ini_iA32.cpp:199
#43 0x410b27a5 in DrlEMImpl::executeMethod (this=0x80911c8, meth=0x52e6dee0, return_value=0x0,
args=0x52da5634) at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/DrlEMImpl.cpp:489
#44 0x410cb3af in ExecuteMethod (meth=0x52e6dee0, return_value=0x0, args=0x52da5634)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/em_intf.cpp:43
#45 0x40b0f0d4 in vm_execute_java_method_array (method=0x52e6dee0, result=0x0, args=0x52da5634)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/ini.cpp:58
#46 0x40b0e0f5 in Objects_To_Finalize::do_finalization (this=0x40d7db40, quantity=128)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/init/finalize.cpp:395
#47 0x40b0e883 in vm_do_finalization (quantity=128)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/init/finalize.cpp:477
#48 0x40b11a38 in Java_java_lang_FinalizerThread_doFinalization (quantity=128)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/kernel_classes/native/java_lang_FinalizerThread.cpp:62
#49 0x4114c13d in ?? ()
#50 0x080aa090 in ?? ()
#51 0x52da56a8 in ?? ()
#52 0x00000080 in ?? ()
#53 0x00020009 in ?? ()
#54 0x00000000 in ?? ()
#55 0x41a4e300 in ?? ()
#56 0x418d693c in ?? ()
#57 0x40d76900 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so
#58 0x52da56d4 in ?? ()
#59 0x40b9be1d in get_thread_ptr_stub ()
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/thread/thread_manager.cpp:134
Previous frame inner to this frame (corrupt stack?)
Thread 1 (Thread 1080381568 (LWP 25063)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x40469eae in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2 0x40466c6c in _L_mutex_lock_88 () from /lib/tls/libpthread.so.0
#3 0x00000000 in ?? ()
#4 0x00000000 in ?? ()
#5 0x4179a8a8 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default//libjitrino.so
#6 0x52fd5c4c in ?? ()
#7 0x417f4dd8 in Jitrino::Jet::Stats::locals_max_name ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default//libjitrino.so
#8 0xbfff9648 in ?? ()
#9 0x414e9e18 in Jitrino::Mutex::lock (this=0x417aaca8) at mkernel.h:111
#10 0x414e9e18 in Jitrino::Mutex::lock (this=0x417aaca8) at mkernel.h:111
#11 0x416666ce in Jitrino::Jet::Compiler::compile (this=0xbfffa740, ch=0xbfffac40, method=0x8629e40,
params=@0xbfffa8ec)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/jet/compiler.cpp:421
#12 0x416c154a in Jitrino::Jet::compile_with_params (jit_handle=0x80912b8, ch=0xbfffac40, method=0x8629e40,
params=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/jet/jet.cpp:508
#13 0x414e7f1d in JIT_compile_method_with_params (jit=0x80912b8, compilation=0xbfffac40,
method_handle=0x8629e40, compilation_params=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/jitrino/src/vm/drl/DrlJITInterface.cpp:277
#14 0x40b08519 in Dll_JIT::compile_method_with_params (this=0x80912b8, compilation=0xbfffac40,
method=0x8629e40, flags=
{exe_notify_method_entry = 0, exe_notify_method_exit = 0, exe_notify_field_access = 0, exe_notify_field_modification = 0, exe_notify_exception_throw = 0, exe_notify_exception_catch = 0, exe_notify_monitor_enter = 0, exe_notify_monitor_exit = 0, exe_notify_contended_monitor_enter = 0, exe_notify_contended_monitor_exit = 0, exe_do_method_inlining = 0, exe_do_code_mapping = 0, exe_do_local_var_mapping = 0, exe_insert_write_barriers = 0, exe_provide_access_to_this = 0, exe_restore_context_after_unwind = 0}) at dll_jit_intf.h:86
#15 0x40b0018d in compile_do_compilation_jit (method=0x8629e40, jit=0x80912b8)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:700
#16 0x40ababf1 in vm_compile_method (jit=0x80912b8, method=0x8629e40)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/C_Interface.cpp:2538
#17 0x410b2b11 in DrlEMImpl::compileMethod (this=0x80911c8, mh=0x8629e40)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/DrlEMImpl.cpp:520
#18 0x410cb3e6 in CompileMethod (method_handle=0x8629e40)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/em/src/em_intf.cpp:49
#19 0x40b0054d in compile_do_compilation (method=0x8629e40, flags=
{insert_write_barriers = 0, opt_level = 7, dynamic_profile = 1})
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:780
#20 0x40b008f3 in compile_jit_a_method (method=0x8629e40)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/jit/compile.cpp:828
#21 0x410d0172 in ?? ()
#22 0x08629e40 in ?? ()
#23 0xbfffb3d0 in ?? ()
#24 0x080aa020 in ?? ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00000082 in ?? ()
#28 0x00000000 in ?? ()
#29 0xdeadbeef in ?? ()
#30 0xbfffafe0 in ?? ()
#31 0x00000000 in ?? ()
#32 0xbfffafac in ?? ()
#33 0x538b6a18 in ?? ()
#34 0x0805ce50 in ?? ()
#35 0xdeadbeef in ?? ()
#36 0xdeadbeef in ?? ()
#37 0xdeadbeef in ?? ()
#38 0x00000000 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000000 in ?? ()
#42 0xdeadbeef in ?? ()
#43 0xdeadbeef in ?? ()
#44 0xdeadbeef in ?? ()
#45 0xdeadbeef in ?? ()
#46 0xdeadbeef in ?? ()
#47 0xdeadbeef in ?? ()
#48 0xdeadbeef in ?? ()
#49 0xdeadbeef in ?? ()
#50 0xdeadbeef in ?? ()
#51 0xdeadbeef in ?? ()
#52 0xdeadbeef in ?? ()
#53 0xdeadbeef in ?? ()
#54 0xdeadbeef in ?? ()
#55 0xdeadbeef in ?? ()
#56 0xdeadbeef in ?? ()
#57 0xdeadbeef in ?? ()
#58 0xdeadbeef in ?? ()
#59 0xdeadbeef in ?? ()
#60 0xdeadbeef in ?? ()
#61 0xdeadbeef in ?? ()
#62 0xdeadbeef in ?? ()
#63 0xdeadbeef in ?? ()
#64 0xdeadbeef in ?? ()
#65 0xdeadbeef in ?? ()
#66 0xdeadbeef in ?? ()
#67 0xdeadbeef in ?? ()
#68 0xdeadbeef in ?? ()
#69 0xdeadbeef in ?? ()
#70 0xdeadbeef in ?? ()
#71 0x40d76900 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so
#72 0xdeadbeef in ?? ()
#73 0xdeadbeef in ?? ()
#74 0xdeadbeef in ?? ()
#75 0xdeadbeef in ?? ()
#76 0xbfffafc0 in ?? ()
#77 0xdeadbeef in ?? ()
#78 0xdeadbeef in ?? ()
#79 0xdeadbeef in ?? ()
#80 0xdeadbeef in ?? ()
#81 0xdeadbeef in ?? ()
#82 0xdeadbeef in ?? ()
#83 0xdeadbeef in ?? ()
#84 0xdeadbeef in ?? ()
#85 0xdeadbeef in ?? ()
#86 0xdeadbeef in ?? ()
#87 0xdeadbeef in ?? ()
#88 0xdeadbeef in ?? ()
#89 0xdeadbeef in ?? ()
#90 0xdeadbeef in ?? ()
#91 0xdeadbeef in ?? ()
#92 0xdeadbeef in ?? ()
#93 0x40b0fdc5 in vm_invoke_native_array_stub () at jvmti_direct.h:61
#94 0x00000000 in ?? ()
#95 0xdeadbeef in ?? ()
#96 0xbfffafe0 in ?? ()
#97 0x40d76900 in __JCR_LIST__ ()
from /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so
#98 0xbfffb060 in ?? ()
#99 0x40b0f79f in JIT_execute_method_default (jit=0x55909090, methodID=0x4d8be589, return_value=0xc458b08,
args=0xba04c083)
at /export/users2/avarlamo/linux.ia32/svn-repo/drlvm/vm/vmcore/src/util/ia32/base/ini_iA32.cpp:199
Previous frame inner to this frame (corrupt stack?)
> [DRLVM] deadlock during finalization
> ------------------------------------
>
> Key: HARMONY-1833
> URL: http://issues.apache.org/jira/browse/HARMONY-1833
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: SLES 9 32-bit SP2; CPU 2xXeon x64
> gcc 3.3.3 drlvm debug build
> Reporter: Alexey Varlamov
>
> The classlib tests hang sporadically, usually in JNDI module when running all classlib unit tests (single runs of JNDI alone always ok).
> Investigation shows that there are deadlocks happening between main thread (MT) and finalizer thread (FT):
> 1) MT performs classloading, it grabs ClassLoader::_lock;
> 2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
> 3) FT invokes some finalize() method, compilation starts and grabs g_compileLock;
> 4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
> 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() and waits for g_compileLock;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira