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

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <address@hidden> 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/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 ()
>
> 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’.