esp32: UDP broadcast via sendto causes memory leaks/ENOMEM error

[dir-ableton]

I described this in the uP forum:

https://forum.micropython.org/viewtopic.php?f=18&t=5063&p=28953#p28953

on further investigation, I found that commenting out

https://github.com/micropython/micropython/blob/master/ports/esp32/modsocket.c#L485

made the problem disappear - by disabling the actual functionality of course. To my uninitiated eye, this looks like a SDK issue, but at the same time there seems to be some dependency to the gc calls as documented in the forum post. Any suggestions on to get to the bottom of this?

[adritium]

If you think it's related to gc, enable all gc diagnostics by setting these to 1:
MICROPY_DEBUG_VERBOSE, EXTENSIVE_HEAP_PROFILING.

[deets]

(same person, different account - sorry for that).

I'm actively trying, the result is various errors regarding DEBUG_printf including eventually a link-error that it's not found. Any suggestions?

Also I do print the gc output, and the free bytes from uP seem to stay constant. So it looks more as if memory is drained in the C-layer.

[deets]

Ok, found #3732, so compilation works. Will test my code now.

[deets]

OK, now the system doesn't come up, the error is

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4616
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:12768
entry 0x4007ad68
I (388) cpu_start: Pro cpu up.
I (388) cpu_start: Single core mode
I (388) heap_init: Initializing. RAM available for dynamic allocation:
I (392) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (398) heap_init: At 3FFC57F0 len 0001A810 (106 KiB): DRAM
I (404) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (410) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (417) heap_init: At 40091B28 len 0000E4D8 (57 KiB): IRAM
I (423) cpu_start: Pro cpu start user code
I (217) cpu_start: Starting scheduler on PRO CPU.
/home/deets/software/vc/esp-idf/components/freertos/queue.c:718 (xQueueGenericSend)- assert failed!
abort() was called at PC 0x4008bbd0 on core 0

Backtrace: 0x4008f49b:0x3ffb6f80 0x4008f4c7:0x3ffb6fa0 0x4008bbd0:0x3ffb6fc0 0x400f39d2:0x3ffb7000 0x400f09cc:0x3ffb7020 0x400f0a35:0x3ffb7040 0x400d43d5:0x3ffb7060 0x400d4876:0x3ffb7080 0x400d4bfd:0x3ffb70e0 0x400d38f7:0x3ffb7130 0x400d3b37:0x3ffb7150 0x400d3269:0x3ffb7180 0x400d32b1:0x3ffb71a0 0x400dd027:0x3ffb71c0 0x400def3f:0x3ffb71e0 0x400dbc99:0x3ffb7200 0x400f0832:0x3ffb7220

[deets]

I found to my surprise that my code that provokes the error survives the make deploy, and thus ran. So it just might be that the above trace is revevant to the problem. Or not. Difficult for me to judge.

[syndycat]

Does this problem was fixed?
We still have it on pycom WIPY3.