NetworkTable crash in unmodified SimpleRobot template

I’m getting a null pointer exeption in


on the following line:

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

This crash occurs in unmodified SimpleRobotTemplate code. How does something like this even get through QA, or is there even any QA to begin with? Sure seems like there isn’t any…

Earlier on in the call stack, the crash stems from


when it calls

LiveWindow *lw = LiveWindow::GetInstance();

which creates a new instance of LiveWindow since it’s the first time GetInstance() is called, which results in it calling



When will this be fixed in WPILib, and how can I work around it in the meantime?


Are you sure that this is unmodified. We just ran the template project again and it worked fine. If you are still having issues would it be possible to do a little more debugging and figure out exactly what is null on that line.


Yes, I’m sure that it’s umodified. I guess I’ll just have to fix the bug in WPILib myself and submit it.

I suggest that you reinstall the WindRiver update before blaming the library itself.

No luck reinstalling everything, however it does work on other computers. Just not mine. Any other ideas?

If you could run the debugger and determine what value on that line is null then I may be able to try to help a little more.

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

Out of curiosity, why is there an asterisk in the argument for NetworkTableProvider? (I always get hazy around dereference operators)

Anyway, a null pointer exception would seem to indicate that something on that line is an uninitialized pointer. How/where did you declare staticProvider?

Well, not looking at the lib or anything, but it seems pretty clear that CreateNode returns a pointer, but the NetworkTableProvider constructor expects a value.

It looks like it expects an address to a node – and if createNode returns a pointer, he has an asterisk in there that he doesn’t need. I think that’s the cause of his null pointer exception – that asterisk creates an uninitialized pointer.

createNode will always return a non-null pointer. The NetworkTableProvider constructor takes a reference to the pointer type returned by createNode. This code has run fine on under linux and the crio so it is weird that it is failing here.

staticProvider is declared in NetworkTable.h

Could ipAddress contain the null string? If so, ipAddress.c_str() would return nullptr.

This may be the issue. It probably stems from misconfiguration of the cRio or laptop. You should double check what team number you formatted it with.

We were running into the same exact problem with our code but instead of WindRiver we were using makefiles similar to UCPP to compile our code (we don’t have problems if we compile with WindRiver).

We tried setting the ipAddress variable to our robot’s ip address manually, but that didn’t fix the problem and since the its a server, the ipAdress seems meaningless.

We double-check the same thing too, but the error is still there. Did you have a particular configuration in mind?

When we were debugging the same issue, we found that both the mode and threadManager store non-null addresses. But whenever mode->CreateNode() was called, the null pointer error resurfaces. The variable mode is of type NetworkTableMode, so we replaced the code with

staticProvider = new NetworkTableProvider(NetworkServerMode::Server.CreateNode(ipAddress.c_str(), port, threadManager));

which still results in an error.

We are totally baffled; we just commented the livewindow stuff out as workaround but ultimately we need to figure out why this happens. Any additional suggestions? I remember there being a debugger that runs on the cRIO, but I’m not sure how that works.


Is there documentation that explains how the c++ networktable stuff works?

I have been unable to reproduce this problem. Try replacing ipAddress.c_str() with just “”. It is actually ignored when in server mode (which it is always when running on the crio)

Can you post the actual output. Also make sure that you rebuild the WPILib project

Fixed it.

As it turned out, when you debug the first time after rebooting the robot, everything works fine. The second time you debug, the crash is caused by an IOException thrown in SocketServerStreamProvider::SocketServerStreamProvider(int port).

The crash happened because the cRIO’s user code (ours) attempted to bind a socket that had already been bound by a previous debugging session.

It can be fixed quite easily by inserting the following code somewhere (anywhere) between the call to setsockopt(…SO_REUSEADDR…) and the call to bind():

// NWR2013 - Set the port as reusable too.
if (setsockopt(serverSocket, SOL_SOCKET, SO_REUSEPORT, (char*) &reuseAddr, sizeof(reuseAddr)) == ERROR)
	printf("[SocketServerStreamProvider] Unable to mark the server socket port as reusable! Reason: %s
", strerror(errno));