From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 22:12:42 2019 Received: (at 38309) by debbugs.gnu.org; 27 Nov 2019 03:12:42 +0000 Received: from localhost ([127.0.0.1]:53259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZnkw-0001MR-DX for submit@debbugs.gnu.org; Tue, 26 Nov 2019 22:12:42 -0500 Received: from mail-qt1-f179.google.com ([209.85.160.179]:35169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZnku-0001MB-I6 for 38309@debbugs.gnu.org; Tue, 26 Nov 2019 22:12:41 -0500 Received: by mail-qt1-f179.google.com with SMTP id n4so23892807qte.2 for <38309@debbugs.gnu.org>; Tue, 26 Nov 2019 19:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=+4rtJnJfJWMsmoatevLD6D36cGRA/j/s97nOFajJM+c=; b=mlpLyZHLHIjIRBhgjkEpTLWNGVGy3WmSPgZwk4Or/RfXS47j18xGFPp9IOEqIYqWFm pkkZIeDpi67QINwLOy4cNP+oqKyhUuW1zf37npxI210lNm7chNcBLfLWH98Te85vS6am YCBYSKsyRc6bS1lAfKyGHaVzydfOKkV0LuaSTDqIwbr6TTp+jUYV4L4oWRJ2x2SvJxGN 39VZIl+RrVJy5Mih9cdCvjfYzqhkrxQhb9lRLyXGv2sP8vNs4Mr/Gt9T16uugnBqNT8L wr58zAmEbEDsq0O0pn0ZW/3gCQ4ihBxC4ED0ccwQoLbMbv9iYAT/61wfX8CiANsY5IPO O/ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=+4rtJnJfJWMsmoatevLD6D36cGRA/j/s97nOFajJM+c=; b=A4zvSX1GuLoKtAFoSSReqw4kmWsqoGwa5X8b5M861PwIvFjH47BLN+QhYHpNYGvjX/ 49bWLgfKFBEGM3D07zXPBSt4PQRrvNCsUnIjKuFWnp8F1inoXbAJg4wfB1j0z4LB1G9b gO+vaHcvnJag+LTAgGysJSP9cT1fZbK/T5kGnWve98FiBRkVns8XzkZiQtrB8+i6EohG 1UpA/tVOHGGtHfrdEK3f5AXV0Eq1Odnefec6axeiwOytelI199u6HwmQ0NHx5YbrmWNH r2fHK/Ryc+1BLhuweNA0UZ6GN08JXN5hCXugh0aafiyD5gQd/IRGT0OSL00a1aueY2Qn cFUA== X-Gm-Message-State: APjAAAVyXYUxJRGxx9uavuV2a41lRPRmuTcbpoOonS5h1+Alo7kdm5V2 5Rtv66b8CgQGzlGLFuR2yWjacUfw X-Google-Smtp-Source: APXvYqwM2mPlmr3CgB4allIgpF/g0lDwGTK0QpI1fwXgJvWKwxikhIFsmaOIPvhluZ9p/nT43ZIc+w== X-Received: by 2002:ac8:3f02:: with SMTP id c2mr21427030qtk.172.1574824354839; Tue, 26 Nov 2019 19:12:34 -0800 (PST) Received: from x200 (dsl-152-52.b2b2c.ca. [66.158.152.52]) by smtp.gmail.com with ESMTPSA id h4sm6157543qkk.128.2019.11.26.19.12.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2019 19:12:33 -0800 (PST) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session References: <87y2w8vzeq.fsf@lassieur.org> <8736egaw7g.fsf@gmail.com> <87k17rvmfw.fsf@gmail.com> <87eexy1nah.fsf@gnu.org> <87d0diuec0.fsf@gmail.com> <875zj9yx8f.fsf@gnu.org> <87zhgjthan.fsf@gmail.com> <87y2w3c8y1.fsf@gnu.org> Date: Wed, 27 Nov 2019 12:12:32 +0900 In-Reply-To: <87y2w3c8y1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 26 Nov 2019 09:56:22 +0100") Message-ID: <87v9r6t3kv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38309 Cc: Mathieu Othacehe , 38309@debbugs.gnu.org, a@ajgrf.com 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: -1.0 (-) Hello Ludovic, Ludovic Court=C3=A8s writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> I could reproduce the gnome-session crash by generating a Guix VM with >> the attached OS configuration (it has about 100 Emacs packages installed >> to its system profile, which gives an EMACSLOADPATH length of about >> 13000 characters), and got the following backtrace (no debugging >> symbols): >> >> #0 0x00007ffff7837e27 in match () from /gnu/store/5j6w0x3aq0i5r9565w92l= rh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #1 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92l= rh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #2 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92l= rh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> [...] >> #17435 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w= 92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #17436 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w= 92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #17437 0x00007ffff78399c6 in match () from /gnu/store/5j6w0x3aq0i5r9565w= 92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #17438 0x00007ffff784a441 in pcre_exec () from /gnu/store/5j6w0x3aq0i5r9= 565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 >> #17439 0x00007ffff7ceca8b in g_match_info_next () from /gnu/store/b8pr2k= 0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0 >> #17440 0x00007ffff7cee21f in g_regex_match_full () from /gnu/store/b8pr2= k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0 >> #17441 0x00007ffff7cee36a in g_regex_match () from /gnu/store/b8pr2k0i2z= d07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0 >> #17442 0x000000000042b779 in gsm_util_export_activation_environment () >> #17443 0x000000000040adde in main () >> >> This tells us that the problem originates from glib. Looking at the >> number of match calls, libpcre is probably blowing up its stack as >> described in this ticket [0]. According to this link, it seems glib >> should be making use of PCRE's facilities to limit the depth of search, >> e.g. by using "match limit" and "recursion limit" as documented here [1] >> (search for "int pcre_exec(" on that page). >> >> Parallel to this, perhaps the regexp used by glib could be rewritten to >> not rely as much on the stack. > > Oh great, thanks for investigating! > > I have a shallow understanding of the issues, but (1) are we not going > overboard with that big a environment variable? :-), and (2) fixing GLib > or PCRE would require a full rebuild, can you think of a way to work > around the issue? About (1); it's definitely bigger than others environment variables we set in Guix (but not that different from PYTHONPATH when it is used on the build side), but it hasn't posed a problem so far outside of glib. I think having a recursive EMACSLOADPATH could be useful here and more convenient for all Emacs users, so probably would be a welcome change in upstream Emacs. That'd reduce the length of our EMACSLOADPATH greatly. I'm also interested in studying if we could use package.el to do the load the autoloads files and put the packages present under a directory in the load-path of Emacs. It seems its variable `package-user-dir' could play a role there. About (2), I was thinking about using grafts -- IIUC this is one use case where they can be useful (to fix a bug and avoid rebuilding many packages). Maxim