Calling LiveWindow::GetInstance() during static initialization causes program crash

[William Kunkel]

I've been trying out a new way of organizing my team's code, which involves initializing subsystems during static initialization. Unfortunately, if I initialize a Talon statically in a namespace, the program crashes. Monitoring the output via netconsole gives this:


* Loading FRC_UserProgram.out: FRC_UserProgram


[NT] NetworkTable::GetTable()...

[NT] Initializing...

[NT] NetworkTable::CheckInit()...

[NT] NetworkTable::Initialize()...



program

Exception current instruction address: 0x00000000

Machine Status Register: 0x0008b012

Condition Register: 0x24004282

Task: 0xb6ec60 "Main Application Thread"

0xb6ec60 (Main Application Thread): task 0xb6ec60 has had a failure and has been stopped.

0xb6ec60 (Main Application Thread): fatal kernel task-level exception!


That last message before the exception comes right before this function call in the NetworkTables code:


staticProvider = new NetworkTableProvider(*(staticNode = mode->CreateNode(ipAddress.c_str(), port, threadManager, streamFactory, streamDeleter, typeManager)));


Which is called because a NetworkTable::GetTable() call in LiveWindow::LiveWindow() called by LiveWindow::GetInstance() checks to see if NetworkTable::staticProvider is NULL, and if so, creates it. Moving the initialization to the RobotInit() function fixes the problem, and the messages related to setting NetworkTable::staticProvider are not displayed. So basically, my question is this: Where does NetworkTable::staticProvider get set, and is there a way around this, short of intializing in RobotInit?

[Joe Ross]

This sounds similar to the following bug, although no details are given: http://firstforge.wpi.edu/sf/go/artf1653 or maybe this one: http://firstforge.wpi.edu/sf/go/artf1644

[William Kunkel]

Yeah, it looks like those are the same issue. I wonder if there's any plan to address that in the near future.

[SoftwareBug2.0]

Where does NetworkTable::staticProvider get set, and is there a way around this, short of intializing in RobotInit?

None of the initialization rules are documented as far as I can tell. If anyone comes across something that says what they are I would love to know too.

[BradAMiller]

There's an issue where statically initialized classes are not created in any specific order. So that means that variables, in particular, lists of the sensors and speed controllers might not have been initialized when the static classes are created.

The best solution is to try to not create WPILib objects statically and instead make them class members. Then you can initialize them from the heap using new or as class members. This makes sure that they don't get initialized before the underlying WPILib code starts up.

But we're looking at the problem now. May be an update.

[William Kunkel]

Just curious, what variables are actually being initialized statically to cause this bug? I couldn't seem to track them down.

[slibert]

There's an issue where statically initialized classes are not created in any specific order. So that means that variables, in particular, lists of the sensors and speed controllers might not have been initialized when the static classes are created.

The best solution is to try to not create WPILib objects statically and instead make them class members. Then you can initialize them from the heap using new or as class members. This makes sure that they don't get initialized before the underlying WPILib code starts up.

But we're looking at the problem now. May be an update.

I ran into this issue making a very simple robot program using the "SimpleTemplate". So it has a class (RobotDemo) derived from SimpleRobot that's initialized via START_ROBOT_CLASS(RobotDemo).

SimpleRobot's constructor invokes base class RobotBase constructor, which invokes DriverStation::GetInstance(), which ultimately leads to NetworkTables::Initialize() which crashes for the reasons described herein.

So unless I'm missing something obvious, the current C++ RobotBase is unusable, since it has to be statically initialized via START_ROBOT_CLASS.

I'd love to know if there's a work around for this; it seems like a pretty serious problem that's got me stopped in my tracks....

[slibert]

I ran into this issue making a very simple robot program using the "SimpleTemplate". So it has a class (RobotDemo) derived from SimpleRobot that's initialized via START_ROBOT_CLASS(RobotDemo).

SimpleRobot's constructor invokes base class RobotBase constructor, which invokes DriverStation::GetInstance(), which ultimately leads to NetworkTables::Initialize() which crashes for the reasons described herein.

So unless I'm missing something obvious, the current C++ RobotBase is unusable, since it has to be statically initialized via START_ROBOT_CLASS.

I'd love to know if there's a work around for this; it seems like a pretty serious problem that's got me stopped in my tracks....

FWIW, the issue seems to be that the virtual table for the static NetworkTableMode::Server object (an instance of NetworkTableServerMode class) is not yet initialized when NetworkTables::Initialize() is invoked; when NetworkTables::Initialize() attempts to use the NetworkTableServerMode object to invoke the virtual member function CreateNode(), the virtual table for the Server object hasn't yet been initialized because the NetworkTableServerMode constructor hasn't yet been invoked. So as Greg said, it's unordered static object construction that's causing it. However, it's happening within the WPILibrary itself (from within the RobotBase constructor), rather than in our robot code.

[slibert]

FWIW, the issue seems to be that the virtual table for the static NetworkTableMode::Server object (an instance of NetworkTableServerMode class) is not yet initialized when NetworkTables::Initialize() is invoked; when NetworkTables::Initialize() attempts to use the NetworkTableServerMode object to invoke the virtual member function CreateNode(), the virtual table for the Server object hasn't yet been initialized because the NetworkTableServerMode constructor hasn't yet been invoked. So as Greg said, it's unordered static object construction that's causing it. However, it's happening within the WPILibrary itself (from within the RobotBase constructor), rather than in our robot code.

Final Update: Looks like I goofed.

I believe this was happening because I was using a project created with last year's Sample Project creator in WindRiver, even though I'd updated to the latest 2014 release of the FRC C++ Update.

When I recreated the project (same process, but it was created after the 2014 update was installed into windriver), I'm not seeing this issue.

My apologies if I've wasted anyone's energy or time.