Debugging stalled threads - volatile variables, others?

[scotthauck]

Quick questions: any good way to find out WHERE a thread is stalling out, particularly a packet event handler for Wifi?

My current plan is to put in lots of writes to a volatile variable in the code that is stalling, and have the main loop (which is still running) print out that variable's value periodically.

* Will this work? I'm assuming the compiler will NOT move the volatile writes within the code, but perhaps that isn't the case.

* Is there some other magical way to find out where a stalled thread is stalling out?

Context: I'm sending a continuous stream of UDP packets to the ESP32, and it periodically hangs the message handling. The send rate isn't high (10 a second for example). I do know UDP can drop packets, which shouldn't be an issue. Anyone see something like this before? Too early to ask about the specific code, since haven't deeply debugged it yet, but perhaps this will sound familiar to someone.

[lbernstone]

Your method should work to track the activity in the function, but is subject to Heisenberg probabilities, as Serial.print is a fairly slow method which may "unbind" timing issues . I would recommend using the AsyncUDP library if you are doing a lot of time sensitive UDP comms. Work has been done recently to improve reliability of the lwip stack, so use the github repo code and see https://github.com/espressif/arduino-esp32/pull/2912

[scotthauck]

Thanks for the pointer. I am using AsyncUDP, but I'll try updating to the newest version - did grab the ESP32 support package just in the last few weeks, but perhaps the separate library may be newer.

Serial.print as a timing issue - when the system locks up for me, it locks up forever afterwards - tons of Serial.print's in the main loop happen with the UDP recieve side stalled.

Thanks!

[scotthauck]

FYI, applying that patch seems to have fixed my problem - thanks!