Unknown abort() of execution

This is my second attempt to create a project-file-structure, it compiles but throws a warning. When I run it, it aborts execution whit this message. I have no idea what it says, please help me out.
— Setup started —
Setup completed.
/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/home/runner/queue.c:71/work/esp32-9 (xQueueGenarduino-libericSend)- a-builder/esssert failedp32-arduino!
abort() w-lib-buildeas called atr/esp-idf/c PC 0x40085aomponents/fc2 on core 1reertos/que

I get a 404 not found when clicking this link o_O.

Possibly private repository or wrong link?

Sorry, changed it. Added bulls… to become more the 20 characters

General tip: If you add

monitor_filters = esp32_exception_decoder
build_type = debug

(docs) to an ESP32 project, the serial monitor will show you much more detailed information about the crash, allowing you to track it down.

In this case it outputs

Backtrace: 0x40084ea0:0x3ffb8b90 0x40085115:0x3ffb8bb0 0x40085ac2:0x3ffb8bd0 0x400d0e36:0x3ffb8c10 0x40086125:0x3ffb8c40
  #0  0x40084ea0:0x3ffb8b90 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #1  0x40085115:0x3ffb8bb0 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #2  0x40085ac2:0x3ffb8bd0 in xQueueGenericSend at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:2038
  #3  0x400d0e36:0x3ffb8c10 in taskSender(void*) at src/taskSender.cpp:15
  #4  0x40086125:0x3ffb8c40 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)

So were are panicing in freertos/queue.c:2038 in the context of the taskSender() function.

This leads us to esp32 reset on xQueueSend - ESP32 Forum.

either you have not initialized xQueue with xQueueCreate, or you did but that call failed because of low memory.

There is an extremely subtle error in your error code. If you look closely in the header file.


Now how can this be if you reference myQueue in

and use it in

? By having written the variable declaration as static, it means that every .cpp file gets its own copy, or version of the myQueue variable. static means a global variable but its scope is limited to the file scope. Thus what’s happening here is that main.cpp includes the header, and it creates its own file-global variable myQueue, then taskSender.cpp is compiled, and it gets its own myQueue file-global variable, which is distinct from the myQueue variable the main.cpp file has. Thus, when taskSender.cpp calls xQueueSend, it does so with a queue that has not been initialized at all! Since main.cpp only initialized its own myQueue variable, but doesn’t further use it, hence the warning of the compiler that the variable is defined but not used is correct (for some files).

So the error here is purely wrongly sharing global variables and calling FreeRTOS functions on uninitialized memory (un-inited queue), and thus you run into an abort. Probably in this code but I couldn’t match up the line numbers for some reason… (Although I did check to use the exact same version Arduino-ESP32 uses with ESP-IDF v3.3.5 hm…).

Anyways, the way to correctly share the global variable accros files is to never declare it static but extern.


static QueueHandle_t myQueue;


extern QueueHandle_t myQueue;

and addding the line

QueueHandle_t myQueue; 

in main.cpp after the includes (line 4), so that the global variable is defined in only one cpp file (which one doesn’t really matter), your problem goes away. Now there’s only truly one myQueue variable in the entire firmware and it’s shared between all .cpp files correctly.

Serial monitor:

entry 0x400806a8

--- Setup started ---
Setup completed.
Sender - Add to Q: 2
Sender - Add to Q: 4
Sender - Add to Q: 8
Sender - Add to Q: 4
Sender - Add to Q: 1
- - - - - - Receiver - reading: 2
Sender - Add to Q: 1
Sender - Add to Q: 5
- - - - - - Receiver - reading: 4

Of course the senderTask is still spamming the queue as hard and fast as it can (the queue is practically constantly full), but that’s the way you programmed it and is okay.

Thank you Max!
You’re a great teacher.

1 Like