Hello Everyone,
We have been having a particularly difficult problem lately. Our code crashes on load. So far I have been able to narrow it down to creating objects of WPILib classes under seperate tasks. Any objects created under the main robot task work correctly, but if i create an object in a seperate task the code crashes when it tries to start.
I’m working on with windows 7 64 bit, with the latest Wind River update. Any help would be much appreciated.
With more testing I believe i’ve narrowed the problem down further. With the first update for this year, our code runs correctly. Our code doesn’t work correctly with the 2nd midseason update. I plan to test teh first midseason update soon. Hopefully I can narrow the problem down further in doing so.
If you can narrow it down to something that is broken in the library, please post it as soon as you can. That will let us put out an update to fix the issue.
Thanks,
Brad
I’m not sure what the problem is exactly, But i’m pretty sure it has to do with the creation of the livewindow objects. They don’t appear to play nice with tasks.
We are having a very similar issue as well. After updating to the 2nd mid season update (from the first 01/03 release), we found our code was crashing immediately after loading FRC_UserProgram.out, before the main robot class constructor could print anything, before even WPILib could print out its revision number. We attached it to WindRiver and traced the crash back to LiveWindow as well. It seems that something to do with acquiring a NetworkTable for the live window was returning or using a null pointer. The crash doesn’t have a specific error, just that the task was killed, which probably means a segfault.
I tried using the first mid-season update, that seemed to crash as well. Reverting to the initial 2013 release worked. This happened even after reimaging the cRIO, both the 4-slot and the 8-slot.
Can either of you post a program that crashes?
Thanks
Brad
With the second update, we too are seeing a crash in live window-related code. The place we saw it crash was in the WPILib PWM code:
void PWM::StopLiveWindowMode() {
SetSpeed(0);
m_table->RemoveTableListener(this); --> crash here
}
I’m thinking m_table is null at this point.
Please note that according to my recollection, this only occurs when we start the Driver Station/SmartDashboard after we start the robot code. If we start the Driver Station/SmartDashboard first the crash doesn’t occur.
Code for the robot that shows the problem is at:
Team 1967 has had trouble with this fatal kernel task-level exception as well. We traced the error back to the LiveWindow SetEnabled() function. To flush out the problem, we put "printf"s to bracket the problem and looked at NetConsole to see how far the code “got” before it crashed. We also used “if” statements to check if pointers in both SetEnabled and InitializeLiveWindowComponents (which is called by SetEnabled) were null (such as: m_scheduler, m_liveWindowTable, table). Then, we checked to make sure it->first was non null, too. This led us to errors down in the PWM and Solenoid .cpp files. In the function StartLiveWindowMode for both the PWM and the Solenoid classes, we created an “if” statement to check if m_table was not null so that we would know that it wasn’t using a null pointer. If it wasn’t null, we let it call AddTableListener. In InitTable, we also put in an “if” statement that would print out that subTable was null if it really was null. The program STILL CRASHED. To debug this further, we went into a debug session (with our own JankyActuator task created as an object). It crashed in PWM’s StopLiveWindowMode. The exception was that pointer m_table was 0xEEEEEEEE. The pointer m_table was never set to null in the constructor. So, we initialized m_table in both PWM’s and Solenoid’s constructors. The program still ended up crashing but we got "printf"s on NetConsole that m_table was now null - AHA! This caused us to see that in StartLiveWindowMode we got a failure because m_table was not checked before using it and Solenoid and PWM and other LiveWindow based classes all use this. We haven’t completely fixed this problem but the lack of initializing m_table and using pointers without checking them is a big part of the problem.
Our work around of the problem is that we create pointer-based objects instead of objects proper in the class (i.e. use Victor * pV and new this object in RobotInit vs. the problematic way of Victor V(5) which gets instantiated too early and trips this problem more frequently). Also, we noted that m_scheduler is not checked in SetEnable() but is used. And it was unclear how the functionality of Initialized Components happens if a component is added after SetEnabled is called for the first time. This is due to the fact that InitializeLiveWindowComponents() is only called once and only the first time SetEnable() is called in LiveWindow. This means late-comers to LiveWindow will not get the same treatment as objects which are added prior to the first SetEnable() call.
Lastly - when adding the WPILib sources into our project as per the Screensteps documentation, we ran into troubles getting WPILib to compile. This is due to the fact that the .cpp -> .o build rule had a ‘shell’ command that called out to ‘subversion’ in order to get the subversion version and put it into a -D define variable. If you don’t have subversion, this FAILS and the command fails, but the library winds up being created but it is empty. This caused a lot of delay until we changed the -D shell-out to a fixed value to get it to work.
Thanks,
Holly