From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 03:56:32 2019 Received: (at 38309) by debbugs.gnu.org; 26 Nov 2019 08:56:32 +0000 Received: from localhost ([127.0.0.1]:50184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZWe8-0005a1-EF for submit@debbugs.gnu.org; Tue, 26 Nov 2019 03:56:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZWe6-0005Zl-JT for 38309@debbugs.gnu.org; Tue, 26 Nov 2019 03:56:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iZWe1-0000un-Cb; Tue, 26 Nov 2019 03:56:25 -0500 Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=35474 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iZWe0-0006TS-R2; Tue, 26 Nov 2019 03:56:25 -0500 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer 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> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 6 Frimaire an 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 26 Nov 2019 09:56:22 +0100 In-Reply-To: <87zhgjthan.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 26 Nov 2019 13:04:00 +0900") Message-ID: <87y2w3c8y1.fsf@gnu.org> 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-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: -3.3 (---) 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/5j6w0x3aq0i5r9565w92lr= h016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #1 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lr= h016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #2 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lr= h016vlmv2d-pcre-8.43/lib/libpcre.so.1 > [...] > #17435 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w9= 2lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #17436 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w9= 2lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #17437 0x00007ffff78399c6 in match () from /gnu/store/5j6w0x3aq0i5r9565w9= 2lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #17438 0x00007ffff784a441 in pcre_exec () from /gnu/store/5j6w0x3aq0i5r95= 65w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1 > #17439 0x00007ffff7ceca8b in g_match_info_next () from /gnu/store/b8pr2k0= i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0 > #17440 0x00007ffff7cee21f in g_regex_match_full () from /gnu/store/b8pr2k= 0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0 > #17441 0x00007ffff7cee36a in g_regex_match () from /gnu/store/b8pr2k0i2zd= 07zmb7kpffmcimqi337if-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? Thanks, Ludo=E2=80=99.