MINGW-packages: Crash after winpthread update

Since the update to mingw-w64-x86_64-libwinpthread-git-9.0.0.6128.07922837-1 / mingw-w64-x86_64-winpthreads-git-9.0.0.6128.07922837-1, my app is crashing with the following gdb stack:

Thread 43 received signal ?, Unknown signal.
[Switching to Thread 2160.0x21f0]
0x00007ffea5b31f46 in ntdll!RtlRaiseStatus ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) #0  0x00007ffea5b31f46 in ntdll!RtlRaiseStatus ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffea5ae0052 in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffea55a2eed in msvcrt!_setjmpex ()
   from C:\WINDOWS\System32\msvcrt.dll
#3  0x00007ffe9d8a5c31 in ?? () from D:\msys64\mingw64\bin\libwinpthread-1.dll
#4  0x00007ffe6cb88330 in ode!_ZN22dxThreadManagerPthread12simLoopChildEPv ()
   from D:\msys64\home\Olivier\webots\msys64\mingw64\bin\ode.dll
#5  0x00007ffe9d8a4f35 in ?? () from D:\msys64\mingw64\bin\libwinpthread-1.dll
#6  0x00007ffea556af5a in msvcrt!_beginthreadex ()
   from C:\WINDOWS\System32\msvcrt.dll
#7  0x00007ffea556b02c in msvcrt!_endthreadex ()
   from C:\WINDOWS\System32\msvcrt.dll
#8  0x00007ffea43b6fd4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#9  0x00007ffea5a7cec1 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) A debugging session is active.

        Inferior 1 [process 2160] will be killed.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 42 (39 by maintainers)

Commits related to this issue

gcc, winpthreads: rebuild See #8094 — committed to msys2/MINGW-packages by lazka 3 years ago
gcc, winpthreads: rebuild See #8094 — committed to mingwandroid/MINGW-packages by lazka 3 years ago
gcc: Revert 357c435 and 49a714e This commit reverts https://github.com/gcc-mirror/gcc/commit/357c435 and https://github.com/gcc-mirror/gcc/commit/49a714e Reference: https://github.com/msys2/MINGW-pa... — committed to lazka/MINGW-packages by Astrum-polaris 3 years ago

Most upvoted comments

perfect, that confirms the cause and the fix.

lazka on May 6, 2021

Since this is a crash in _setjmpex, I think it’s the same bug as (or related to) gcc PR100402.

ssbssa on May 4, 2021

Here’s my test results

Revert 0202-backport-357c435.patch only → still crash Revert 0201-backport-49a714e.patch and 0202-backport-357c435.patch → success

Edit: Realized 0202 is a fix on top of 0201 and previous comments suggest that when the initial crash happens, 0202 is not applied, so the first testcase is useless.

~~Next I will try to revert 0201 only and see if that works~~ on second thought, keeping 0202 without 0201 does not make much sense

Astrum-polaris on Apr 12, 2021

So I rebuilt winpthread 9.0.0.6158 with gcc 10.3.0 and tested Webots nightly, it crash at start-up just as described

Will revert the commit in 0202-backport-357c435.patch to see if the problem persists.

Astrum-polaris on Apr 12, 2021

was winpthread built with the last backport, or before that was applied? It could be that it would have benefitted from that fix also

It was build without the last backport (you can look at the .BUILDINFO file in each package for which versions were current at that time). Is it worth re-trying, or should we just wait for an official release?

Anyway, thanks for testing @omichel, glad we could pin down the cause.

lazka on Mar 10, 2021