[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28211: Stack marking issue in multi-threaded code, 2020 edition
From: |
Andy Wingo |
Subject: |
bug#28211: Stack marking issue in multi-threaded code, 2020 edition |
Date: |
Tue, 17 Mar 2020 22:16:22 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
On Thu 12 Mar 2020 22:59, Ludovic Courtès <address@hidden> writes:
> I think I’ve found another race condition involving stack marking, as a
> followup to <https://issues.guix.gnu.org/issue/28211> (this time on
> 3.0.1+, but the code is almost the same.)
>
> ‘abort_to_prompt’ does this:
>
> fp = vp->stack_top - fp_offset;
> sp = vp->stack_top - sp_offset;
>
> /* Continuation gets nargs+1 values: the one more is for the cont. */
> sp = sp - nargs - 1;
>
> /* Shuffle abort arguments down to the prompt continuation. We have
> to be jumping to an older part of the stack. */
> if (sp < vp->sp)
> abort ();
> sp[nargs].as_scm = cont;
> while (nargs--)
> sp[nargs] = vp->sp[nargs];
>
> /* Restore VM regs */
> vp->fp = fp;
> vp->sp = sp;
> vp->ip = vra;
>
>
> What if ‘scm_i_vm_mark_stack’ walks the stack right before the ‘vp->fp’
> assignment? It can determine that one of the just-assigned ‘sp[nargs]’
> is a dead slot, and thus set it to SCM_UNSPECIFIED.
I think you're right here.
Given that the most-recently-pushed frame is marked conservatively, I
think it would be sufficient to reset vp->fp before shuffling stack
args; that would make it so that the frame includes the values to
shuffle, their target locations, and probably some other crap in
between. Given that marking the crap is harmless, I think that would be
enough. WDYT?
In a more perfect world, initiating GC should tell threads to reach a
safepoint and mark their own stacks -- preserves thread locality and
prevents this class of bug. But given that libgc uses signals to stop
threads, we have to be less precise.
Cheers,
Andy