inferior process on core-updates crashes: mmap(PROT_NONE) failed

Done

Details

2 participants

Ludovic Courtès
Christopher Baines

Owner: unassigned

Submitted by: Christopher Baines

Severity: serious

Christopher Baines wrote on 9 Apr 2020 21:45

Recipients:(address . bug-guix@gnu.org)

Message-ID:87369c8mus.fsf@cbaines.net

Hey,

The Guix Data Service seems to be having trouble processing the

core-updates branch [1]

1: https://guix-patches-data.cbaines.net/repository/2/branch/core-updates

At some point, usually when extracting the information about lint

warnings, package derivations or system tests, the inferior guix repl

crashes.

Looking at some strace output (attached), a mmap system call fails with

ENOMEM, however I don't think my system was out of memory or that the

process was even using that much memory at the time.

I'm not trying to use the Guix Data Service much with the core-updates

branch, but I wouldn't want this issue to break the data at

data.guix.gnu.org once the core-updates changes are merged.

Any ideas?

Thanks,

Chris

Attachment: guix-inferior-strace

Ludovic Courtès wrote on 10 Apr 2020 11:41

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 40525@debbugs.gnu.org)

Message-ID:87a73jy8y9.fsf@gnu.org

Hi,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (4 lines)

> At some point, usually when extracting the information about lint

> warnings, package derivations or system tests, the inferior guix repl

> crashes.

Could you come up with a simpler reproducer? What do we need to send to

the inferior to reach that crash?

Thanks,

Ludo’.

Christopher Baines wrote on 10 Apr 2020 13:55

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40525@debbugs.gnu.org)

Message-ID:87y2r37dy8.fsf@cbaines.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (11 lines)> Hi,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> At some point, usually when extracting the information about lint
>> warnings, package derivations or system tests, the inferior guix repl
>> crashes.
>
> Could you come up with a simpler reproducer?  What do we need to send to
> the inferior to reach that crash?

I've attached a script that when run should reproduce the issue. I
extracted the code relating to lint warnings from the Guix Data
Service. The script attached runs this code twice against the inferior,
once will often be enough to cause it to crash, but twice should
reproduce it more reliably.

Attachment: inferior-crash.scm

Ludovic Courtès wrote on 11 Apr 2020 15:24

control message for bug #40525

Recipients:(address . control@debbugs.gnu.org)

Message-ID:874ktqtatm.fsf@gnu.org

severity 40525 serious

quit

Ludovic Courtès wrote on 11 Apr 2020 16:03

Re: bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 40525@debbugs.gnu.org)

Message-ID:87h7xqrug3.fsf@gnu.org

Hi Christopher,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (6 lines)

> I've attached a script that when run should reproduce the issue. I

> extracted the code relating to lint warnings from the Guix Data

> Service. The script attached runs this code twice against the inferior,

> once will often be enough to cause it to crash, but twice should

> reproduce it more reliably.

Thanks a lot.

Here’s a backtrace from the core dumped by the inferior:

Toggle snippet (136 lines)$ gdb /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile core
GNU gdb (GDB) 9.1

[...]

(gdb) bt
#0  0x00007fc5d8145aba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#1  0x00007fc5d8146bf5 in abort () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#2  0x00007fc5d86d94ee in GC_unmap () from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#3  0x00007fc5d86d95d1 in GC_unmap_old.part.30 ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#4  0x00007fc5d86e0882 in GC_finish_collection ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#5  0x00007fc5d86e0cf5 in GC_try_to_collect_inner ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#6  0x00007fc5d86e1138 in GC_collect_or_expand ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#7  0x00007fc5d86e1517 in GC_alloc_large ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#8  0x00007fc5d86e545a in GC_generic_malloc ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#9  0x00007fc5d86e56a2 in GC_malloc_kind_global ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#10 0x00007fc5d8805ce5 in resize_table (table=table@entry=0x7fc5d6318cb0) at weak-table.c:251
#11 0x00007fc5d8806638 in weak_table_put_x (value=#<unmatched-tag c77>, 
    key="mirror://cpan/authors/id/M/MI/MIYAGAWA/", closure=0x7fc5434535c0, pred=0x7fc5d8805bb0 <assq_predicate>, 
    hash=4466916161623136036, table=0x7fc5d6318cb0) at weak-table.c:377
#12 scm_c_weak_table_put_x (table=<optimized out>, raw_hash=4466916161623136036, 
    pred=0x7fc5d8805bb0 <assq_predicate>, closure=0x7fc5434535c0, key="mirror://cpan/authors/id/M/MI/MIYAGAWA/", 
    value=#<unmatched-tag c77>) at weak-table.c:559
