From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Doug Evans Newsgroups: gmane.comp.gdb.patches,gmane.lisp.guile.devel Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile Date: Fri, 05 Sep 2014 01:26:28 -0700 Message-ID: References: <834mwsh2nu.fsf@gnu.org> <8338ccgj78.fsf@gnu.org> <87ppffabw8.fsf@gnu.org> <83y4u3flr2.fsf@gnu.org> <87r3zv71qy.fsf@gnu.org> <83vbp7fer3.fsf@gnu.org> <83iol6f3iy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409905651 19223 80.91.229.3 (5 Sep 2014 08:27:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 08:27:31 +0000 (UTC) Cc: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org To: Eli Zaretskii Original-X-From: gdb-patches-return-115547-gdb-gdb-patches=m.gmane.org@sourceware.org Fri Sep 05 10:27:24 2014 Return-path: Envelope-to: gdb-gdb-patches@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPorc-0001Or-1G for gdb-gdb-patches@plane.gmane.org; Fri, 05 Sep 2014 10:27:24 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=IsVoTYleRJ7uQ1cF2g58OuqZxTXdCIWzyKjQmFP8o7Z EuAhAiLK2ZnfGzLRSsFGcYpP6OIyUQ9tc525q7SdZ668wXlGXkjNkAaqQWcIqBqp /rvI6+Sy2AYwctKqR6x8FoyhUx7a5oetqijjEHLMyrSDpDHJY3Hr2aqi2uZsE7sc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=2fwX6Et/rYhaF19x+IN14YS6xFU=; b=Vc7Nz1L2wQSrE0QtM dz2k0tbttpvWeQvxZt0hviXjHcztw7FSJ1x+Eeb13s+8Zj/yTosvjA4bcw5RQkgK DsEEEPTjnRM3fJYTZLi7999+xCUrEeZZd1kzDiCyjN7vz2C9rauG/IZw+qEVbQc8 BQFp+JAgvyoi3DX8PnUdB9X1ZA= Original-Received: (qmail 1932 invoked by alias); 5 Sep 2014 08:27:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: gdb-patches-owner@sourceware.org Original-Received: (qmail 1914 invoked by uid 89); 5 Sep 2014 08:27:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f181.google.com Original-Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 05 Sep 2014 08:27:17 +0000 Original-Received: by mail-ie0-f181.google.com with SMTP id rp18so13264955iec.40 for ; Fri, 05 Sep 2014 01:27:15 -0700 (PDT) X-Received: by 10.67.23.70 with SMTP id hy6mr19033464pad.30.1409905632637; Fri, 05 Sep 2014 01:27:12 -0700 (PDT) Original-Received: from seba.sebabeach.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id ou6sm1128166pbb.88.2014.09.05.01.27.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Sep 2014 01:27:11 -0700 (PDT) In-Reply-To: <83iol6f3iy.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2014 18:25:25 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gdb.patches:100525 gmane.lisp.guile.devel:17411 Archived-At: Eli Zaretskii writes: >> Date: Mon, 1 Sep 2014 15:04:16 -0700 >> From: Doug Evans >> Cc: Ludovic Court=C3=A8s ,=20 >> guile-devel ,=20 >> "gdb-patches@sourceware.org" >>=20 >>> Eli Zaretskii skribis: >>> >>> > Perhaps we should request GC and Guile to provide capabilities to >>> > disable threads at run time, then. >>> >>> I don=E2=80=99t think we need to go this far: reading the recent discus= sions, it >>> seems Doug found a way to make sure Guile=E2=80=99s and libgc=E2=80=99s= internal threads >>> don=E2=80=99t receive signals that GDB is interested in, which should b= e enough >>> for practical purposes. >> >> That's just the tip of an iceberg, I'm afraid. >>=20 >> In the interests of seeking clarification early and clearly, can you ela= borate? >>=20 >> I'm not saying there aren't issues, I'm just wondering if you have >> anything specific that you are thinking of. > > OK, but if no one except myself sees the danger, then that's about the > last time I'm writing about this, and will hold my peace thereafter. > > With that out of my way... > > Basically, anything you can do in Guile that somehow causes > process-wide changes would present a problem, if Guile threads are > allowed in GDB. Here are a few examples that come to mind: > > . redirection of standard descriptors (I already mentioned this in my > initial message in this discussion) > > . changing environment variables with setenv/unsetenv > > . changing the current directory with chdir > > . changing the process's umask > > . calling setuid/seteuid or setsid > > . changing the priority or affinity of the process > > . setting or changing signal handlers, or raising signals > > . setting or canceling interval timers > > . changing resource limits with setrlimit > > The full list is almost infinite, since Guile supports foreign > libraries via libffi and libltdl. So a Guile extension can load any > code that might call any API. > > Since GDB is itself a program that uses at least some of the low-level > OS interfaces that underly the above Guile functionalities, the danger > of core GDB and threads running Guile extensions stomping onto each > other's feet is not just theoretical, IMO. > > Moreover, the proposed solutions only address the issues we know about > at this time. Both GC and Guile are being actively maintained, so > there's a real danger they will introduce more features whose use from > a separate thread will present problems beyond those known today. I > predict this to be a constant source of maintainers' headache. We > will probably see more incidents like this one, where we released a > seriously flawed GDB. > > We had our share of similar problems in Emacs compiled with GTK, where > it turned out that GTK launches threads at will, and some of those > threads manipulate signals and even start subprocesses(!). There are > several horror stories in the Emacs bug tracker about related > hard-to-debug crashes caused, e.g., by GTK usurping SIGCHLD while > Emacs was waiting for a subprocess to terminate. > > In a single-threaded program, a well-behaved Guile extension can at > least minimize the damage by restoring the global state immediately > after doing whatever it needed the change in that state for. But if > the extension code runs in a separate thread, there's no way of doing > that safely and reliably. > > We could introduce some synchronization mechanism, whereby, for > example, GDB's main thread could cause all other threads stop in their > tracks while it is accessing some global resource, and then resumes > them. But that means added complexity, and doesn't entirely fix the > problem (e.g., a chdir call that doesn't return to the original > directory could still cause harm to core GDB). > > So I suggest to think about this now, rather than bearing the > maintenance burden in the years to come. I'm happy to leave users to their own devices, we can't physically prevent them from starting threads. We pretty much leave them that way already given the myriad of things they can do to mess up gdb without threads. The python side of things is too silent on whether threads are supported there. https://sourceware.org/gdb/current/onlinedocs/gdb/Basic-Python.html#Basic-P= ython The only thing it says with regards to threads is: "GDB takes care to mark its internal file descriptors as close-on-exec. However, this cannot be done in a thread-safe way on all platforms. Your Python programs should be aware of this and should both create new file descriptors with the close-on-exec flag set and arrange to close unneeded file descriptors before starting a child process." At any rate, the task at hand is getting gdb to work well with Guile, regardless of whether the user starts any threads, and that's the intent of the patch. I am happy to make the default value of GC_MARKERS be 1 (regardless of libgc version, and if not already set by the user) when initializing Gui= le, that will disable libgc marker threads.