Project

General

Profile

Actions
Copy link

Bug #6577

closed

infinite loop resolving port width

Added by Daniel Crawl over 10 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Daniel Crawl
Category:
actors
Target version:
2.5.0
Start date:
07/09/2014
Due date:
% Done:

90%

Estimated time:
Spent time:
0.25 h
Bugzilla-Id:

Description

There are several actors whose output port is set to multiport. When this port is connected to a multiport input port, an error occurs when the workflow executes saying that the default port width could not be determined. The error message says that one way to fix this is call setDefaultPortWidth(1). This works if the output port is connected to only one port, but if the output port is connected to more ports, an infinite loop occurs during preinitialize(). I'm attaching an example workflow.

Files

Download all files
InfiniteLoop1.xml (26.9 KB) InfiniteLoop1.xml Daniel Crawl, 07/09/2014 04:06 PM
MultiportOutHangDuringGetWidth.xml (5.07 KB) MultiportOutHangDuringGetWidth.xml Christopher Brooks, 08/17/2015 08:53 AM
Actions
Copy link
 #1

Updated by Daniel Crawl over 9 years ago

I just checked, and this still occurs.

Actions
Copy link
 #2

Updated by Daniel Crawl over 9 years ago

  • Category set to actors
  • Assignee set to Christopher Brooks

I'm reassigning to Christopher since this problem is in Ptolemy. The attached workflow reproduces the problem.

Actions
Copy link
 #3

Updated by Christopher Brooks over 9 years ago

I can replicate this in Ptolemy, outside of Kepler.

It seems that the problem has to do with having more than one Display actor connected to a multiport output.

The attached model (MultiportOutHangDuringGetWidth.xml) replicates the problem using the Minimum actor, which has a multiport output connected to two Display actors.

The model hangs in preinitialize():

at java.util.LinkedList.addAll(LinkedList.java:408)
        at java.util.LinkedList.addAll(LinkedList.java:387)
        at java.util.LinkedList.<init>(LinkedList.java:119)
        at ptolemy.actor.RelationWidthInference.inferWidths(RelationWidthInference.java:338\
)
        at ptolemy.actor.CompositeActor.inferWidths(CompositeActor.java:824)
        at ptolemy.actor.IORelation.getWidth(IORelation.java:325)
        at ptolemy.actor.IOPort._getWidth(IOPort.java:4999)
        at ptolemy.actor.IOPort.getWidth(IOPort.java:1952)
        at ptolemy.actor.IOPort._getReceivers(IOPort.java:4859)
        at ptolemy.actor.IOPort.getReceivers(IOPort.java:1754)
        at ptolemy.actor.IOPort.getInsideReceivers(IOPort.java:1365)
        at ptolemy.domains.sdf.kernel.SDFScheduler._scheduleConnectedActors(SDFScheduler.ja\
va:1513)
        at ptolemy.domains.sdf.kernel.SDFScheduler._getSchedule(SDFScheduler.java:585)
        at ptolemy.actor.sched.Scheduler.getSchedule(Scheduler.java:189)
        at ptolemy.domains.sdf.kernel.SDFDirector.createSchedule(SDFDirector.java:408)
        at ptolemy.domains.sdf.kernel.SDFDirector.preinitialize(SDFDirector.java:761)
    at ptolemy.actor.CompositeActor.preinitialize(CompositeActor.java:1820)

However, $PTII/ptolemy/actor/lib/test/auto/MinimumMultiports.xml does not hang.

It has the Minimum actor connected to Test actors instead of Display.

I tried reverse type inference on my test case, but that did not change anything.

I'll see if I can get Edward's input.

Actions
Copy link
 #4

Updated by Christopher Brooks over 9 years ago

  • Assignee changed from Christopher Brooks to Daniel Crawl
  • % Done changed from 20 to 90

I checked a copy of MultiportOutHangDuringGetWidth.xml in to $PTII/ptolemy/actor
/lib/test/auto

I think this is fixed.

I'm redispatching to Dan.

Edward wrote:
--start--
"I found a logic error in the width inference algorithm and have checked in a fix."

"Note that nevertheless one should not be making output ports multiports to accomplish broadcast."
"The ones in the Ptolemy tree that do this are legacy. E.g., Maximum.java says:" 

/* Note that the output ports need not be multiports since all output
 * channels carry the same data. Using multiports this way is not
 * recommended, so please do not emulate this design in your own actors.
 * Changing this actor to the recommended design would break existing
 * models, so we leave it as is.
         */

"Instead of making output ports multiports, model builders should create a relation and fork the output from there."
--end--

Actions
Copy link
 #5

Updated by Daniel Crawl over 9 years ago

  • Status changed from New to Resolved

Fixed!

Actions
Copy link

Also available in: Atom PDF