Bug #3255

Diva ConcurrentModificationException

Added by Christopher Brooks about 11 years ago. Updated about 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I'm seeing the following stack trace in the DOS window when
I run the Kepler-1.0.0 installer on a Windows 2003 Server that has
multiple cores:

Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationExceptio

at java.util.LinkedList$ListItr.checkForComodification(Unknown Source)
at java.util.LinkedList$ Source)
at java.util.Collections$UnmodifiableCollection$ Source)
at ptolemy.kernel.util.NamedObj.attributeList(
at diva.graph.modular.ModularGraphModel.getParent(ModularGraphModel.jav
at diva.graph.GraphUtilities.isContainedNode(
at diva.graph.GraphUtilities.isPartiallyContainedEdge(GraphUtilities.ja
at diva.graph.AbstractGraphController.rerender(AbstractGraphController.
at diva.graph.AbstractGraphController$ChangeListener.structureChanged(A
at diva.graph.toolbox.GraphEventMulticaster.structureChanged(GraphEvent
at diva.graph.toolbox.GraphEventMulticaster.dispatchEvent(GraphEventMul
at diva.graph.AbstractGraphModel$
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at Source)

Thomas Feng wrote:
I saw this exception more often when using the TransformationAttribute
(the one I showed yesterday for regression testing) on a dual-core
Vista machine. But when I used another computer that did not have dual
core, the problem never showed up. I thought it was a bug in GT, so I
went ahead and fixed a few places by adding getReadAccess() and
doneReading(). This reduced the number of exceptions on the dual-core
machine, but it still happened.

I then ran some very simple SDF models, and still got the exception in
my command console. Those models were just as simple as two Ramps
connected to a Display. I really wonder how this happens. Maybe
someone does attributeList() and use the returned list without
protecting the whole transaction with getReadAccess()? This kind of
bugs are really hard to trace. We could modify the attributeList()
function to return a list that logs every operation on it, though.

This is probably my fault, I'll take a look.

Related issues

Blocked by Kepler - Bug #3245: Release 1.0 installer tracking bugResolved04/29/2008


#1 Updated by Chad Berkley about 11 years ago

You're seeing this when you run the installer or a specific workflow?

#2 Updated by Christopher Brooks about 11 years ago

I saw it with the Kepler 1.0.0 kepler.exe
I can't repeat it. I was trying
However, I think it is more generic and
can happen for any demo on a multi-core machine.

#3 Updated by Christopher Brooks about 11 years ago

I think I've narrowed down the problem and hope to have a solution tonight
or tomorrow. I posted my notes to the ptdevel list, I think it has
to do with data.expr.TemporaryVariable not grabbing a lock when it
adds itself to the container.

#4 Updated by Christopher Brooks about 11 years ago

I've checked in a fix to ptolemy.kernel.util.Attribute.
Basically, if incrementWorkspaceVersion is false, then get write Access to
the workspace because we are updating the _attributes field of the

#5 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 3255

Also available in: Atom PDF