Kepler

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$ListItr.next(Unknown Source)
        at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
        at ptolemy.kernel.util.NamedObj.attributeList(NamedObj.java:365)
        at ptolemy.vergil.actor.ActorGraphModel$PortModel.getParent(ActorGraphM
del.java:1513)
        at diva.graph.modular.ModularGraphModel.getParent(ModularGraphModel.jav
:107)
        at diva.graph.GraphUtilities.isContainedNode(GraphUtilities.java:156)
        at diva.graph.GraphUtilities.isPartiallyContainedEdge(GraphUtilities.ja
a:187)
        at diva.graph.AbstractGraphController.rerender(AbstractGraphController.
ava:295)
        at diva.graph.AbstractGraphController$ChangeListener.structureChanged(A
stractGraphController.java:638)
        at diva.graph.toolbox.GraphEventMulticaster.structureChanged(GraphEvent
ulticaster.java:154)
        at diva.graph.toolbox.GraphEventMulticaster.dispatchEvent(GraphEventMul
icaster.java:86)
        at diva.graph.AbstractGraphModel$1.run(AbstractGraphModel.java:79)
        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 java.awt.EventDispatchThread.run(Unknown Source)

Thomas Feng wrote:
--start--
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.
--end--

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