Re: StreamDevice problem

["Davis, Mark via Tech-talk" <tech-talk@aps.anl.gov>]

Quick update on this problem:

Turns out that, with my modification to check for duplicate calls for an existing interface, that my local build DOES work.

Apparently our firewall rules where changed again, restricting things even more within our controls network, not allowing the connections I had defined.

But the question still remains: How/why are these redundant calls occurring?  Makes me wonder what other surprises there might be waiting...

Mark

Mark Davis NSCL/FRIB Control Systems Software Engineer davism50@msu.edu

On 10/8/2019 10:30 AM, Davis, Mark via Tech-talk wrote:

Having a bit of a problem with the StreamDevice interface that I am hoping someone can help with.

I am trying to get a working build working on a machine running debian stretch (9.9).

The version I am using is a copy of the latest on github, and I can get it to build, but when I run an IOC using the result something very odd is happening during the initialization of the objects for this library.

By adding a printf() call to the loop in the StreamBusInterfaceRegistrarBase(const char* name) constructor in StreamBusInterface.cc, I can see that it is normally called once for 3 derived interfaces:

• DebugInterface
• DummyInterface
• AsynDriverInterface

But for the build on my debian stretch machine, after these 3 calls occur, it is called again for the DebugInterface, which appears to cause an infinite loop (either stuck in the constructor, or calling it endlessly for the same interface.

If I move the "next = NULL;" statement to the end of the constructor, and add a check in the loop for a redundant call ("if *pr == this) return;", then I see that it is being called for the 1st 2 interfaces again, and it avoids the infinite loop, and the IOC processes the startup script, but the asyn connections for the StreamDevice interfaces never connect.

Anyone have any ideas what I should be looking at to determine how/why this is happening?

Mark Davis
NSCL/FRIB