We are receiving the following error:
Fatal Python error: Segmentation fault
The robotpy sim runs on teleop sometimes but will often crash, though the error is inconsistent.
Here is a link to our github: https://github.com/beavertronics/2020code5970
We don’t know what to do from here. Can we have some clarification on segmentation faults? Please elaborate further than the common mistakes found on the 2020 documentation.
Commenting out the drivetrain subsystem call in the robotpy init still results in a segmentation fault though there should be no commands running in the scheduler
It also occurs in auto
As mentioned in the other thread, this issue should go away if you upgrade to the latest version of RobotPy commands.
We have done that following these instructions https://robotpy.readthedocs.io/en/stable/install/commands.html
(several times on both the rio and regular computers).
It is what prompted the deluge of errors, including this one about the segmentation faults
Also I will note that that page says the 2020 command framework is not available although running the install seems to get a 2020 framework
"Note
The new command framework is not yet available for RobotPy 2020."
What version of robotpy-commands-v1 does py -m pip list show?
robotpy-commands-v1 2020.2.2.3
robotpy-ctre 2020.2.1
robotpy-hal 2020.2.2.2
robotpy-halsim-gui 2020.2.2.0
robotpy-installer 2020.0.5
robotpy-wpilib-utilities 2020.1.1
robotpy-wpiutil 2020.2.2.2
With your current code on github, and those versions installed, it does not crash for me in simulation.
The one thing that does crash is something about a simple PID which isn’t checked into the repo. Please check it in and push it.
I don’t have errors with simple pid. Have you installed it with pip?
Didn’t realize it was an external package, thanks.
Your code works for me in simulation on Linux, though I haven’t exercised it more than just running it and switching between modes.
The segmentation faults that you’re experiencing are a result of python destroying an object that the underlying C++ code is trying to use. I fixed a bunch of them that your code triggered in robotpy-commands-v1 2020.2.2.3.
There are a variety of ways this error can occur. The most common pattern is creating an object and passing it directly to a function:
something(Command())
Instead, if you store the object somewhere:
self.command = Command()
something(self.command)
Then python won’t destroy the object.
Obviously, RobotPy should be ‘doing the right thing’ and not destroying the underlying object. However, the design of the command framework makes this difficult at times – but I am trying to fix them as they come up. If you can give me specific ways to trigger the crashes (they’re usually fairly deterministic), I can fix them on our end. The python stack traces usually aren’t so helpful, as it’s happening underneath python.
Would objects that are made and destroyed in the scope of a function also cause these errors? Meaning not stored as instance variables such as
def a(self):
b = 1
something(b)
Yes, exactly that.
To be clear, this would cause an error?
That particular example you cited would not. Simple types like strings and integers are automatically converted to their C++ equivalents and should pose no issues.
However, if b were something more complex like a command, it potentially could – but if it did, I would consider that a RobotPy bug and is fixable if we know which function is having the problem (see https://github.com/robotpy/robotpy-commands-v1/issues/5 for an example that we fixed).
If you are still having segmentation faults despite being on 2020.2.2.3, please try to narrow the crashes down to a reproduceable thing, and we should be able to address it. I tried your code in simulation on Linux and another developer tried it on Windows and we were not able to trigger any non-python crashes.
So we have also gotten it to where the sim does not crash, however it crashes immediately on our rio every time we enter teleop mode. A sample error from the log file is here:
File “/usr/local/lib/python3.8/threading.py”, line 932 in _bootstrap_inner File “/usr/local/lib/python3.8/threading.py”, line 870 in run File “/usr/local/lib/python3.8/site-packages/_pyntcore/_logutil.py”, line 60 in _logging_thread Thread 0xb3756470 (most recent call first): Fatal Python error: Segmentation fault at at frc::DriverStation::Run() at frc::MotorSafety::CheckMotors() at frc::MotorSafety::Check() Error at Check [MotorSafety.cpp:103]: A timeout has been exceeded: DifferentialDrive… Output not updated often enough. ERROR -6 A timeout has been exceeded: DifferentialDrive… Output not updated often enough. Check [MotorSafety.cpp:103] Loop time of 0.020000s overrun Warning 1 Loop time of 0.020000s overrun
We have been able to bypass all the complaints about motorsafety by doing self.drive.setSafetyEnabled(False) but the code still dies on the robot with a segmentation fault, below
File “/home/lvuser/py/robot.py”, line 170 in File “/usr/local/lib/python3.8/site-packages/wpilib/_impl/main.py”, line 186 in run File “/usr/local/lib/python3.8/site-packages/wpilib/_impl/start.py”, line 16 in run File “/usr/local/lib/python3.8/site-packages/wpilib/_impl/start.py”, line 49 in run File “/usr/local/lib/python3.8/site-packages/wpilib/_impl/start.py”, line 106 in start File “/usr/local/lib/python3.8/site-packages/commandbased/commandbasedrobot.py”, line 15 in startCompetition File “/home/lvuser/py/robot.py”, line 124 in teleopPeriodic Current thread 0xb6fdf210 (most recent call first): File “/usr/local/lib/python3.8/threading.py”, line 890 in _bootstrap File “/usr/local/lib/python3.8/threading.py”, line 932 in _bootstrap_inner File “/usr/local/lib/python3.8/threading.py”, line 870 in run File “/usr/local/lib/python3.8/site-packages/_pyntcore/_logutil.py”, line 60 in _logging_thread Thread 0xb3836470 (most recent call first): Fatal Python error: Segmentation fault Loop time of 0.020000s overrun Watchdog not fed within 0.020000s
Therefore, we have made a duplicate of the code where we took out everything except for the drivetrain call and we have tried to find the segmentation fault. We have not found anything. We think maybe the problem is that the watchdog is perpetually not fed for some reason (even though the code isn’t really running that many operations). So maybe you could help, here’s the link to the new debugging repo
Thanks
the post above was meant to be in reply to you woops
First, please make sure your packages on the rio are up to date (including robotpy, robotpy-ctre, and robotpy-commands-v1)
Then:
In your left_motors.py and right_motors.py files, try adding self. (ie. left_one -> self.left_one).
Also, in drivetrain.py, try keeping your Left_Motors() and Right_Motors() objects around in a variable.
I just ran your code on my RoboRIO with some minor modifications and there’s no segfault. I’ve pushed a PR to your repo with the modifications – in particular, I’ve fixed your path stuff.
It is critical to ensure your RoboRIO is updated with the latest RobotPy packages. In prior years RobotPy printed out the package versions when the robot started, but that somehow got lost this year. I just added it back in wpilib 2020.2.2.12, soooo…
py -m robotpy_installer download-robotpypy -m robotpy_installer download-opkg ctre commands-v1py -m robotpy_installer install-robotpypy -m robotpy_installer install-opkg ctre commands-v1When the robot starts, the console should show all the versions. Something like this:
22:33:06:614 INFO : wpilib : WPILib version 2020.2.2.12
22:33:06:615 INFO : wpilib : HAL version 2020.2.2.3
22:33:06:617 INFO : wpilib : robotpy-cscore version 2020.0.1
22:33:06:622 INFO : wpilib : robotpy-wpiutil version 2020.2.2.3
22:33:06:623 INFO : wpilib : robotpy-rev version 2020.1.0.1
22:33:06:624 INFO : wpilib : robotpy-ctre version 2020.2.1
22:33:06:626 INFO : wpilib : robotpy-commands-v1 version 2020.2.2.3
22:33:06:627 INFO : wpilib : pyntcore version 2020.2.2.5
22:33:06:629 INFO : faulthandler : registered SIGUSR2 for PID 2353
If the robot still crashes, let me know, and post all the versions (hint: they should be pretty similar to my versions as posted above).