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

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Christopher Baines  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 :)


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Christopher Baines  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’.

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

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Glad you manage to get more info.
>>
>> Christopher Baines  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!


signature.asc
Description: PGP signature

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

[Christopher Baines]

Ludovic Courtès  writes:

> Glad you manage to get more info.
>
> Christopher Baines  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.


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hi,

Glad you manage to get more info.

Christopher Baines  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.

Thanks,
Ludo’.

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

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Hi Christopher,
>>
>> Christopher Baines  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 .
>>
>> 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" #)
> 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?


signature.asc
Description: PGP signature

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

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Christopher,
>
> Christopher Baines  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 .
>
> 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" #)
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)
   (($  file line column)
(list (if (string-prefix? "/gnu/store/" file)
  (string-join (drop (string-split file #\/) 8) "/")
  

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

[Ludovic Courtès]

Hi Christopher,

Christopher Baines  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  0x7fc5d8145aba in raise () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#1  0x7fc5d8146bf5 in abort () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#2  0x7fc5d86d94ee in GC_unmap () from 
/gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#3  0x7fc5d86d95d1 in GC_unmap_old.part.30 ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#4  0x7fc5d86e0882 in GC_finish_collection ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#5  0x7fc5d86e0cf5 in GC_try_to_collect_inner ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#6  0x7fc5d86e1138 in GC_collect_or_expand ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#7  0x7fc5d86e1517 in GC_alloc_large ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#8  0x7fc5d86e545a in GC_generic_malloc ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#9  0x7fc5d86e56a2 in GC_malloc_kind_global ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#10 0x7fc5d8805ce5 in resize_table (table=table@entry=0x7fc5d6318cb0) at 
weak-table.c:251
#11 0x7fc5d8806638 in weak_table_put_x (value=#, 
key="mirror://cpan/authors/id/M/MI/MIYAGAWA/", closure=0x7fc5434535c0, 
pred=0x7fc5d8805bb0 , 
hash=4466916161623136036, table=0x7fc5d6318cb0) at weak-table.c:377
#12 scm_c_weak_table_put_x (table=, 
raw_hash=4466916161623136036, 
pred=0x7fc5d8805bb0 , closure=0x7fc5434535c0, 
key="mirror://cpan/authors/id/M/MI/MIYAGAWA/", 
value=#) at weak-table.c:559
#13 0x7fc5d87d6007 in maybe_annotate_source (column=27, line=3340, 
opts=0x7fff347b9708, 
port=#, 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=#, 
opts=opts@entry=0x7fff347b9708) at read.c:726
#15 0x7fc5d87d6720 in scm_read_string (opts=0x7fff347b9708, port=#, chr=34) at read.c:733
#16 read_inner_expression (port=#, opts=0x7fff347b9708) at 
read.c:1822
#17 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#18 0x7fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, 
port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:481
#19 0x7fc5d87d6820 in read_inner_expression (port=#, 
opts=0x7fff347b9708) at read.c:1820
#20 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#21 0x7fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, 
port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:481
#22 0x7fc5d87d6820 in read_inner_expression (port=#, 
opts=0x7fff347b9708) at read.c:1820
#23 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#24 0x7fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, 
port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:481
#25 0x7fc5d87d6820 in read_inner_expression (port=#, 
opts=0x7fff347b9708) at read.c:1820
#26 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#27 0x7fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, 
port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:481
#28 0x7fc5d87d6820 in read_inner_expression (port=#, 
opts=0x7fff347b9708) at read.c:1820
#29 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#30 0x7fc5d87d7c16 in scm_read_sexp (chr=chr@entry=40, 
port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:481
#31 0x7fc5d87d6820 in read_inner_expression (port=#, 
opts=0x7fff347b9708) at read.c:1820
#32 0x7fc5d87d7925 in scm_read_expression (port=port@entry=#, 
opts=opts@entry=0x7fff347b9708) at read.c:1880
#33 0x7fc5d87d8197 in scm_read (port=#) at read.c:1969
#34 0x7fc5c0d5598b in ?? ()
#35 0x7fc5d80bed80 in ?? ()
#36 0x7fc5d886e5c0 in ?? () from 
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
#37 0x7fc5d80bed80 in ?? ()
#38 0x7fc5d87a7f0b in scm_jit_enter_mcode (thread=0x7fc5d80bed80, 
mcode=0x7fc5c9

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

[Christopher Baines]

Ludovic Courtès  writes:

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

(use-modules (ice-9 match)
 (guix inferior)
 (guix channels)
 (guix store))

(define (all-inferior-lint-warnings inf store)
  (define locales
'("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"))

  (define (lint-warnings-for-checker checker-name)
`(lambda (store)
   (let* ((checker (find (lambda (checker)
   (eq? (lint-checker-name checker)
',checker-name))
 %local-checkers))
  (check (lint-checker-check checker)))

 (define lint-checker-requires-store?-defined?
   (defined? 'lint-checker-requires-store?
 (resolve-module '(guix lint

 (define (process-lint-warning lint-warning)
   (list
(match (lint-warning-location lint-warning)
  (($  file line column)
   (list (if (string-prefix? "/gnu/store/" file)
 ;; Convert a string like
 ;; 
/gnu/store/53xh0mpigin2rffg31s52x5dc08y0qmr-guix-module-union/share/guile/site/2.2/gnu/packages/xdisorg.scm
 ;;
 ;; This happens when the checker uses
 ;; package-field-location.
 (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
 (list ,@locales
  (cons (cons source-locale source-message)
messages-by-locale

 (filter
  (match-lambda
((package-id . warnings)
 (not (null? warnings)))
(a
 (error (simple-format #f "NO MATCH FOR ~A\n" a
  (hash-map->list
   (lambda (package-id package)
 (cons
  package-id
  (catch
#t
(lambda ()
  (map process-lint-warning
   (if (and lint-checker-requires-store?-defined?
(lint-checker-requires-store? checker))

   (check package #:store store)
   (check package
(lambda (key . args)
  '()
   %package-table)

  (inferior-eval '(use-modules (srfi srfi-1)
   (guix lint)) inf)
  (inferior-packages inf)
  (let ((checkers
 (inferior-eval
  '(begin
 (map (lambda (checker)
(list (lint-checker-name checker)
  (lint-checker-description checker)
  (if (memq checker %network-dependent-checkers)
  #t
  #f)))
  %all-checkers))
  inf)))
(map
 (match-lambda
   ((name description network-dependent?)
(cons
 (list name description network-dependent?)
 (if network-dependent?
 '()
 (inferior-eval-with-store inf store (lint

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

[Ludovic Courtès]

Hi,

Christopher Baines  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’.