On Wed Feb 8 19:01:54 2023 +0000, **** wrote:
> Paul Gofman replied on the mailing list:
> ```
> On 2/8/23 12:55, Rémi Bernon (@rbernon) wrote:
> >
> > USR1 / USR2 / INT for instance could be blocked in non-Wine threads,
> raising them again until they reach a Wine thread.
> I think USR1 may only be received by a non-Wine thread if it was
> originated by some native library and not by wineserver which sends that
> only to threads it knows? In that case, not sure how that can be handled
> better in a Wine thread?
> Also, is there a good way to block signals in threads which are created
> by native libraries, I think we don't know anything about those threads?
> ```
Yes, what Paul said. If a non-Wine thread gets USR1 or USR2 it didn't come from us, and handing it to a Wine thread is not going to do the right thing.
Note that signal masks are per-thread, but according to my understanding signal *actions* aren't.
QUIT is supposed to kill the entire process by default, not just a thread, so just killing that thread doesn't seem right. I suppose we *could* exit() in that case, but QUIT also dumps core by default, so it doesn't seem quite right to do a clean exit either. At least not right enough to be worth the extra complexity.
Rethrowing INT to a Wine thread is... nontrivial, but possible, I guess? I'd rather leave it for a follow-up patch if it's really worth doing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2126#note_23484
On Wed Feb 8 18:55:31 2023 +0000, Zebediah Figura wrote:
> > Should we really crash on any unexpected signal?
> All of the signals we catch are signals for which the default action
> specified by POSIX is to terminate. In the case of TRAP, SEGV, ILL, BUS
> we have no choice. That might be true for FPE too but I can't remember;
> but either way, either the program was expecting an exception and won't
> get it, or it was going to crash anyway.
> In the case of ABRT, QUIT, INT not terminating seems like the wrong
> thing to do (and we can't handle them the normal way because we don't
> have a TEB and can't contact the server).
> We could potentially ignore USR1 and USR2, but that doesn't seem great
> for stability. Whatever was sending them had a reason to do so, and
> isn't going to function correctly.
> Perhaps more saliently, we were already crashing on unexpected signals,
> simply by virtue of trying to access the TEB and then dereferencing it.
> This patch just makes it more obvious.
Well we currently crash indeed but I don't think it is intentional. Making it explicit would make it look more like it is.
I'd think that instead we should block the signals in the threads that cannot handle them, or handle them in a way that doesn't require a TEB.
USR1 / USR2 / INT for instance could be blocked in non-Wine threads, raising them again until they reach a Wine thread. I think QUIT should be handled properly by calling `pthread_cancel` or `pthread_exit` and letting the thread cleanup properly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2126#note_23475
Without this patch the process will silently die.
I managed to trigger this while trying to trace Child of Light with Renderdoc,
the latter of which crashed in its own "TargetControlServerThread".
This, confusingly, manifested in the game restarting itself without the Ubisoft
overlay; apparently the game or one of its launchers was capable of recognizing
when the process had died and restarting it, but would not try to inject the
overlay a second time. I have not investigated the cause of the crash; it is not
unlikely that it resulted from the overlay injection (despite the fact that that
should only directly affect PE code.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2126
While running in XCode's profiler, I noticed two memory leaks in `interp_redim_preserve`.
After looking at `interp_redim`, the `bounds` structure is freed.
I've updated `interp_redim_preserve` to free `bounds` when the array is NULL and not NULL.
--
v5: vbscript: Fix memory leak in Split()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2132
While running in XCode's profiler, I noticed two memory leaks in `interp_redim_preserve`.
After looking at `interp_redim`, the `bounds` structure is freed.
I've updated `interp_redim_preserve` to free `bounds` when the array is NULL and not NULL.
--
v4: vbscript: Fix memory leak in interp_redim_preserve
https://gitlab.winehq.org/wine/wine/-/merge_requests/2132
The Rutoken driver installer tries to start this service, and fails if it
doesn't exist.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54396
--
v2: scardsvr: Add stub service.
wine.inf: Always use FLG_ADDREG_APPEND for SvcHost entries.
setupapi: Create the registry value if it doesn't exist in append_multi_sz_value().
setupapi: Fail installation when trying to append to a registry value of the wrong type.
setupapi/tests: Add tests for FLG_ADDREG_APPEND.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2073