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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40525 in the body.
You can then email your comments to 40525 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: inferior process on core-updates crashes: mmap(PROT_NONE) failed
Date: Thu, 09 Apr 2020 20:45:15 +0100

[Message part 1 (text/plain, inline)]

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

[guix-inferior-strace (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Fri, 10 Apr 2020 11:41:02 +0200

Hi,

Christopher Baines <mail <at> 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?

Thanks,
Ludo’.

Message #11 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Fri, 10 Apr 2020 12:55:11 +0100

[Message part 1 (text/plain, inline)]

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

> Hi,
>
> Christopher Baines <mail <at> 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.

[inferior-crash.scm (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Sat, 11 Apr 2020 16:03:08 +0200

Hi Christopher,

Christopher Baines <mail <at> 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:

--8<---------------cut here---------------start------------->8---
$ 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 <at> 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 <at> entry=34, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> entry=0x7fff347b9708) at read.c:1880
#18 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr <at> entry=40, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> entry=0x7fff347b9708) at read.c:1880
#21 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr <at> entry=40, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> entry=0x7fff347b9708) at read.c:1880
#24 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr <at> entry=40, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> entry=0x7fff347b9708) at read.c:1880
#27 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr <at> entry=40, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> entry=0x7fff347b9708) at read.c:1880
#30 0x00007fc5d87d7c16 in scm_read_sexp (chr=chr <at> entry=40, port=port <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=#<port 3 7fc543ad90a0>, 
    opts=opts <at> 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 <at> entry=0x7fff347b9900, nargs=nargs <at> 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 <at> entry=0x7fff347b9b48, nargs=nargs <at> 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 <at> entry=0x7fff347b9d18, nargs=nargs <at> entry=1)
    at vm.c:1608
#55 0x00007fc5d8782207 in scm_primitive_eval (exp=<optimized out>, 
    exp <at> 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 <at> 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 <at> entry=0x7fff347b9f20, nargs=nargs <at> 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 <at> entry=#t, 
    handler=handler <at> entry=0x7fc5d87f9560 <catch_post_unwind_handler>, 
    handler_data=handler_data <at> entry=0x7fff347ba090, thunk=thunk <at> entry=0x7fc5d87f96a0 <catch_body>, 
    thunk_data=thunk_data <at> entry=0x7fff347ba090) at exceptions.c:170
#64 0x00007fc5d87f989d in scm_c_catch (tag=tag <at> entry=#t, body=body <at> entry=0x7fc5d877ce50 <c_body>, 
    body_data=body_data <at> entry=0x7fff347ba160, handler=handler <at> entry=0x7fc5d877d0f0 <c_handler>, 
    handler_data=handler_data <at> entry=0x7fff347ba160, 
    pre_unwind_handler=pre_unwind_handler <at> entry=0x7fc5d877cf50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7fc5d6385360) at throw.c:168
#65 0x00007fc5d877d403 in scm_i_with_continuation_barrier (body=body <at> entry=0x7fc5d877ce50 <c_body>, 
    body_data=body_data <at> entry=0x7fff347ba160, handler=handler <at> entry=0x7fc5d877d0f0 <c_handler>, 
    handler_data=handler_data <at> entry=0x7fff347ba160, 
    pre_unwind_handler=pre_unwind_handler <at> 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 <at> entry=0x7fff347ba1f0, 
    func=func <at> entry=0x7fc5d8799bf0 <invoke_main_func>) at threads.c:688
#70 scm_with_guile (func=func <at> entry=0x7fc5d8799bf0 <invoke_main_func>, data=data <at> entry=0x7fff347ba220)
    at threads.c:694
#71 0x00007fc5d8799d82 in scm_boot_guile (argc=argc <at> entry=6, argv=argv <at> entry=0x7fff347ba388, 
    main_func=main_func <at> entry=0x401240 <inner_main>, closure=closure <at> 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
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
(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}
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
(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 <at> entry=0x7ffaaf032d00, 
    proc=proc <at> entry=0x7ffaed77b580 <finalize_smob>, data=data <at> 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 <at> entry=0x7ffe9ad99640, nargs=nargs <at> 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 <at> entry=0x7ffe9ad99888, nargs=nargs <at> 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 <at> entry=0x7ffe9ad99a58, nargs=nargs <at> entry=1)
    at vm.c:1608
#31 0x00007ffaed723207 in scm_primitive_eval (exp=<optimized out>, 
    exp <at> 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 <at> 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 <at> entry=0x7ffe9ad99c60, nargs=nargs <at> 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 <at> entry=#t, 
    handler=handler <at> entry=0x7ffaed79a560 <catch_post_unwind_handler>, 
    handler_data=handler_data <at> entry=0x7ffe9ad99dd0, thunk=thunk <at> entry=0x7ffaed79a6a0 <catch_body>, 
    thunk_data=thunk_data <at> entry=0x7ffe9ad99dd0) at exceptions.c:170
