Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v10: ntdll: Remove now unnecessary arch-specific exit frame.
ntdll: Avoid calling pthread_exit from abort_thread.
ntdll: Avoid calling abort_thread from the signal stack.
ntdll: Use is_inside_syscall more consistently.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088
Windows gives this content special protection from being painted over, by some means that I have not investigated yet.
Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3416
--
v3: d3d10/effect: Add 'ceil' instruction for expressions.
d3d10/effect: Add 'dot' instruction support for expressions.
d3d10/effect: Add trigonometric instructions support for expressions.
d3d10/effect: Add support for shift instructions.
d3d10/effect: Add 'or' instruction support for expressions.
d3d10/effect: Add more integer instructions for expressions.
d3d10/effect: Add signed integer compare instructions for expressions.
d3d10/effect: Implement instructions used for signed integer division.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1684
This avoids stalling the pipeline when upstream nodes have not given enough samples for processing. If there are multiple upstream nodes, request samples in a round-robin fashion.
This fixes an issue where the intro audio of the game Airborne Kingdom stops playing after a few seconds.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2684
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v24: winesni.drv: add dbus watch instead of using plain unix fds and flush
winesni.drv: replaced the dbus connection logic with a single connection per each SNI object
winesni.drv: wrap functions with pthread mutex locking
winesni.drv: implement basic balloon notification support
explorer: add winesni.drv tray implementation support
winesni.drv: add KDE StatusNotifierItem implementation for tray
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372