Michael Kelly, le mer. 21 janv. 2026 17:33:16 +0000, a ecrit:
> On 21/01/2026 17:11, Samuel Thibault wrote:
> > Michael Kelly, le mer. 21 janv. 2026 13:15:12 +0000, a ecrit:
> > > Has this issue with signal handling been resolved?
> > No, and I don't know if it's really related to signal handling actually,
> > it could also be user/user or user/kernel context switch management in
> > mach.
>
> I couldn't yet offer any certainty as to the cause of the problem that I see
> but it certainly seems to be triggered by multiple signals.
Ah, sorry, now I remember: when disabling preemption by signals in ghc,
I'm not getting it. So somehow it probably related to signals. But
then how exactly it's not clear since I have investigated sigreturn at
length, and the testcase passes. Possibly it's the state management on
calling the signal handler that has issues.
> 6269: 2 SIGALRMs in memset
> 6267(19893): Non zero at index: 19472
> 6267: 2 SIGALRMs in memset
> 6267(24924): Non zero at index: 63456
> 6267: 2 SIGALRMs in memset
>
> Is my test case (and stress-ng) doing something very silly?
C assumes that nothing happens outside its own execution flow, so
whatever happens otherwise,
> while (1)
> {
> nalrms_inmemset = 0;
>
> inmemset = 1;
> (void)memset(buf, 0x00, SZ);
> inmemset = 0;
>
> size_t n = 0;
>
> while (n < SZ)
> {
> if (buf[n] != 0)
> {
> fprintf(stderr, "%d(%ld): Non zero at index: %zu\n",
> getpid(), iterations, n);
That is not supposed to happen.
> n = SZ;
> }
> else
> n++;
> }
>
> if (nalrms_inmemset > 1)
> fprintf(stderr, "%d: %d SIGALRMs in memset\n", getpid(),
> nalrms_inmemset);
>
> iterations++;
> }
> > > I've seen some fixes in glibc (eg. hurd/x86_64/htl/pt-machdep.c)
> > Which fix are you thinking about? The only related fix is
> > e539a269990dac3ff4d2432c0eb6966a5ee4f274
> > ("hurd: Fix sigreturn clobbering some xmm registers")
> > which should help, but does not completely fix the issue.
>
> I did include the above and also the following which might not be relevant
> anyway:
>
> commit 0bbeb1fd13ba4d30cd7ec977e1ab6c22d7bf8b7f
> Date: Sat Jan 17 15:15:33 2026 +0100
> hurd: make __thread_set_pcsptp align stack
It is not, it's just a crash on pthread_cancel().
Samuel
