Guru Meditation Error at uxListRemove

[rtborg]

I have an application which creates two static queues, and some static tasks which are waiting on said queues. When I try pushing an item onto a queue, I get the following error:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x4037d76b  PS      : 0x00060633  A0      : 0x8037ca3d  A1      : 0x3fceac70  
0x4037d76b: uxListRemove at C:/Users/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/list.c:197

A2      : 0x000000be  A3      : 0x3fc96cb8  A4      : 0x00000000  A5      : 0x00060623
A6      : 0x00000000  A7      : 0x0000cdcd  A8      : 0x8037d920  A9      : 0x3fceac40
A10     : 0x00000001  A11     : 0x00000000  A12     : 0x00000000  A13     : 0x3fc94140  
A14     : 0x00060023  A15     : 0x00000003  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x000000ce  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0x00000000  


Backtrace: 0x4037d768:0x3fceac70 0x4037ca3a:0x3fceac90 0x4037b46b:0x3fceacb0 0x4200882f:0x3fceacf0 0x42008d09:0x3fcead10 0x42009e3d:0x3fcead80 0x4200b005:0x3fceada0 0x4200b387:0x3fceadd0 0x4037d79d:0x3fceadf0
0x4037d768: uxListRemove at C:/Users/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/list.c:194

0x4037ca3a: xTaskRemoveFromEventList at C:/Users/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3800

0x4037b46b: xQueueGenericSend at C:/Users/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:890

All tasks and queues are initialized when the error happens. The queues are used for passing data by copy.

Some info on my application:
- Using TWAI driver with ESP_INTR_FLAG_LOWMED
- Using tinyusb
- All user-defined tasks have a priority of 1

Any leads will be greatly appreciated, I've wasted a whole day with no results whatsoever.

Thanks

If only one of the queues is used, the error does not appear. It only occurs when I am pushing data to both queues.

[ESP_Sprite]

Hard to say without your code; all I can see is that the thing tries to dereference a null pointer. Are you sure your queues are initialized before you push or pop something to/from it? (E.g. starting a task that uses a queue and then initializing the queue can lead to this.)

[rtborg]

Yes, the queues are properly initialized and I am using them to pass structs by value, so no ownership problems should occur.

When changing the tasks and queues from static to dynamically allocated, the problem disappears. The error happens when the scheduler unblocks a task which is waiting on a queue, so maybe the TCB gets corrupted somehow. Which is strange, because it's statically allocated.

Any ideas how to trace that?

[ESP_Sprite]

Just to check: how do you statically allocate those queues?

[rtborg]

Below is a queue initialization code. I have two of these at the moment, each with separate control block and buffer.

Code: Select all

typedef struct {
	uint16_t type;
	union { /* different payloads for each event */ }
} event_t;

static event_t queue_storage[10 * sizeof(event_t)];
static StaticQueue_t queue_cb;
static QueueHandle_t queue;

queue = xQueueCreate(10, sizeof(event_t), (uint8_t*) queue_storage, &queue_cb);

Here's the complete stack trace:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x4037d771  PS      : 0x00060f33  A0      : 0x8037caa4  A1      : 0x3fced4c0  
0x4037d771: uxListRemove at /home/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/list.c:199

A2      : 0x3fc99430  A3      : 0x3fc96cb8  A4      : 0x00000000  A5      : 0x00060f23  
A6      : 0x00000000  A7      : 0x0000cdcd  A8      : 0x3fc96d28  A9      : 0x3fcec5ac  
A10     : 0x0000ab08  A11     : 0x00000000  A12     : 0x00000000  A13     : 0x00060f23  
A14     : 0x00000003  A15     : 0x0000cdcd  SAR     : 0x00000018  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x0000ab10  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0x00000000  


Backtrace: 0x4037d76e:0x3fced4c0 0x4037caa1:0x3fced4e0 0x4037b46b:0x3fced500 0x42008817:0x3fced540 0x42008a19:0x3fced560 0x4037d79d:0x3fced630
0x4037d76e: uxListRemove at /home/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/list.c:199

0x4037caa1: xTaskRemoveFromEventList at /home/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3829

0x4037b46b: xQueueGenericSend at /home/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:890

0x42008817: active_post at /home/user/Documents/esp32s3/project/main/freeact.c:135

0x42008a19: blink_task at /home/user/Documents/esp32s3/project/main/active.c:362 (discriminator 1)

0x4037d79d: vPortTaskWrapper at /home/user/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:151

I replaced the static queues with a dynamic, and so far the code works, or at least it does not crash right away, which confirms your initial suspicions. The crash consistently happens after pushing three items on a queue (item size is 72 bytes).

[rtborg]

Found the culprit - one of the static queues was initialized like this:

Code: Select all

static event_t queue_storage[10 + sizeof(event_t)];

Thanks for pointing me in the right direction, @ESP_Sprite

[ESP_Sprite]

No, I don't think that is the issue... I saw that construct in your original code as well, and I don't think it does what you think what it does. Specifically, the number between [] brackets indicates the amount of elements (with the size of the array type) in the array, not the amount of bytes the array occupies. In other words, if e.g. event_t is 16 bytes, event_t queue_storage[10] would allocate space for 10 events, occupying 160 bytes of RAM. event_t queue_storage[10*sizeof(event_t)] however would allocate 160 elements, occupying 2560 bytes.

That means that even an array of size queue_storage[10 + sizeof(event_t)] should be more than enough to store 10 queue elements in (the array is too large, but that's not a breaking bug), so that can't be it.

What I think is that something somehow is writing outside its allocated space and clobbering the queue data. Over-sizing the array makes the erroneous writes land inside the 'extra' space in the array, making the thing not crash. I fear your original bug is still there, though.

[rtborg]

Thanks for spotting that. I am now allocating storage for the queues like this:

Code: Select all

static uint8_t queue_storage[10 * sizeof(event_t)];

and the application works; I will keep on testing to see where the fault might be.