bug#58631: Shepherd crash on berlin

[Ludovic Courtès]

Same backtrace with debugging symbols for libgc and libc:

--8<---------------cut here---------------start------------->8---
(gdb) bt
#0  0x00007ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#1  <signal handler called>
#2  0x00007ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#5  0x00007ff30b2bc526 in __GI_abort () at abort.c:79
#6  0x00007ff30b7bb263 in GC_add_to_heap (bytes=<optimized out>, 
p=0x7fefd1f70000) at extra/../alloc.c:1232
#7  GC_expand_hp_inner (n=n@entry=2048) at extra/../alloc.c:1386
#8  0x00007ff30b7c2232 in GC_collect_or_expand 
(needed_blocks=needed_blocks@entry=1, 
    ignore_off_page=ignore_off_page@entry=0, retry=retry@entry=0) at 
extra/../alloc.c:1480
#9  0x00007ff30b7c25a8 in GC_allocobj (gran=gran@entry=7, kind=<optimized out>) 
at extra/../alloc.c:1543
#10 0x00007ff30b7c290f in GC_generic_malloc_inner (lb=lb@entry=112, 
k=k@entry=1) at extra/../malloc.c:191
#11 0x00007ff30b7c78da in GC_generic_malloc_many (lb=lb@entry=112, k=k@entry=1, 
    result=result@entry=0x7ff30b246e48) at extra/../mallocx.c:473
#12 0x00007ff30b87fb45 in scm_inline_gc_alloc (kind=SCM_INLINE_GC_KIND_NORMAL, 
idx=6, 
    freelist=0x7ff30b246e48) at gc-inline.h:79
#13 allocate_words_with_freelist (thread=0x7ff30b246d80, freelist_idx=6) at 
intrinsics.c:470
#14 0x00007ff300039f95 in ?? ()
#15 0x00007ff30b246d80 in ?? ()
#16 0x00007ff302a2f7e8 in ?? ()
#17 0x0000000000000040 in ?? ()
#18 0x00007ff30b88bb1c in scm_jit_enter_mcode 
(thread=thread@entry=0x7ff30b246d80, 
    mcode=0x7ff30231e75c "B", <incomplete sequence \340>, 
    mcode@entry=0x7ff302a2f7e8 "I\211\314I)\304I\203\374 \017\205\345\b") at 
jit.c:6038
#19 0x00007ff30b8e80c5 in scm_call_n (proc=<optimized out>, 
argv=argv@entry=0x7ffeae067878, 
    nargs=nargs@entry=1) at vm.c:1602
#20 0x00007ff30b862ea7 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
#21 0x00007ff30b88d729 in scm_primitive_load (filename=<optimized out>) at 
load.c:131
#22 0x00007ff30b8e5915 in vm_regular_engine (thread=0x7ff30b246d80) at 
vm-engine.c:972
#23 0x00007ff30b8e8029 in scm_call_n (proc=<optimized out>, 
argv=argv@entry=0x7ffeae067a58, 
    nargs=nargs@entry=1) at vm.c:1608
#24 0x00007ff30b862ea7 in scm_primitive_eval (exp=<optimized out>, 
    exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) 
load/lang) 
"/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/bin/shepherd") 
(quit)))) at eval.c:671
--8<---------------cut here---------------end--------------->8---

This means we’re hitting this ‘abort’ call:

--8<---------------cut here---------------start------------->8---
GC_INNER void GC_add_to_heap(struct hblk *p, size_t bytes)
{
    hdr * phdr;
    word endp;

    if (GC_n_heap_sects >= MAX_HEAP_SECTS) {
        ABORT("Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS");
    }
--8<---------------cut here---------------end--------------->8---

Indeed, the core dump weighs 13 GiB, so it looks like a memory leak (too
bad ‘info proc stat’ in GDB doesn’t work).

I have not observed it on any other machine.  The difference between
berlin and machines I have access to is that berlin is being hammered on
port 22, which means it gets to spawn sshd processes very often.  This
could be where the leak is.

Ludo’.