Unexpected break/watch point in FreeRTOS code cannot be resumed

[i_am_mrp]

When debugging the ESP32 I get a break/watch point stops inside FreeRTOS code. The problem is I never set any break/watch point(s) in that code. What is worse is that I can never resume debugging from this condition. Trying to resume or (step into/over/out-of) from the FreeRTOS code all result in the debug session being terminated after a delay of approximately 10 seconds. This condition happens all the time.

Environment: MAC OS X Sierra 10.12.2
OpenOCD - Open On-Chip Debugger 0.10.0-dev-ga859564 (2017-07-25-00:19)
GNU gdb (GDB) 8.0.1, IDE: Eclipse Neon 3, Board: ESP32 WROVER KIT - V3, ESP-IDF: latest (about 10 days old, and with latest - as of this writing)

I see this same behavior with any combination of OpenOCD (standalone or with Eclipses) with (Eclipse GDB HW Debugging or Eclipses OpenOCD Debugging). The scenario is, I hit a breakpoint in my code (as set and expected) and when I say resume debugging, I get the unexpected break into the FreeRTOS code from which I cannot proceed.

The unexpected FreeRTOS breaks occur in queue.c::1591: portYIELD_WITHIN_API() or other places in queue.c, but as mentioned these unexpected and un-asked for breaks result in the debug session unable to resume and ultimately end. The executing thread (really FreeRTOS task) shows (Suspended : Signal : SIGTRAP:Trace/breakpoint trap).

Does anyone have any ideas as to why this is happening? I have attached my sdkconfig for reference.

Is it possible that memory/stack bugs/problems are causing SIGTRAP?

I know, SIGTRAP is normal for processors that support breakpoints/watchpoints. Of course without the debugger running, SIGTRAP would terminate the process. The issue is I don't have any breakpoints in these FreeRTOS functions and I don't have any watchpoints either. The watchpoint angle seems interesting as there are options in make menuconfig that could possibly result in watchpoints being set from FreeRTOS options:
[ ] Set a debug watchpoint as a stack overflow check
[ ] Enable FreeRTOS trace facility
[ ] Enable FreeRTOS to collect run time stats
[ ] Debug FreeRTOS internals
I don't have any of these set.

I do have:
[*] Make exception and panic handlers JTAG/OCD aware

There are other menuconfig's like these where it's not clear what the will/should do in GDB/OCD scenarios but I don't have them enabled anyways.
[ ] Use TRAX tracing feature
[ ] Heap corruption detection
[ ] Enable heap tracing

[hassan789]

I have been living with same problem. I am running in eclipse on windows.
Hoping the dev team is working on improving debugging.

[ESP_krzychb]

Hi i_am_mrp,
Hi hassan789,

Could you report it following https://esp-idf.readthedocs.io/en/lates ... ing-issues ?

[i_am_mrp]

Thank you for the response.

Can memory issues (heap, stack) etc... somehow cause this problem? I asked this in the original post and am wondering if I should be looking at other potential causes.

I will try to get a standalone example.

Currently I cannot send you my entire environment (licensing, etc...), which is unfortunate since I can reproduce the problem every time.