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

[slibert]

Originally Posted by 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.

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]

Originally Posted by 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]

Originally Posted by 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.