LIBC PANIC!!
fmutex deadlock: Recursive mutex!
0x2003013c: Owner=0x2da80001 Self=0x2da80001 fs=0x3 flags=0x0 hev=0x00010004
Desc="LIBC Heap"
pid=0x2da8 ppid=0x2da7 tid=0x0001 slot=0x00c8 pri=0x0200 mc=0x0000 ps=0x0010
D:\CODING\QT5\QT5-DEV-BUILD\QTBASE\LIBEXEC\QTWEBENGINEPROCESS.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
It means that the libc heap mutex is requested while being already held. I suspect that it might be because of the interrupt service that in theory may kick into the process at any time — even inside a malloc/new call. SO if there is another malloc call from that state, such a problem may show up. This should not happen as I made protection against that (against unexpected reentrancy) but I need to check this.
This is a regression of #87. Thanks to LIBC panic .TRP reports (see bitwiseworks/libc#96), I could easily confirm my guess. The interrupt service request from LIBCx happens while LIBC is in the middle of some malloc call under the LIBC Heap fmutex lock. Since the interrupt handler calls _beginthread which does some malloc (halloc, actually, but it's the same mutex in this case), we get this recursion. A fix is to not use _beginthread but call DosCreateThread directly.
From this comment:
This is a regression of #87. Thanks to LIBC panic .TRP reports (see bitwiseworks/libc#96), I could easily confirm my guess. The interrupt service request from LIBCx happens while LIBC is in the middle of some
malloccall under the LIBC Heap fmutex lock. Since the interrupt handler calls_beginthreadwhich does somemalloc(halloc, actually, but it's the same mutex in this case), we get this recursion. A fix is to not use_beginthreadbut callDosCreateThreaddirectly.