No Robot Code may be caused by link error

[kenfox]

We had a problem running C++ code on the robot. The project built and deployed without errors. We could FTP to the cRIO and verify the out file matched what we deployed. The driver station had communication, but did not have robot code.

The problem was a declared but undefined static class variable that prevented VxWorks from loading the out file. Link errors don't appear to be logged anywhere. I couldn't see the error in Net Console.

We found the problem by setting up a debug target and running in debug mode. The instructions at http://wpilib.screenstepslive.com/s/...-robot-program worked great. When WindRiver tried to attach to our code, it showed an error dialog with the name of the undefined variable. It was name mangled, but pretty easy to figure out. The program "c++filtppc" will unmangle names for you if you can't figure out the C++ variable from the mangled name.

Here's an example of a static class variable declaration (in the h file):

class MyRobot: public IterativeRobot {
public:
  static MySubsystem* mySubsystem;
};

And here's the definition that we were missing (in the cpp file):

MySubsystem* MyRobot::mySubsystem = 0;

Hope this helps someone!

[bob.wolff68]

Ken,

Our robot experienced a similar and even more dramatic version of this yesterday. Somehow (unrelated), our project file from last year no longer had two <class>.cpp files in the left hand project area. Therefore, those cpp files were not being compiled...no problem yet... and the main robot did instantiate both of these classes. Compile time won't notice a problem here, but linking *SHOULD*. It didn't. It compiles and links without issue. It gives a .out file. The .out file is happy to deploy. No robot code...

After a bit of investigating, we brought up NetConsole client - thanks for this tool - very helpful. At run-time, the .out file is ran, and it actually spits out errors about unresolved symbols which are all related to the non-compiled classes. *SIGH* - including the files in the project now yields a .out file that runs. It's not happy for other reasons which we'll explore today, but there's robot code.

What happened here folks? WindRiver want to comment? And I'd love to hear from FIRST as to why the toolchain hasn't changed since 2012. Is this a hint of big changes to come in platform, tools, etc? Rather surprised that we're using the same tools after a year ... and that the linker doesn't catch these issues more importantly.

Thanks,
bob

[mikets]

I think we hit this years ago. If I remember correctly, the explanation was that Wind River doesn't complain about missing variables because they could be part of WPILib which are linked dynamically to the kernel when the robot code is loaded. Therefore, they will generate run-time error but not compile time error. And the way to catch it is through the debug console.

[jwakeman]

Originally Posted by mikets

I think we hit this years ago. If I remember correctly, the explanation was that Wind River doesn't complain about missing variables because they could be part of WPILib which are linked dynamically to the kernel when the robot code is loaded. Therefore, they will generate run-time error but not compile time error. And the way to catch it is through the debug console.

This is the explanation I got from Joe Hershberger when i was confused on a similar issue.

It's a single mode OS... if you have a header that defines the symbols and you are not trying to statically link the library in, then you just need to load your library. The symbols will be looked up at runtime.

From this thread

[bob.wolff68]

Wow - it was obvious from the messages in the console that it was doing dynamic loading - otherwise I can't imagine it running at all. But I gotta say firstly I'm shocked we haven't run headlong into such issues in the past - lucky us. And secondly I gotta think that there are some good number of teams out there who have no idea what went wrong one day with their code and it no longer works...that's gotta be very frustrating. Seems to be very counterproductive for the goals of FIRST to me. It wouldn't be very hard to hard a 'whitelist' of expected runtime-load-symbols and have the compiler/linker at least WARN users if they have any unresolved symbols which are NOT part of the whitelist. This would provide sophisticated teams the ability to utilize runtime binding and keep junior teams from hurting themselves badly with what is nothing but a 'bug' to those teams.

Who maintains a FAQ or the Sticky threads here? This topic could be a notable for that -- "No Robot Code after deploy and reboot" ...

bob