Hello again, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer 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