#13 0x00007fc5d87d6007 in maybe_annotate_source (column=27, line=3340, opts=0x7fff347b9708, 
    port=#<port 3 7fc543ad90a0>, x="mirror://cpan/authors/id/M/MI/MIYAGAWA/") at read.c:693
#14 scm_read_string_like_syntax (chr=chr@entry=34, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:726
#15 0x00007fc5d87d6720 in scm_read_string (opts=0x7fff347b9708, port=#<port 3 7fc543ad90a0>, chr=34) at read.c:733
#16 read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1822
#17 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#18 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:481
#19 0x00007fc5d87d6820 in read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1820
#20 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#21 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:481
#22 0x00007fc5d87d6820 in read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1820
#23 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#24 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:481
#25 0x00007fc5d87d6820 in read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1820
#26 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#27 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:481
#28 0x00007fc5d87d6820 in read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1820
#29 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#30 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:481
#31 0x00007fc5d87d6820 in read_inner_expression (port=#<port 3 7fc543ad90a0>, opts=0x7fff347b9708) at read.c:1820
#32 0x00007fc5d87d7925 in scm_read_expression (port=port@entry=#<port 3 7fc543ad90a0>, 
    opts=opts@entry=0x7fff347b9708) at read.c:1880
#33 0x00007fc5d87d8197 in scm_read (port=#<port 3 7fc543ad90a0>) at read.c:1969
#34 0x00007fc5c0d5598b in ?? ()
#35 0x00007fc5d80bed80 in ?? ()
#36 0x00007fc5d886e5c0 in ?? () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
#37 0x00007fc5d80bed80 in ?? ()
#38 0x00007fc5d87a7f0b in scm_jit_enter_mcode (thread=0x7fc5d80bed80, 
    mcode=0x7fc5c964daf0 "H\203\350\020I\211\314I)\304I\203\374(\017\205\261") at jit.c:5777
#39 0x00007fc5d88034c9 in vm_regular_engine (thread=0x10) at vm-engine.c:360
#40 0x00007fc5d8804175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7fff347b9900, nargs=nargs@entry=2)
    at vm.c:1608
#41 0x00007fc5d878109a in scm_call_2 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
    at eval.c:503
#42 0x00007fc5d87954fe in map_proc (proc=<optimized out>, key=<optimized out>, data=<optimized out>, 
    value=((140487468690240) (140487526526240) (140487485623904) (140487467244992) (140487524472384) (140487487009568) (140487524865600) (140487524471904) (140487524657184) (140487489846880) (140487468425216) (140487466477120) (140487486996640) …)
#43 0x00007fc5d87965d2 in scm_internal_hash_fold (fn=0x7fc5d87954f0 <map_proc>, closure=0x7fc53e3e8620, 
    init=<optimized out>, table=<optimized out>) at hashtab.c:1029
#44 0x00007fc5d2e2c206 in ?? ()
#45 0x00007fc5d80bed80 in ?? ()
#46 0x00007fc5d886e5c0 in ?? () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
#47 0x00007fc5d80bed80 in ?? ()
#48 0x00007fc5d87a7f0b in scm_jit_enter_mcode (thread=0x7fc5d80bed80, 
    mcode=0x7fc5c0e813c1 "I\211\314I)\304I\203\374@\017\214\002\002") at jit.c:5777
#49 0x00007fc5d8803350 in vm_regular_engine (thread=0x7fc5d2e2c1e0) at vm-engine.c:546
#50 0x00007fc5d8804175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7fff347b9b48, nargs=nargs@entry=1)
    at vm.c:1608
#51 0x00007fc5d8782207 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
#52 0x00007fc5d87a9bcb in scm_primitive_load (filename=<optimized out>) at load.c:131
#53 0x00007fc5d8802d2c in vm_regular_engine (thread=0x7fc5d80bed80) at vm-engine.c:972
#54 0x00007fc5d8804175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7fff347b9d18, nargs=nargs@entry=1)
    at vm.c:1608
#55 0x00007fc5d8782207 in scm_primitive_eval (exp=<optimized out>, 
    exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "/home/ludo/.cache/guix/inferiors/x5fhyqwm6qwd445ftlnwxlcot77xbxxstysjbvnvyzuo6kp3jwpq/bin/guix") (quit)))) at eval.c:671
#56 0x00007fc5d8782263 in scm_eval (
    exp=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "/home/ludo/.cache/guix/inferiors/x5fhyqwm6qwd445ftlnwxlcot77xbxxstysjbvnvyzuo6kp3jwpq/bin/guix") (quit))), 
    module_or_state=module_or_state@entry=#<invalid-struct 7fc5d5fb5f00>) at eval.c:705