#40 0x00007ffaed79a89d in scm_c_catch (tag=tag <at> entry=#t, body=body <at> entry=0x7ffaed71de50 <c_body>, 
    body_data=body_data <at> entry=0x7ffe9ad99ea0, handler=handler <at> entry=0x7ffaed71e0f0 <c_handler>, 
    handler_data=handler_data <at> entry=0x7ffe9ad99ea0, 
    pre_unwind_handler=pre_unwind_handler <at> entry=0x7ffaed71df50 <pre_unwind_handler>, 
    pre_unwind_handler_data=0x7ffaeb326360) at throw.c:168
#41 0x00007ffaed71e403 in scm_i_with_continuation_barrier (body=body <at> entry=0x7ffaed71de50 <c_body>, 
    body_data=body_data <at> entry=0x7ffe9ad99ea0, handler=handler <at> entry=0x7ffaed71e0f0 <c_handler>, 
    handler_data=handler_data <at> entry=0x7ffe9ad99ea0, 
    pre_unwind_handler=pre_unwind_handler <at> 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 <at> entry=0x7ffe9ad99f30, 
    func=func <at> entry=0x7ffaed73abf0 <invoke_main_func>) at threads.c:688
#46 scm_with_guile (func=func <at> entry=0x7ffaed73abf0 <invoke_main_func>, data=data <at> entry=0x7ffe9ad99f60)
    at threads.c:694
#47 0x00007ffaed73ad82 in scm_boot_guile (argc=argc <at> entry=6, argv=argv <at> entry=0x7ffe9ad9a0c8, 
    main_func=main_func <at> entry=0x401240 <inner_main>, closure=closure <at> entry=0x0) at init.c:291
#48 0x0000000000401100 in main (argc=6, argv=0x7ffe9ad9a0c8) at guile.c:95
--8<---------------cut here---------------end--------------->8---

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?

Ludo’.

Message #19 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Thu, 16 Apr 2020 18:29:59 +0100

[Message part 1 (text/plain, inline)]

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

> Hi Christopher,
>
> Christopher Baines <mail <at> 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.

Thanks,

Chris

[reproduce-core-updates-mmap-PROT_NONE-failed.scm (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Thu, 16 Apr 2020 20:24:15 +0100

[Message part 1 (text/plain, inline)]

Christopher Baines <mail <at> cbaines.net> writes:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Christopher,
>>
>> Christopher Baines <mail <at> 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 <at> 7
rather than libgc <at> 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 <at> 7 for now?

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Fri, 17 Apr 2020 11:02:20 +0200

Hi,

Glad you manage to get more info.

Christopher Baines <mail <at> cbaines.net> skribis:

> Following up on this, I've built Guile on core-updates with libgc <at> 7
> rather than libgc <at> 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 <at> 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 <at> 7 for now?

Yes, we can define a Guile variant in (gnu packages guile) and have
(guix self) refer to it.

Thanks,
Ludo’.

Message #28 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>, Marius Bakke
 <mbakke <at> fastmail.com>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Fri, 17 Apr 2020 18:34:55 +0100

[Message part 1 (text/plain, inline)]

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

> Glad you manage to get more info.
>
> Christopher Baines <mail <at> cbaines.net> skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc <at> 7
>> rather than libgc <at> 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 <at> 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 <at> 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.

[signature.asc (application/pgp-signature, inline)]

Message #33 received at 40525-done <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>, Marius Bakke
 <mbakke <at> fastmail.com>
Cc: 40525-done <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Sat, 18 Apr 2020 17:53:17 +0100

[Message part 1 (text/plain, inline)]

Christopher Baines <mail <at> cbaines.net> writes:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Glad you manage to get more info.
>>
>> Christopher Baines <mail <at> cbaines.net> skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc <at> 7
>>> rather than libgc <at> 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 <at> 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 <at> 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!

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Sat, 08 May 2021 11:56:03 +0200

Hi,

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

> Christopher Baines <mail <at> cbaines.net> skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc <at> 7
>> rather than libgc <at> 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 <at> 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 <at> 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’.

Message #43 received at 40525 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40525 <at> debbugs.gnu.org
Subject: Re: bug#40525: inferior process on core-updates crashes:
 mmap(PROT_NONE) failed
Date: Sat, 08 May 2021 20:58:44 +0100

[Message part 1 (text/plain, inline)]

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

> Hi,
>
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> Christopher Baines <mail <at> cbaines.net> skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc <at> 7
>>> rather than libgc <at> 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 <at> 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 <at> 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 :)

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.