Segmentation fault

VEX V5 General Discussion Technical Discussion
#1

I’ve started using PROS this year and so far it’s been (mostly) great. However, I’ve been having a recurring problem for a while now: segmentation faults. Usually it isn’t a big deal, the cortex shuts down for a second and then resumes, but my team FINALLY but optical shaft encoders on our lift and any time the fault occurs it resets the encoder, screwing up my proportional controller and auto-stacker. As I understand it, segmentation faults happen when you try to access invalid pointers. I do not have any manually defined pointers in my code, so I can’t just look around for a bad one. The fault seems to happen when I run


taskDelete()

on my auto-stacker task, no matter where call it from. I have a suspicion that


taskHandle

s utilize some sort of pointer in them and my declaring


extern TaskHandle auto_stack_task;

is causing scope issues when I try to access it. Can anybody shed some light onto what may be causing this? I’d also appreciate it if somebody can come up with a better implementation of my auto-stacker task, as the current system is messy and for some reason doesn’t let my main task (opcontrol) do anything while it’s running, despite having


delay()

s throughout my code. Any help is appreciated.

My code

Also I apologize for the messy code, I had to start over and did this all in like a day, so sorry about the lack of useful comments.

#2

Have you tried a blocking delay at the end of autoStackerRun? I’m not sure of the exact details of the PROS port of FreeRTOS but usually a task should not terminate. You should also always test for NULL pointers before using them (ie. the task handle ) and assuming they are good.

#3

This is true, however in this case he is ending the task with a


taskDelete

statement, which should be fine (generally tasks shouldn’t terminate by just ending or returning because the scheduler wouldn’t know how to handle them).

As for NULL pointers- I’ll quote from our API documentation:

This means that you shouldn’t need to have a global reference to your


TaskHandle

, which may be the source of your undesired behaviour.

That being said, I notice that you sometimes directly (not as a task). In this case, if you call the function and the


TaskHandle

has already been deleted you may be mistakenly deleting the


opcontrol

task instead.

Also, can I ask how you are sure there are segfaults occurring (I assume you have


pros terminal

running)?

1 Like
#4

That was commented out in the version I saw IIRC.

except that if the taskCreate call in opcontrol returns NULL then the call to taskDelete will delete the wrong task.

#5

My assumption was that it was commented out because it was causing issues.

Yes, this was the point I was trying to make.

#6

Yeah it showed a message in the terminal. At the moment I’m just running the function without a task and telling my driver that he can’t move the bot around while it’s running… Not the best solution, but it’ll work for now. Thanks for the help, I’ll try passing NULL in once I get a chance with the bot.

#7

Your code is mostly good except for a few things I highlight below regarding the auto stacker:

First, delete these lines: https://github.com/ZachDaChampion/77788J-mk4/blob/master/src/opcontrol.c#L135-L137

When a task exits (like autoStack does), PROS will automatically call taskDelete for you. Calling taskDelete twice will usually cause a double free and invalid pointer access.

Finally, I’m not really sure what


auto_stack_initialized

is doing and looks like it could be safely removed. I would also recommend making use of [

](https://pros.cs.purdue.edu/api/#taskGetState) instead of using

auto_stacker_enabled

 since taskGetState should do a better job of determining whether or not that task is actually running.
#8