Re: [PATCH v2 0/1] MR2126: ntdll: Print an error if we receive a signal not on the signal stack.

[Rémi Bernon]

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

[PATCH v2 0/1] MR2126: ntdll: Print an error if we receive a signal not on the signal stack.

[Paul Gofman]

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?