unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#28211: Stack marking issue in multi-threaded code, 2020 edition
       [not found]                 ` <87a74eznq1.fsf@pobox.com>
@ 2020-03-17 23:22                   ` Ludovic Courtès
  0 siblings, 0 replies; only message in thread
From: Ludovic Courtès @ 2020-03-17 23:22 UTC (permalink / raw)
  To: Andy Wingo; +Cc: 28211

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’.





^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-03-17 23:22 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <877exuj58y.fsf@gnu.org>
     [not found] ` <87d0yo1tie.fsf@gnu.org>
     [not found]   ` <87fu3124nt.fsf@gnu.org>
     [not found]     ` <87d0y5k6sl.fsf@netris.org>
     [not found]       ` <871sel6vnq.fsf@igalia.com>
     [not found]         ` <87fu30dmx3.fsf@netris.org>
     [not found]           ` <87tvrg3q1d.fsf@igalia.com>
     [not found]             ` <87a7rdvdm9.fsf_-_@gnu.org>
     [not found]               ` <87tv2tp74g.fsf_-_@gnu.org>
     [not found]                 ` <87a74eznq1.fsf@pobox.com>
2020-03-17 23:22                   ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès

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).