[CLOSED] ESP32 abort in locks() after updating from release 4.1 to release 4.3 (or master)

[RobMeades]

We've recently moved our code forward from release 4.1 to release 4.3, and then to master, and on both release 4.3 and master we are getting a consistent abort() in one of our regression tests as a result of the check on line 138 of newlib locks.c where a recursive mutex is being called inside an interrupt. We don't write any interrupt code on ESP32 and the only ESP-IDF thing we're using that might use interrupts (we aren't using Wifi etc. in this case, just boring MCU stuff) is the UART API; the problem occurs around the time we are shutting down a UART by calling uart_driver_delete(). We shut down a UART in plenty of other places but maybe there's something it doesn't like about this particular shutdown?

The backtrace doesn't take us very far I'm afraid, just line 138 of locks.c and then line 167 of locks.c where _lock_acquire_recursive() is called, after that none of the backtrace addresses line up with anything valid.

Could we have somehow missed out some switch or other, or had it renamed underneath us, in our sdkconfig (attached), which might cause this? Any other suggestions as to how we find out what is causing this?

sdkconfig.txt

sdkconfig

(26.43 KiB) Downloaded 341 times

[RobMeades]

Inserting a trail of printf()s shows that the assert is happening at about the time we actually do lock a mutex but we are not doing so in an interrupt; as I said we don't use interrupts for anything. Also, we only create mutexes with xSemaphoreCreateMutex() which should create a mutex with type queueQUEUE_TYPE_MUTEX not queueQUEUE_TYPE_RECURSIVE_MUTEX, which is what the check is for.

Could something be going wrong with the !xPortCanYield() check somehow? FYI this is with configSUPPORT_DYNAMIC_ALLOCATION=1.

FYI, here is as far as the trail goes:

https://github.com/u-blox/ubxlib/blob/m ... est.c#L234
https://github.com/u-blox/ubxlib/blob/m ... ate.c#L173
https://github.com/u-blox/ubxlib/blob/m ... eam.c#L577
https://github.com/u-blox/ubxlib/blob/m ... nt.c#L2973

[RobMeades]

Hah! Found it, ignore me: our pointer gEdmStream.atHandle looks very sensible at that point, however it had been free'd a few lines earlier! All our fault, nothing for you to be concerned with, and fortunately only in the test code. Will now move happily to master .