#57 0x00007fc5d87da070 in scm_shell (argc=6, argv=0x7fff347ba388) at script.c:357
#58 0x00007fc5d8799c0d in invoke_main_func (body_data=0x7fff347ba220) at init.c:308
#59 0x00007fc5d877ce5a in c_body (d=0x7fff347ba160) at continuations.c:430
#60 0x00007fc5d8802d2c in vm_regular_engine (thread=0x7fc5d80bed80) at vm-engine.c:972
#61 0x00007fc5d8804175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7fff347b9f20, nargs=nargs@entry=2)
    at vm.c:1608
#62 0x00007fc5d878109a in scm_call_2 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
    at eval.c:503
#63 0x00007fc5d878289a in scm_c_with_exception_handler (type=type@entry=#t, 
    handler=handler@entry=0x7fc5d87f9560 <catch_post_unwind_handler>, 
    handler_data=handler_data@entry=0x7fff347ba090, thunk=thunk@entry=0x7fc5d87f96a0 <catch_body>, 
    thunk_data=thunk_data@entry=0x7fff347ba090) at exceptions.c:170
#64 0x00007fc5d87f989d in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7fc5d877ce50 <c_body>, 
    body_data=body_data@entry=0x7fff347ba160, handler=handler@entry=0x7fc5d877d0f0 <c_handler>, 
    handler_data=handler_data@entry=0x7fff347ba160, 
    pre_unwind_handler=pre_unwind_handler@entry=0x7fc5d877cf50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7fc5d6385360) at throw.c:168
#65 0x00007fc5d877d403 in scm_i_with_continuation_barrier (body=body@entry=0x7fc5d877ce50 <c_body>, 
    body_data=body_data@entry=0x7fff347ba160, handler=handler@entry=0x7fc5d877d0f0 <c_handler>, 
    handler_data=handler_data@entry=0x7fff347ba160, 
    pre_unwind_handler=pre_unwind_handler@entry=0x7fc5d877cf50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7fc5d6385360) at continuations.c:368
#66 0x00007fc5d877d495 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>)
    at continuations.c:464
#67 0x00007fc5d87f833f in with_guile (base=0x7fff347ba1c8, data=0x7fff347ba1f0) at threads.c:645
#68 0x00007fc5d86d7c78 in GC_call_with_stack_base ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#69 0x00007fc5d87f8658 in scm_i_with_guile (dynamic_state=<optimized out>, data=data@entry=0x7fff347ba1f0, 
    func=func@entry=0x7fc5d8799bf0 <invoke_main_func>) at threads.c:688
#70 scm_with_guile (func=func@entry=0x7fc5d8799bf0 <invoke_main_func>, data=data@entry=0x7fff347ba220)
    at threads.c:694
#71 0x00007fc5d8799d82 in scm_boot_guile (argc=argc@entry=6, argv=argv@entry=0x7fff347ba388, 
    main_func=main_func@entry=0x401240 <inner_main>, closure=closure@entry=0x0) at init.c:291
#72 0x0000000000401100 in main (argc=6, argv=0x7fff347ba388) at guile.c:95
(gdb) shell du -h core
1.4G	core

Two clues: the heap is very large, and the backtrace shows it crashes as

we populate ‘scm_source_whash’, the source property weak hash table.

The size of the table looks reasonable though:

Toggle snippet (15 lines)(gdb) frame 12
#12 scm_c_weak_table_put_x (table=<optimized out>, raw_hash=4466916161623136036, 
    pred=0x7fc5d8805bb0 <assq_predicate>, closure=0x7fc5434535c0, key="mirror://cpan/authors/id/M/MI/MIYAGAWA/", 
    value=#<unmatched-tag c77>) at weak-table.c:559
