Allocating more memory result in bulk errors

[KanyeKanye]

Working with WiFi, whenever I alloc any buffer larger than ~64bytes, my code crashes, but whats important I am unable to detect any accurate place where it does. Like there would be no more memory and when some background things for WiFi receive some packets, alloc space for them, the code stops:

Code: Select all

char recv_buf[256];
memset(recv_buf, 0, 256);

Code: Select all

/.../esp-idf/components/freertos/./queue.c:1445 (xQueueGenericReceive)- assert failed!
Guru Meditation Error: Core  0 panic’ed (Unhandled debug exception)
Register dump:
PC      : 0x40009203  PS      : 0x00060936  A0      : 0x800834e0  A1      : 0x3ffc4dd0  
A2      : 0x0000006f  A3      : 0x0000006f  A4      : 0x00000010  A5      : 0xffffffff  
A6      : 0x00000000  A7      : 0xffffffeb  A8      : 0x00000000  A9      : 0x3ffc4d40  
A10     : 0x00000000  A11     : 0x3f404304  A12     : 0x3ffc4d0f  A13     : 0x00000035  
A14     : 0x00000000  A15     : 0x3ffc4d15  SAR     : 0x00000004  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffff93  

Backtrace: 0x40009203:0x3ffc4dd0 0x400834e0:0x3ffc4df0 0x40082d30:0x3ffc4e30 0x40081399:0x3ffc4e50 0x40081470:0x3ffc4e80 0x40081ebc:0x3ffc4ea0 0x40100de0:0x3ffc4ec0 0x4000bd86:0x3ffc4ee0 0x40001180:0x3ffc4f00 0x40059301:0x3ffc4f20 0x4005937d:0x3ffc4f40 0x40058bc2:0x3ffc4f60 0x400f4be4:0x3ffc4f90 0x400fa371:0x3ffc4fc0 0x400fa500:0x3ffc52d0 0x400812a8:0x3ffc5300 0x4010408d:0x3ffc5350 0x40104693:0x3ffc5370

Rebooting…

[kolban]

Would you be able to post more code than that just seen?
What makes you think that is the location where the error occurs?
Have you tried attaching "gdb" to look at the back trace to see exactly where the error is encountered?

See (for example) ... https://www.youtube.com/watch?v=p63VEYS7ZUw

[ESP_Angus]

Code: Select all

char recv_buf[256];
memset(recv_buf, 0, 256);

This code is allocating the buffer on the stack, and may be leading to stack overflow (which the RTOS scheduler should detect rather than crash, but I think that's a separate issue.)

You can do any of the following to work around this

• Increase the stack size for the calling task via its xTaskCreate call - it's the third argument.
• Allocate from the heap with malloc(), ie "const char *recv_buf = malloc(256)". Remember you need to free the memory when you're done.
• Static allocate the buffer with "static char recv_buf[256]". The buffer will permanently occupy RAM in your firmware and makes the function non-thread-safe, but this may still be a convenient solution.

(First option probably the best option.)