bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2

[Andy Wingo <wingo@igalia.com>]

On Thu 10 May 2018 08:50, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@igalia.com> writes:
>
>> On Wed 09 May 2018 02:32, Mark H Weaver <mhw@netris.org> writes:
>>
>>> However, I think it's _far_ more likely that the NULL argument on the
>>> stack was copied from memory shared by multiple threads without proper
>>> thread synchronization.
>>
>> I think this is unlikely on x86 given its total-store-ordering memory
>> model.  I agree with you about the value of barriers, but I don't think
>> they are part of this bug that Ludo is seeing.
>
> I think you're forgetting about the C compiler.  It's true that x86
> machine code has a TSO memory model, but C does not.  In the absence of
> barriers, the C compiler may freely reorder stores to non-volatile,
> non-atomic objects.  In particular, it is free to reorder the
> initialization of an object with the write of that object's address.
>
> I admit that I haven't checked whether GCC 5.5.0 does this in practice.
> Do you have reason to believe that it never does so?

Oh I agree with you here as well, and compiler reordering could well be
happening here.  My suspicions are however that it's not happening.  In
libguile, we rarely mutate shared state, and in that case it's usually
within mutexes.  The main source of mutation in libguile is
initialization -- but there that's on a fresh object local to a thread,
and we try to avoid publishing that object to other threads without a
barrier (atomic or mutex), and in any case such publishing is usually
outside of the region that a compiler can work on.

There is the possibility of mutation via e.g. vector-set!, but hopefully
we aren't doing that on shared data; likewise in Scheme there are
barriers (the atomic box instructions and mutexes, both of which are
compiler barriers as well).  It's still possible to write Scheme
programs with races, of course, but I don't think that's what's
happening here.

I could be misunderstanding things of course!

Andy