559	weak-table.c: Dosiero a? dosierujo ne ekzistas.
(gdb) info locals
t = 0x7fc5d6318cb0
(gdb) p *t
$1 = {buckets = 0x7fc59f0d5000, lock = {__data = {__lock = 1, __count = 0, __owner = 29145, __nusers = 1, 
      __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, 
    __size = "\001\000\000\000\000\000\000\000\331q\000\000\001", '\000' <repeats 26 times>, __align = 1}, 
  kind = SCM_WEAK_TABLE_KIND_KEY, n_buckets = 14051, n_items = 12646, lower = 3512, upper = 12645, 
  size_index = 9, min_size_index = 0, last_gc_no = 139}

It’s probably the ‘formatting’ checker that causes source files to be

read, as show in the backtrace.

In your reproducer, I changed:

if network-dependent?

to:

if (or network-dependent? (eq? name 'formatting))

but it eventually crashes as well, with a slightly different backtrace:

Toggle snippet (88 lines)(gdb) bt
#0  0x00007ffaed0e6aba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#1  0x00007ffaed0e7bf5 in abort () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#2  0x00007ffaed67a4ee in GC_unmap () from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#3  0x00007ffaed67a5d1 in GC_unmap_old.part.30 ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#4  0x00007ffaed681882 in GC_finish_collection ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#5  0x00007ffaed681cf5 in GC_try_to_collect_inner ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#6  0x00007ffaed685570 in GC_grow_table ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#7  0x00007ffaed685c8a in GC_register_finalizer_inner ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#8  0x00007ffaed72c1c1 in scm_i_set_finalizer (obj=obj@entry=0x7ffaaf032d00, 
    proc=proc@entry=0x7ffaed77b580 <finalize_smob>, data=data@entry=0x0) at finalizers.c:59
#9  0x00007ffaed77b985 in scm_i_new_smob (tc=2935, data=140715203757120) at smob.c:440
#10 0x00007ffad5e1fae4 in ?? ()
#11 0x00007ffaed05fd80 in ?? ()
#12 0x00007ffaed80f5c0 in ?? () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
#13 0x00007ffaed05fd80 in ?? ()
#14 0x00007ffaed748f0b in scm_jit_enter_mcode (thread=0x7ffaed05fd80, 
    mcode=0x7ffada5eaaf0 "H\203\350\020I\211\314I)\304I\203\374(\017\205\261") at jit.c:5777
#15 0x00007ffaed7a44c9 in vm_regular_engine (thread=0x304) at vm-engine.c:360
#16 0x00007ffaed7a5175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7ffe9ad99640, nargs=nargs@entry=2)
    at vm.c:1608
#17 0x00007ffaed72209a in scm_call_2 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
    at eval.c:503
#18 0x00007ffaed7364fe in map_proc (proc=<optimized out>, key=<optimized out>, data=<optimized out>, 
    value=((140715403607328) (140715509812992) (140715405240352) (140715407862272) (140715403697600) (140715511169504) (140715385141440) …)
    at hashtab.c:953
#19 0x00007ffaed7375d2 in scm_internal_hash_fold (fn=0x7ffaed7364f0 <map_proc>, closure=0x7ffa5353fee0, 
    init=<optimized out>, table=<optimized out>) at hashtab.c:1029
#20 0x00007ffae7dcd206 in ?? ()
#21 0x00007ffaed05fd80 in ?? ()
#22 0x00007ffaed80f5c0 in ?? () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
#23 0x00007ffaed05fd80 in ?? ()
#24 0x00007ffaed748f0b in scm_jit_enter_mcode (thread=0x7ffaed05fd80, 
    mcode=0x7ffad5e1e3c1 "I\211\314I)\304I\203\374@\017\214\002\002") at jit.c:5777
#25 0x00007ffaed7a4350 in vm_regular_engine (thread=0x7ffae7dcd1e0) at vm-engine.c:546
#26 0x00007ffaed7a5175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7ffe9ad99888, nargs=nargs@entry=1)
    at vm.c:1608
#27 0x00007ffaed723207 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
#28 0x00007ffaed74abcb in scm_primitive_load (filename=<optimized out>) at load.c:131
#29 0x00007ffaed7a3d2c in vm_regular_engine (thread=0x7ffaed05fd80) at vm-engine.c:972
#30 0x00007ffaed7a5175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7ffe9ad99a58, nargs=nargs@entry=1)
    at vm.c:1608
#31 0x00007ffaed723207 in scm_primitive_eval (exp=<optimized out>, 
    exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "/home/ludo/.cache/guix/inferiors/x5fhyqwm6qwd445ftlnwxlcot77xbxxstysjbvnvyzuo6kp3jwpq/bin/guix") (quit)))) at eval.c:671
#32 0x00007ffaed723263 in scm_eval (
    exp=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "/home/ludo/.cache/guix/inferiors/x5fhyqwm6qwd445ftlnwxlcot77xbxxstysjbvnvyzuo6kp3jwpq/bin/guix") (quit))), 
    module_or_state=module_or_state@entry=#<invalid-struct 7ffaeaf56f00>) at eval.c:705
#33 0x00007ffaed77b070 in scm_shell (argc=6, argv=0x7ffe9ad9a0c8) at script.c:357
#34 0x00007ffaed73ac0d in invoke_main_func (body_data=0x7ffe9ad99f60) at init.c:308
#35 0x00007ffaed71de5a in c_body (d=0x7ffe9ad99ea0) at continuations.c:430
#36 0x00007ffaed7a3d2c in vm_regular_engine (thread=0x7ffaed05fd80) at vm-engine.c:972
#37 0x00007ffaed7a5175 in scm_call_n (proc=<optimized out>, argv=argv@entry=0x7ffe9ad99c60, nargs=nargs@entry=2)
    at vm.c:1608
