From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 03:53:32 2018 Received: (at 28211) by debbugs.gnu.org; 10 May 2018 07:53:32 +0000 Received: from localhost ([127.0.0.1]:55899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fGgOJ-0001Jn-Qc for submit@debbugs.gnu.org; Thu, 10 May 2018 03:53:32 -0400 Received: from pb-sasl2.pobox.com ([64.147.108.67]:61318 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fGgOH-0001Jc-6c for 28211@debbugs.gnu.org; Thu, 10 May 2018 03:53:30 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id A664EBBF09; Thu, 10 May 2018 03:53:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=I3hlac/o9cjgXtaD0KuPSBpq5DU=; b=Ofpj5p 2ArAknyPgW6E39iR5YXzOuUf1oZqvqARQ+ZLzpTgHW9O5nQqLzQP+I0K8TGamqgw LN/Zp+5MNrSBWsDLKv2n6huNJdu8vWGzX1WTKkiX5cPJHMSiZH1s1O0Wnva3G18o /PnKYJJ0KlNvh3vCIH/9QAJ1tLlHZJPp3RUSc= Received: from pb-sasl2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id 9F71BBBF08; Thu, 10 May 2018 03:53:28 -0400 (EDT) Received: from sparrow (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id AD8C5BBF07; Thu, 10 May 2018 03:53:26 -0400 (EDT) From: Andy Wingo To: Mark H Weaver Subject: Re: bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 References: <877exuj58y.fsf@gnu.org> <87d0yo1tie.fsf@gnu.org> <87fu3124nt.fsf@gnu.org> <87d0y5k6sl.fsf@netris.org> <871sel6vnq.fsf@igalia.com> <87fu30dmx3.fsf@netris.org> Date: Thu, 10 May 2018 09:53:18 +0200 In-Reply-To: <87fu30dmx3.fsf@netris.org> (Mark H. Weaver's message of "Thu, 10 May 2018 02:50:32 -0400") Message-ID: <87tvrg3q1d.fsf@igalia.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 38E43AD4-5427-11E8-8726-B479894C8D7C-02397024!pb-sasl2.pobox.com X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28211 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 28211@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) 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