https://bugs.winehq.org/show_bug.cgi?id=49301
Bug ID: 49301 Summary: pthread_exit hangs on unwind through call_thread_exit_func on arm64 Product: Wine Version: unspecified Hardware: aarch64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: stefan@codeweavers.com Distribution: ---
Created attachment 67309 --> https://bugs.winehq.org/attachment.cgi?id=67309 Workaround
My arm64 Wine build spins in services.exe after starting up anything. The backtrace points into pthread_exit() - see attached file backtrace.txt.
I placed pthread_exit calls throughout the thread creation / shutdown code and it works up to the point where signal_exit_thread() calls call_thread_exit_func(). After call_thread_exit_func() passes control to the C function exit_thread() pthread_exit() will hang.
I previously had this problem only in a gcc wine build (with 8fb8cc03 reverted), but recently, presumably after an update to clang-10, the problem also happens when building Wine with clang. The attached backtrace is from a build with clang 10.
Calling exit_thread() directly from signal_exit_thread() without going through call_thread_exit_func works around the problem. See attached file noasm.diff
https://bugs.winehq.org/show_bug.cgi?id=49301
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 67310 --> https://bugs.winehq.org/attachment.cgi?id=67310 Backtrace
This file shows a backtrace of the hung thread. I did not notice this before, but gdb also struggles with the asm code.
https://bugs.winehq.org/show_bug.cgi?id=49301
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=49301
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 67312 --> https://bugs.winehq.org/attachment.cgi?id=67312 Add CFI info to call_thread_exit_func
This patch makes threads exit properly for me. I think it goes in the right direction, but I would be highly surprised if all the numbers in it are correct.
It specifies the call frame setup done at the start of start_thread(), because after the mov %sp points to the 'old' stack as set up in start_thread, not whatever happened before call_thread_exit_func was called.
I am worried that gdb still can't unwind the backtrace through call_thread_exit_func and start_thread. I would expect to see signal_start_thread, thread.c:start_thread and then the pthread creation functions below call_thread_exit_func.
https://bugs.winehq.org/show_bug.cgi?id=49301
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Keywords| |patch