#38 0x00007ffaed72209a in scm_call_2 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
    at eval.c:503
#39 0x00007ffaed72389a in scm_c_with_exception_handler (type=type@entry=#t, 
    handler=handler@entry=0x7ffaed79a560 <catch_post_unwind_handler>, 
    handler_data=handler_data@entry=0x7ffe9ad99dd0, thunk=thunk@entry=0x7ffaed79a6a0 <catch_body>, 
    thunk_data=thunk_data@entry=0x7ffe9ad99dd0) at exceptions.c:170
#40 0x00007ffaed79a89d in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7ffaed71de50 <c_body>, 
    body_data=body_data@entry=0x7ffe9ad99ea0, handler=handler@entry=0x7ffaed71e0f0 <c_handler>, 
    handler_data=handler_data@entry=0x7ffe9ad99ea0, 
    pre_unwind_handler=pre_unwind_handler@entry=0x7ffaed71df50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7ffaeb326360) at throw.c:168
#41 0x00007ffaed71e403 in scm_i_with_continuation_barrier (body=body@entry=0x7ffaed71de50 <c_body>, 
    body_data=body_data@entry=0x7ffe9ad99ea0, handler=handler@entry=0x7ffaed71e0f0 <c_handler>, 
    handler_data=handler_data@entry=0x7ffe9ad99ea0, 
    pre_unwind_handler=pre_unwind_handler@entry=0x7ffaed71df50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7ffaeb326360) at continuations.c:368
#42 0x00007ffaed71e495 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>)
    at continuations.c:464
#43 0x00007ffaed79933f in with_guile (base=0x7ffe9ad99f08, data=0x7ffe9ad99f30) at threads.c:645
#44 0x00007ffaed678c78 in GC_call_with_stack_base ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#45 0x00007ffaed799658 in scm_i_with_guile (dynamic_state=<optimized out>, data=data@entry=0x7ffe9ad99f30, 
    func=func@entry=0x7ffaed73abf0 <invoke_main_func>) at threads.c:688
#46 scm_with_guile (func=func@entry=0x7ffaed73abf0 <invoke_main_func>, data=data@entry=0x7ffe9ad99f60)
    at threads.c:694
#47 0x00007ffaed73ad82 in scm_boot_guile (argc=argc@entry=6, argv=argv@entry=0x7ffe9ad9a0c8, 
    main_func=main_func@entry=0x401240 <inner_main>, closure=closure@entry=0x0) at init.c:291
#48 0x0000000000401100 in main (argc=6, argv=0x7ffe9ad9a0c8) at guile.c:95

It could be an unbounded growth of libgc’s finalizer table or our weak

tables as we experienced in https://bugs.gnu.org/28590.

We should be able to reproduce it with something like:

guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \

lint -c inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis

In top one can see that heap usage keeps growing, which may well be a

bug in Guix proper rather than in Guile… but it doesn’t crash.

I would propose three actions here:

1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully

find and address the leak. As a start, maybe just start reducing

the list of checkers to see if there’s one of them that’s causing

it.

The ‘derivation’ checker is definitely responsible for a lot of the

heap consumption because of the various caches in (guix packages) &

co. Perhaps add calls to ‘invalidate-derivation-caches!’ as in

(gnu ci).

2. Work around the problem in Guix Data Service by running, say, one

inferior per checker instead of one inferior for all che

This message was truncated. Download the full message here.

Christopher Baines wrote on 16 Apr 2020 19:29

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40525@debbugs.gnu.org)

Message-ID:87pnc75ofc.fsf@cbaines.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (14 lines)> Hi Christopher,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> I've attached a script that when run should reproduce the issue. I
>> extracted the code relating to lint warnings from the Guix Data
>> Service. The script attached runs this code twice against the inferior,
>> once will often be enough to cause it to crash, but twice should
>> reproduce it more reliably.
>
> Thanks a lot.
>
> Here’s a backtrace from the core dumped by the inferior:

...

