From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.comp.gdb.patches,gmane.lisp.guile.devel Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile Date: Tue, 02 Sep 2014 18:25:25 +0300 Message-ID: <83iol6f3iy.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1409671531 21544 80.91.229.3 (2 Sep 2014 15:25:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Sep 2014 15:25:31 +0000 (UTC) Cc: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org To: Doug Evans Original-X-From: gdb-patches-return-115471-gdb-gdb-patches=m.gmane.org@sourceware.org Tue Sep 02 17:25:25 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 1XOpxU-0005BS-Bu for gdb-gdb-patches@plane.gmane.org; Tue, 02 Sep 2014 17:25: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:date:from:subject:in-reply-to:to:cc:reply-to :message-id:mime-version:content-type:content-transfer-encoding :references; q=dns; s=default; b=eUxcGztJSsdxPFBxHUB0qR7eNJiFfty lKmUOJ1HkzSiLvJcaQ8kNzQRGibl8h7WEo6x4Hc+z2ffRSHtKHuD+Er5QmINf+vk YAKsrpfV8SrRG1wJcsmTyg2G/5uI3DU2iuYffJT6bnO0H82gvIuje+ydDSmeArJ4 Lv4jkDY9wqnk= 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:date:from:subject:in-reply-to:to:cc:reply-to :message-id:mime-version:content-type:content-transfer-encoding :references; s=default; bh=CWRMGRhXPn9JzuggUS6OzquvSHQ=; b=vPO5a hTOT/CxDbuvbrmRZ1uTs9Q3Gt3jG68c46C5ugHwkiVu08DMEkPd7BAVIAh8e7RLH FucBwIKTdASCM+nVej9w1eafT+VCHEX0dwh8uRfB1k2WKZvM3YFEcZooUw8YNnTc MQT0KGDxIhTgyoedgm6C8YuwWNZ6gcy4wnM04M= Original-Received: (qmail 14609 invoked by alias); 2 Sep 2014 15:25:21 -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 14598 invoked by uid 89); 2 Sep 2014 15:25:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Original-Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Sep 2014 15:25:18 +0000 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NBA002005A0FG00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Tue, 02 Sep 2014 18:25:15 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBA001U05I3HEB0@a-mtaout20.012.net.il>; Tue, 02 Sep 2014 18:25:15 +0300 (IDT) In-reply-to: X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gdb.patches:100452 gmane.lisp.guile.devel:17390 Archived-At: > Date: Mon, 1 Sep 2014 15:04:16 -0700 > From: Doug Evans > Cc: Ludovic Courtès , > guile-devel , > "gdb-patches@sourceware.org" > >> Eli Zaretskii skribis: >> >> > Perhaps we should request GC and Guile to provide capabilities to >> > disable threads at run time, then. >> >> I don’t think we need to go this far: reading the recent discussions, it >> seems Doug found a way to make sure Guile’s and libgc’s internal threads >> don’t receive signals that GDB is interested in, which should be enough >> for practical purposes. > > That's just the tip of an iceberg, I'm afraid. > > In the interests of seeking clarification early and clearly, can you elaborate? > > 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.