From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Date: Thu, 10 May 2018 02:50:32 -0400 Message-ID: <87fu30dmx3.fsf@netris.org> References: <877exuj58y.fsf@gnu.org> <87d0yo1tie.fsf@gnu.org> <87fu3124nt.fsf@gnu.org> <87d0y5k6sl.fsf@netris.org> <871sel6vnq.fsf@igalia.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGfQr-0003Gy-Mg for bug-guix@gnu.org; Thu, 10 May 2018 02:52:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGfQo-0003ya-Ks for bug-guix@gnu.org; Thu, 10 May 2018 02:52:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:47975) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fGfQo-0003yK-I0 for bug-guix@gnu.org; Thu, 10 May 2018 02:52:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <871sel6vnq.fsf@igalia.com> (Andy Wingo's message of "Wed, 09 May 2018 11:11:21 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Andy Wingo Cc: 28211@debbugs.gnu.org Hi Andy, 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? Thanks, Mark