Toggle quote (32 lines)> It could be an unbounded growth of libgc’s finalizer table or our weak
> tables as we experienced in <https://bugs.gnu.org/28590>.
>
> We should be able to reproduce it with something like:
>
>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
>     lint -c inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>
> In top one can see that heap usage keeps growing, which may well be a
> bug in Guix proper rather than in Guile… but it doesn’t crash.
>
> I would propose three actions here:
>
>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>      find and address the leak.  As a start, maybe just start reducing
>      the list of checkers to see if there’s one of them that’s causing
>      it.
>
>      The ‘derivation’ checker is definitely responsible for a lot of the
>      heap consumption because of the various caches in (guix packages) &
>      co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>      (gnu ci).
>
>   2. Work around the problem in Guix Data Service by running, say, one
>      inferior per checker instead of one inferior for all checkers for
>      all packages.
>
>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>      bug or something like that.
>
> Thoughts?

Thanks, that's useful to know.

I think I've now managed to find a way of reproducing this without the

inferior getting in the way. I was testing if triggering garbage

collection in Guile would help avoid the problem, but actually it seems

to cause it. I guess given the mentions of GC in the above stacktrace,

and the major version change of libgc, some GC related bug seems quite

likely here.

I've been testing with a checkout of Guix built with Guix from the

core-updates branch. I think that provides the same broken Guile that

the guix repl is using.

When trying to just use a checkout of the core-updates branch, and guile

built from that branch I get the following odd error:

→ ./pre-inst-env /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm

guile: warning: failed to install locale

warning: failed to load '(gnu packages abiword)': Function not implemented

error: git-fetch: unbound variable

