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.
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.
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.
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