From: "Ludovic Courtès" <ludo@gnu.org>
To: Andy Wingo <wingo@igalia.com>
Cc: 28211@debbugs.gnu.org
Subject: bug#28211: Stack marking issue in multi-threaded code, 2020 edition
Date: Wed, 18 Mar 2020 00:22:37 +0100 [thread overview]
Message-ID: <87mu8ebm82.fsf@gnu.org> (raw)
In-Reply-To: <87a74eznq1.fsf@pobox.com> (Andy Wingo's message of "Tue, 17 Mar 2020 22:16:22 +0100")
Hi!
Andy Wingo <wingo@igalia.com> skribis:
> On Thu 12 Mar 2020 22:59, Ludovic Courtès <ludo@gnu.org> 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?
Sounds good. Following our discussion on IRC, I pushed what you
proposed as 89edd1bc2dcff50fb05c3598a846d6b51b172f7c. \o/
I confirmed with and without rr that it no longer triggers the dreaded
crash.
BTW, pro tip: to run ./meta/guile under rr, I do:
sed -i libguile/guile \
-e 's/exec /exec rr record -n --syscall-buffer-sig=SIGUSR1 /g'
where ‘-n’ disables stack switching.
> 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.
Yup, agreed.
Thanks,
Ludo’.
parent reply other threads:[~2020-03-17 23:22 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <87a74eznq1.fsf@pobox.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mu8ebm82.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=28211@debbugs.gnu.org \
--cc=wingo@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).