Clutching at straws: guru doesn't like me in uxListRemove() (freertos/list.c: 218)

ESP_Angus
Posts: 1897
Joined: Sun May 08, 2016 4:11 am

Re: Clutching at straws: guru doesn't like me in uxListRemove() (freertos/list.c: 218)

Postby ESP_Angus » Tue Dec 03, 2019 3:19 am

RobMeades wrote:
Mon Dec 02, 2019 5:40 pm
A possible answer (still testing): allow the idle task to run. If I put a vTaskDelay() of 100 ms after deleting my "LED" task then, so far at least, the problem does not occur. Is it possible that FreeRTOS is getting confused when the task is created once more after it has been deleted if FreeRTOS is not allowed to do some form of clean-up first?
Yes, calling vTaskDelete() stops the task from being scheduled to run again but doesn't free all the associated resources. The task's resources aren't fully released until after the FreeRTOS idle task has a chance to run and "clean up" the task. This is part of the FreeRTOS design.

As you're using static resources, if the vTaskStaticCreate() is run before the idle task has cleaned up, there's a high chance of a problem.

ESP_Sprite
Posts: 2910
Joined: Thu Nov 26, 2015 4:08 am

Re: Clutching at straws: guru doesn't like me in uxListRemove() (freertos/list.c: 218)

Postby ESP_Sprite » Tue Dec 03, 2019 3:29 am

Agreed. My guess would be that you delete your task, then immediately re-create it in the same memory. The task still is on the to-be-deleted list, so when finally the idle task kicks in, it thinks the newly-created task isn't running anymore and should be cleaned up and happily clobbers all the structures it's in.

RobMeades
Posts: 28
Joined: Thu Nov 29, 2018 1:12 pm

Re: Clutching at straws: guru doesn't like me in uxListRemove() (freertos/list.c: 218)

Postby RobMeades » Tue Dec 03, 2019 9:04 am

Confirmed: with a vTaskDelay() of 100 ms after the task was deleted on an overnight run of 832 cycles there were no more occurrences of the panic. Just wish I hadn't spent 3 days trying to find a nasty memory-stomp in my code! I guess from a FreeRTOS point of view doing any checking to defend against this is just fat but it would be kinda nice, or maybe just a mention in the documentation.

Anyway. thanks for all your swift help guys, now sorted.

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 19 guests