bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

[Maxim Cournoyer]

Hello again,

Ludovic Courtès <address@hidden> writes:

> Hi Maxim,
>
> Maxim Cournoyer <address@hidden> skribis:
>
>> There would be a couple more commits to include in the revert to undo
>> the changes (one to the build system, others to adapt the renaming of
>> the emacs-set-load-path phase for some packages:
>
> Oh indeed.
>
> I must say I haven’t looked closely at the changes nor at the reasons
> for the regression, but IIUC, the regression is serious enough that we
> should have a way to address it quickly.

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):

--8<---------------cut here---------------start------------->8---
#0  0x00007ffff7837e27 in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#1  0x00007ffff78467de in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#2  0x00007ffff783ac48 in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
[...]
#17435 0x00007ffff78467de in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17436 0x00007ffff783ac48 in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17437 0x00007ffff78399c6 in match () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17438 0x00007ffff784a441 in pcre_exec () from 
/gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17439 0x00007ffff7ceca8b in g_match_info_next () from 
/gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17440 0x00007ffff7cee21f in g_regex_match_full () from 
/gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17441 0x00007ffff7cee36a in g_regex_match () from 
/gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17442 0x000000000042b779 in gsm_util_export_activation_environment ()
#17443 0x000000000040adde in main ()
--8<---------------cut here---------------end--------------->8---

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.

[0]  https://bugs.exim.org/show_bug.cgi?id=2126
[1]  https://pcre.org/original/doc/html/pcreapi.html