Hello Ludovic,
Ludovic Courtès <l...@gnu.org> writes:
> Hi Maxim,
>
> Maxim Cournoyer <maxim.courno...@gmail.com> 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?
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
