Re: [Bug hurd/24110] SS_DISABLE never set in stack_t value returned by sigaltstack

[Samuel Thibault]

Svante Signell, le jeu. 24 janv. 2019 12:11:25 +0100, a ecrit:
> I've built and installed glibc-2.28-5 with the patches in
> https://sourceware.org/bugzilla/show_bug.cgi?id=24110

Thanks!

> threadinit-set-SS_DISABLE.patch and sigaltstack-set-SS_DISABLE.patch
> with an equals sign in the first patch
> ss->sigaltstack.ss_flags = SS_DISABLE;
> not adding to the ss_flags as in Samuels patch
> ss->sigaltstack.ss_flags |= SS_DISABLE;
> 
> I don't know which version is the correct one! Please advise.

Both would be correct actually, since the memset above sets it to 0.

> However, the test programs works fine: foo.c gives:
> 
> main-thread sigaltstack: enabled=no onstack=no sp=0x0 size=0x0
> alternate stack installed
> main-thread sigaltstack: enabled=yes onstack=no sp=0x1ff9cdf size=0xa000
> thread2 running
> thread2 sigaltstack: enabled=no onstack=no sp=0x0 size=0x0
> thread2 alternate stack installed
> thread2 sigaltstack now: enabled=yes onstack=no sp=0x2ffbf7f size=0xa000
> main-thread sigaltstack: enabled=yes onstack=no sp=0x1ff9cdf size=0xa000
> SUPPORTED

Good :) I'll commit the fix then.

(I guess you tested that the same tests do fail with a non-patched
glibc).

> I've also run the libgo tests in gcc-9-9-20190120-1 and all 13 failing tests
> returning "Illegal instruction (SIGILL)" now does not with the patched glibc.

Great :)

> However, all these tests are still failing, but now mainly with SIGABRT or
> "signal 20 (SIGCHLD) received but handler not on signal stack" or "signal 30
> (SIGUSR1) received but handler not on signal stack".
> 
> So I think there are still more bugs to hunt down.

Yep, but there is most probably some progress here, and possibly it'll
be easier to track down such explicit abort than a SIGILL from out of
space.

Samuel