On Thu 10 May 2018 08:50, Mark H Weaver writes: > Andy Wingo writes: > >> On Wed 09 May 2018 02:32, Mark H Weaver 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