You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by "Paul Hepworth (JIRA)" <xm...@xml.apache.org> on 2008/11/04 18:38:44 UTC
[jira] Created: (XMLBEANS-388) XmlBeans can Deadlock Threads
XmlBeans can Deadlock Threads
-----------------------------
Key: XMLBEANS-388
URL: https://issues.apache.org/jira/browse/XMLBEANS-388
Project: XMLBeans
Issue Type: Bug
Components: XmlObject
Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
Environment: Windows XP, Java 1.6
Reporter: Paul Hepworth
The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[jira] Updated: (XMLBEANS-388) XmlBeans can Deadlock Threads
Posted by "Paul Hepworth (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hepworth updated XMLBEANS-388:
-----------------------------------
Description:
The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
The attached code can produce the following:
run:
[java] Thread:main:RUNNABLE:true
[java] java.lang.Thread.dumpThreads:-2
[java] java.lang.Thread.getAllStackTraces:1487
[java] Deadlock.main:21
[java] Thread:Signal Dispatcher:RUNNABLE:true
[java] Thread:Finalizer:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.ref.ReferenceQueue.remove:116
[java] java.lang.ref.ReferenceQueue.remove:132
[java] java.lang.ref.Finalizer$FinalizerThread.run:159
[java] Thread:Reference Handler:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] java.lang.ref.Reference$ReferenceHandler.run:116
[java] Thread:Attach Listener:RUNNABLE:true
[java] Thread:Thread-0:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
[java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
[java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
[java] MyThread.run:49
[java] Thread:Thread-1:BLOCKED:true
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
[java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
[java] MyThread.run:48
[java] Java Result: 1
As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2049).
was:
The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> XmlBeans can Deadlock Threads
> -----------------------------
>
> Key: XMLBEANS-388
> URL: https://issues.apache.org/jira/browse/XMLBEANS-388
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
> Environment: Windows XP, Java 1.6
> Reporter: Paul Hepworth
>
> The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
> The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
> The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
> As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> The attached code can produce the following:
> run:
> [java] Thread:main:RUNNABLE:true
> [java] java.lang.Thread.dumpThreads:-2
> [java] java.lang.Thread.getAllStackTraces:1487
> [java] Deadlock.main:21
> [java] Thread:Signal Dispatcher:RUNNABLE:true
> [java] Thread:Finalizer:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.ref.ReferenceQueue.remove:116
> [java] java.lang.ref.ReferenceQueue.remove:132
> [java] java.lang.ref.Finalizer$FinalizerThread.run:159
> [java] Thread:Reference Handler:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] java.lang.ref.Reference$ReferenceHandler.run:116
> [java] Thread:Attach Listener:RUNNABLE:true
> [java] Thread:Thread-0:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
> [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
> [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
> [java] MyThread.run:49
> [java] Thread:Thread-1:BLOCKED:true
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
> [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
> [java] MyThread.run:48
> [java] Java Result: 1
> As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2049).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[jira] Updated: (XMLBEANS-388) XmlBeans can Deadlock Threads
Posted by "Paul Hepworth (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hepworth updated XMLBEANS-388:
-----------------------------------
Description:
The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
The attached code can produce the following:
run:
[java] Thread:main:RUNNABLE:true
[java] java.lang.Thread.dumpThreads:-2
[java] java.lang.Thread.getAllStackTraces:1487
[java] Deadlock.main:21
[java] Thread:Signal Dispatcher:RUNNABLE:true
[java] Thread:Finalizer:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.ref.ReferenceQueue.remove:116
[java] java.lang.ref.ReferenceQueue.remove:132
[java] java.lang.ref.Finalizer$FinalizerThread.run:159
[java] Thread:Reference Handler:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] java.lang.ref.Reference$ReferenceHandler.run:116
[java] Thread:Attach Listener:RUNNABLE:true
[java] Thread:Thread-0:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
[java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
[java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
[java] MyThread.run:49
[java] Thread:Thread-1:BLOCKED:true
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
[java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
[java] MyThread.run:48
[java] Java Result: 1
As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2054).
was:
The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
The attached code can produce the following:
run:
[java] Thread:main:RUNNABLE:true
[java] java.lang.Thread.dumpThreads:-2
[java] java.lang.Thread.getAllStackTraces:1487
[java] Deadlock.main:21
[java] Thread:Signal Dispatcher:RUNNABLE:true
[java] Thread:Finalizer:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.ref.ReferenceQueue.remove:116
[java] java.lang.ref.ReferenceQueue.remove:132
[java] java.lang.ref.Finalizer$FinalizerThread.run:159
[java] Thread:Reference Handler:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] java.lang.ref.Reference$ReferenceHandler.run:116
[java] Thread:Attach Listener:RUNNABLE:true
[java] Thread:Thread-0:WAITING:true
[java] java.lang.Object.wait:-2
[java] java.lang.Object.wait:485
[java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
[java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
[java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
[java] MyThread.run:49
[java] Thread:Thread-1:BLOCKED:true
[java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
[java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
[java] MyThread.run:48
[java] Java Result: 1
As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2049).
Updated the line number.
> XmlBeans can Deadlock Threads
> -----------------------------
>
> Key: XMLBEANS-388
> URL: https://issues.apache.org/jira/browse/XMLBEANS-388
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
> Environment: Windows XP, Java 1.6
> Reporter: Paul Hepworth
> Attachments: XmlBeansDeadlock.zip
>
>
> The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
> The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
> The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
> As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> The attached code can produce the following:
> run:
> [java] Thread:main:RUNNABLE:true
> [java] java.lang.Thread.dumpThreads:-2
> [java] java.lang.Thread.getAllStackTraces:1487
> [java] Deadlock.main:21
> [java] Thread:Signal Dispatcher:RUNNABLE:true
> [java] Thread:Finalizer:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.ref.ReferenceQueue.remove:116
> [java] java.lang.ref.ReferenceQueue.remove:132
> [java] java.lang.ref.Finalizer$FinalizerThread.run:159
> [java] Thread:Reference Handler:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] java.lang.ref.Reference$ReferenceHandler.run:116
> [java] Thread:Attach Listener:RUNNABLE:true
> [java] Thread:Thread-0:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
> [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
> [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
> [java] MyThread.run:49
> [java] Thread:Thread-1:BLOCKED:true
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
> [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
> [java] MyThread.run:48
> [java] Java Result: 1
> As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2054).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[jira] Updated: (XMLBEANS-388) XmlBeans can Deadlock Threads
Posted by "Cezar Andrei (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cezar Andrei updated XMLBEANS-388:
----------------------------------
Fix Version/s: Version 2.4.1
Assignee: Cezar Andrei
Paul, I checked in a fix for the deadlock bug when using generated setters.
The fix applies to generated setters of singletons and for setters of one item in an array.
> XmlBeans can Deadlock Threads
> -----------------------------
>
> Key: XMLBEANS-388
> URL: https://issues.apache.org/jira/browse/XMLBEANS-388
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
> Environment: Windows XP, Java 1.6
> Reporter: Paul Hepworth
> Assignee: Cezar Andrei
> Fix For: Version 2.4.1
>
> Attachments: XmlBeansDeadlock.zip
>
>
> The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
> The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
> The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
> As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> The attached code can produce the following:
> run:
> [java] Thread:main:RUNNABLE:true
> [java] java.lang.Thread.dumpThreads:-2
> [java] java.lang.Thread.getAllStackTraces:1487
> [java] Deadlock.main:21
> [java] Thread:Signal Dispatcher:RUNNABLE:true
> [java] Thread:Finalizer:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.ref.ReferenceQueue.remove:116
> [java] java.lang.ref.ReferenceQueue.remove:132
> [java] java.lang.ref.Finalizer$FinalizerThread.run:159
> [java] Thread:Reference Handler:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] java.lang.ref.Reference$ReferenceHandler.run:116
> [java] Thread:Attach Listener:RUNNABLE:true
> [java] Thread:Thread-0:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
> [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
> [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
> [java] MyThread.run:49
> [java] Thread:Thread-1:BLOCKED:true
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
> [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
> [java] MyThread.run:48
> [java] Java Result: 1
> As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2054).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[jira] Resolved: (XMLBEANS-388) XmlBeans can Deadlock Threads
Posted by "Cezar Andrei (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cezar Andrei resolved XMLBEANS-388.
-----------------------------------
Resolution: Fixed
Also the array setter has been fixed to avoid deadlock, but in the same time, with the current synchonize architecture the setter can not be atomic, i.e. thread safe. In order to make it thread safe the entire XMLBeans syncronization code must be changed so use generated array setters (setArrayXXX(GenXObj[] ) ) with caution in multi-threaded environments.
> XmlBeans can Deadlock Threads
> -----------------------------
>
> Key: XMLBEANS-388
> URL: https://issues.apache.org/jira/browse/XMLBEANS-388
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
> Environment: Windows XP, Java 1.6
> Reporter: Paul Hepworth
> Assignee: Cezar Andrei
> Fix For: Version 2.4.1
>
> Attachments: XmlBeansDeadlock.zip
>
>
> The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
> The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
> The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
> As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> The attached code can produce the following:
> run:
> [java] Thread:main:RUNNABLE:true
> [java] java.lang.Thread.dumpThreads:-2
> [java] java.lang.Thread.getAllStackTraces:1487
> [java] Deadlock.main:21
> [java] Thread:Signal Dispatcher:RUNNABLE:true
> [java] Thread:Finalizer:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.ref.ReferenceQueue.remove:116
> [java] java.lang.ref.ReferenceQueue.remove:132
> [java] java.lang.ref.Finalizer$FinalizerThread.run:159
> [java] Thread:Reference Handler:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] java.lang.ref.Reference$ReferenceHandler.run:116
> [java] Thread:Attach Listener:RUNNABLE:true
> [java] Thread:Thread-0:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
> [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
> [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
> [java] MyThread.run:49
> [java] Thread:Thread-1:BLOCKED:true
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
> [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
> [java] MyThread.run:48
> [java] Java Result: 1
> As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2054).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[jira] Updated: (XMLBEANS-388) XmlBeans can Deadlock Threads
Posted by "Paul Hepworth (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hepworth updated XMLBEANS-388:
-----------------------------------
Attachment: XmlBeansDeadlock.zip
Code attached that can produce the deadlock.
> XmlBeans can Deadlock Threads
> -----------------------------
>
> Key: XMLBEANS-388
> URL: https://issues.apache.org/jira/browse/XMLBEANS-388
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.3, Version 2.3.1, Version 2.4
> Environment: Windows XP, Java 1.6
> Reporter: Paul Hepworth
> Attachments: XmlBeansDeadlock.zip
>
>
> The situation can occur when calling a setter on an XmlObject which synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B at the same time as calling a setter on an XmlObject which synchronizes on Locale B to set an XmlObject which synchronizes on Locale A.
> The code within XmlObjectBase is fine, but the problem lies in the generated code compiled from a schema.
> The code that is generated contains a synchronized block on the monitor (Locale A or B depending on the object), and then delegates to the XmlObjectBase set method, which detects that you need to lock more than 1 Locale and so acquires a GlobalLock and then synchronizes on both monitors.
> As another thread can be doing the reverse, you can end up with 2 threads, one with Locale A locked, and one with Locale B locked. The first one then acquires a GlobalLock, but can never obtain a lock on the other Locale.
> The attached code can produce the following:
> run:
> [java] Thread:main:RUNNABLE:true
> [java] java.lang.Thread.dumpThreads:-2
> [java] java.lang.Thread.getAllStackTraces:1487
> [java] Deadlock.main:21
> [java] Thread:Signal Dispatcher:RUNNABLE:true
> [java] Thread:Finalizer:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.ref.ReferenceQueue.remove:116
> [java] java.lang.ref.ReferenceQueue.remove:132
> [java] java.lang.ref.Finalizer$FinalizerThread.run:159
> [java] Thread:Reference Handler:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] java.lang.ref.Reference$ReferenceHandler.run:116
> [java] Thread:Attach Listener:RUNNABLE:true
> [java] Thread:Thread-0:WAITING:true
> [java] java.lang.Object.wait:-2
> [java] java.lang.Object.wait:485
> [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
> [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
> [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
> [java] MyThread.run:49
> [java] Thread:Thread-1:BLOCKED:true
> [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
> [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
> [java] MyThread.run:48
> [java] Java Result: 1
> As you can see, one thread is waiting on the GlobalLock, and the other has the lock and is waiting for a lock on the other Locale (XmlObjectBase.set:2049).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org