hint: Did you forget `(use-modules (guix git-download))'?

error: git-version: unbound variable

No idea what's happening there, but when I ./configure and make with

packages from core-updates, I seem to end up with a setup that works:

This is the guile I'm using: /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile

If you just run the script, you should see:

→ ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm

;;; ("%package-table-setup" #<hash-table 7f5f329278a0 13275/28099>)

mmap(PROT_NONE) failed

Aborted

For more information, you can pipe the script to the REPL. What you

should see is that it's slow to compute the lint warnings the first

time, but the subsequent times are quick, and it crashes in one of the

(gc) calls.

I'm going to try and continue looking in to this, at least it'll be

easier to delve in to guile now that I can directly control what guile

is used.

Thanks,

Chris

(use-modules (srfi srfi-1) (ice-9 match) (gnu packages) (guix store) (guix grafts) (guix packages) (guix lint) (guix utils)) (define %package-table (make-hash-table)) (begin (fold-packages (lambda (package result) (let ((id (object-address package))) (hashv-set! %package-table id package) (cons (list (package-name package) (package-version package) id) result))) '()) (peek "%package-table-setup" %package-table)) (define lint-warnings-for-checker (lambda (checker-name store) (let* ((checker (find (lambda (checker) (eq? (lint-checker-name checker) checker-name)) %local-checkers)) (check (lint-checker-check checker))) (define (process-lint-warning lint-warning) (list (match (lint-warning-location lint-warning) (($ <location> file line column) (list (if (string-prefix? "/gnu/store/" file) (string-join (drop (string-split file #\/) 8) "/") file) line column))) (let* ((source-locale "en_US.utf8") (source-message (begin (setlocale LC_MESSAGES source-locale) (lint-warning-message lint-warning))) (messages-by-locale (filter-map (lambda (locale) (catch 'system-error (lambda () (setlocale LC_MESSAGES locale)) (lambda (key . args) (error (simple-format #f "error changing locale to ~A: ~A ~A" locale key args)))) (let ((message (lint-warning-message lint-warning))) (setlocale LC_MESSAGES source-locale) (if (string=? message source-message) #f (cons locale message)))) '("cs_CZ.utf8" "da_DK.utf8" "de_DE.utf8" "eo_EO.utf8" "es_ES.utf8" "fr_FR.utf8" "hu_HU.utf8" "pl_PL.utf8" "pt_BR.utf8" ;;"sr_SR.utf8" "sv_SE.utf8" "vi_VN.utf8" "zh_CN.utf8")))) (cons (cons source-locale source-message) messages-by-locale)))) (filter (match-lambda ((package-id . warnings) (not (null? warnings)))) (hash-map->list (lambda (package-id package) (cons package-id (catch #t (lambda () (map process-lint-warning (check package #:store store))) (lambda (key . args) '())))) %package-table))))) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (gc) (with-store store (lint-warnings-for-checker 'derivation store)) (simple-format #t "finished successfully\n\n")

Christopher Baines wrote on 16 Apr 2020 21:24

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40525@debbugs.gnu.org)

Message-ID:87mu7b5j4w.fsf@cbaines.net

Christopher Baines <mail@cbaines.net> writes:

Toggle quote (99 lines)> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Christopher,
>>
>> Christopher Baines <mail@cbaines.net> skribis:
>>
>>> I've attached a script that when run should reproduce the issue. I
>>> extracted the code relating to lint warnings from the Guix Data
>>> Service. The script attached runs this code twice against the inferior,
>>> once will often be enough to cause it to crash, but twice should
>>> reproduce it more reliably.
>>
>> Thanks a lot.
>>
>> Here’s a backtrace from the core dumped by the inferior:
>
> ...
>
>> It could be an unbounded growth of libgc’s finalizer table or our weak
>> tables as we experienced in <https://bugs.gnu.org/28590>.
>>
>> We should be able to reproduce it with something like:
>>
>>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
>>     lint -c inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>>
>> In top one can see that heap usage keeps growing, which may well be a
>> bug in Guix proper rather than in Guile… but it doesn’t crash.
>>
>> I would propose three actions here:
>>
>>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>>      find and address the leak.  As a start, maybe just start reducing
>>      the list of checkers to see if there’s one of them that’s causing
>>      it.
>>
>>      The ‘derivation’ checker is definitely responsible for a lot of the
>>      heap consumption because of the various caches in (guix packages) &
>>      co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>>      (gnu ci).
>>
>>   2. Work around the problem in Guix Data Service by running, say, one
>>      inferior per checker instead of one inferior for all checkers for
>>      all packages.
>>
>>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>>      bug or something like that.
>>
>> Thoughts?
>
> Thanks, that's useful to know.
>
> I think I've now managed to find a way of reproducing this without the
> inferior getting in the way. I was testing if triggering garbage
> collection in Guile would help avoid the problem, but actually it seems
> to cause it. I guess given the mentions of GC in the above stacktrace,
> and the major version change of libgc, some GC related bug seems quite
> likely here.
>
> I've been testing with a checkout of Guix built with Guix from the
> core-updates branch. I think that provides the same broken Guile that
> the guix repl is using.
>
> When trying to just use a checkout of the core-updates branch, and guile
> built from that branch I get the following odd error:
>
> → ./pre-inst-env /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
> guile: warning: failed to install locale
> warning: failed to load '(gnu packages abiword)': Function not implemented
> error: git-fetch: unbound variable
> hint: Did you forget `(use-modules (guix git-download))'?
>
> error: git-version: unbound variable
>
>
>
> No idea what's happening there, but when I ./configure and make with
> packages from core-updates, I seem to end up with a setup that works:
>
> This is the guile I'm using: /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
>
> If you just run the script, you should see:
>
> → ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
>
> ;;; ("%package-table-setup" #<hash-table 7f5f329278a0 13275/28099>)
> mmap(PROT_NONE) failed
> Aborted
>
>
> For more information, you can pipe the script to the REPL. What you
> should see is that it's slow to compute the lint warnings the first
> time, but the subsequent times are quick, and it crashes in one of the
> (gc) calls.
>
> I'm going to try and continue looking in to this, at least it'll be
> easier to delve in to guile now that I can directly control what guile
> is used.

Following up on this, I've built Guile on core-updates with libgc@7
rather than libgc@8 (which is what's used above), and I can't reproduce
the issue. So, I'm getting more certain that this is a regression which
the libgc upgrade has led to.

Would it be feasible to keep guile, or at least the guile Guix uses with
libgc@7 for now?

Ludovic Courtès wrote on 17 Apr 2020 11:02

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 40525@debbugs.gnu.org)

Message-ID:87h7xibi3n.fsf@gnu.org

Hi,

Glad you manage to get more info.

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (5 lines)

> Following up on this, I've built Guile on core-updates with libgc@7

> rather than libgc@8 (which is what's used above), and I can't reproduce

> the issue. So, I'm getting more certain that this is a regression which

> the libgc upgrade has led to.

Bah. :-/

We noticed similar issues with libgc@8 earlier but it seemed to be

fixed:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812

Toggle quote (3 lines)

> Would it be feasible to keep guile, or at least the guile Guix uses with

> libgc@7 for now?

Yes, we can define a Guile variant in (gnu packages guile) and have

(guix self) refer to it.

Thanks,

Ludo’.

Christopher Baines wrote on 17 Apr 2020 19:34

Recipients:(address . 40525@debbugs.gnu.org)

Message-ID:87lfmu583k.fsf@cbaines.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (22 lines)> Glad you manage to get more info.
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc@7
>> rather than libgc@8 (which is what's used above), and I can't reproduce
>> the issue. So, I'm getting more certain that this is a regression which
>> the libgc upgrade has led to.
>
> Bah.  :-/
>
> We noticed similar issues with libgc@8 earlier but it seemed to be
> fixed:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>
>> Would it be feasible to keep guile, or at least the guile Guix uses with
>> libgc@7 for now?
>
> Yes, we can define a Guile variant in (gnu packages guile) and have
> (guix self) refer to it.

I've sent a patch which I think does this now [1]. Assuming I've done

the right thing, is this something that can be merged in to core-updates

Marius?

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684

I've tested the patch by running:

./pre-inst-env guile build-aux/compile-as-derivation.scm "$PWD"

Then taking the Guix I get, and trying the script to reproduce the issue

through the guix repl, and it seems to work.

Christopher Baines wrote on 18 Apr 2020 18:53

Recipients:(address . 40525-done@debbugs.gnu.org)

Message-ID:877dyc68hu.fsf@cbaines.net

Christopher Baines <mail@cbaines.net> writes:

Toggle quote (37 lines)> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Glad you manage to get more info.
>>
>> Christopher Baines <mail@cbaines.net> skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's used above), and I can't reproduce
>>> the issue. So, I'm getting more certain that this is a regression which
>>> the libgc upgrade has led to.
>>
>> Bah.  :-/
>>
>> We noticed similar issues with libgc@8 earlier but it seemed to be
>> fixed:
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>>
>>> Would it be feasible to keep guile, or at least the guile Guix uses with
>>> libgc@7 for now?
>>
>> Yes, we can define a Guile variant in (gnu packages guile) and have
>> (guix self) refer to it.
>
> I've sent a patch which I think does this now [1]. Assuming I've done
> the right thing, is this something that can be merged in to core-updates
> Marius?
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684
>
> I've tested the patch by running:
>
>   ./pre-inst-env guile build-aux/compile-as-derivation.scm "$PWD"
>
> Then taking the Guix I get, and trying the script to reproduce the issue
> through the guix repl, and it seems to work.

I've merged the fix [1] in now, and it looks to have worked [2].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684

2: https://guix-patches-data.cbaines.net/revision/cef392f3936922b7b0b74bd59be67e660c10db67

Thanks for your help in resolving this Ludo!

Closed

Ludovic Courtès wrote on 7 May 2021 11:17

control message for bug #40525

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87v97uc38e.fsf@gnu.org

unarchive 40525

quit

Ludovic Courtès wrote on 8 May 2021 11:56

Re: bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 40525@debbugs.gnu.org)

Message-ID:87czu1a6rw.fsf@gnu.org

Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (20 lines)> Christopher Baines <mail@cbaines.net> skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc@7
>> rather than libgc@8 (which is what's used above), and I can't reproduce
>> the issue. So, I'm getting more certain that this is a regression which
>> the libgc upgrade has led to.
>
> Bah.  :-/
>
> We noticed similar issues with libgc@8 earlier but it seemed to be
> fixed:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>
>> Would it be feasible to keep guile, or at least the guile Guix uses with
>> libgc@7 for now?
>
> Yes, we can define a Guile variant in (gnu packages guile) and have
> (guix self) refer to it.

FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash

upstream and gathered more info:

https://github.com/ivmai/bdwgc/issues/353

On #guile they also mentioned that libgc 8 defaults to

‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’.

Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487,

I changed libgc 8 so it’s built with ‘--disable-munmap’. This relieves

the need for ‘guile-3.0/libgc-7’. (I checked with “make as-derivation”

on x86_64-linux that those derivations that would previously fail with

libgc 8 no longer do.)

Ludo’.

Christopher Baines wrote on 8 May 2021 21:58

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40525@debbugs.gnu.org)

Message-ID:87a6p52e17.fsf@cbaines.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (38 lines)> Hi,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Christopher Baines <mail@cbaines.net> skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's used above), and I can't reproduce
>>> the issue. So, I'm getting more certain that this is a regression which
>>> the libgc upgrade has led to.
>>
>> Bah.  :-/
>>
>> We noticed similar issues with libgc@8 earlier but it seemed to be
>> fixed:
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>>
>>> Would it be feasible to keep guile, or at least the guile Guix uses with
>>> libgc@7 for now?
>>
>> Yes, we can define a Guile variant in (gnu packages guile) and have
>> (guix self) refer to it.
>
> FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash
> upstream and gathered more info:
>
>   https://github.com/ivmai/bdwgc/issues/353
>
> On #guile they also mentioned that libgc 8 defaults to
> ‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’.
>
> Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487,
> I changed libgc 8 so it’s built with ‘--disable-munmap’.  This relieves
> the need for ‘guile-3.0/libgc-7’.  (I checked with “make as-derivation”
> on x86_64-linux that those derivations that would previously fail with
> libgc 8 no longer do.)

Great, that sounds good :)

Your comment

This issue is archived.

To comment on this conversation send an email to 40525@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date