bug#39997: High CPU load and no return value with 3.0.0

[Ludovic Courtès]

Hi,

Roel Janssen  skribis:

> When I use the "md5" module from guile-lib (release 0.2.6.1) together
> with the following snippet in Guile 3.0.0, it never returns, while on
> Guile 2.2.6, it returns the MD5 sum of the input string:
> ---
> (use-modules (md5))
>
> (define (md5-from-string input)
>   (call-with-input-string input md5))
>
> (define (random-ascii length)
>   "Returns a random string of ASCII characters of length LENGTH."
>   (list->string
>(map (lambda _ (integer->char (+ (random 95) 32)))
> (iota length
>
> (display
>  (md5-from-string
>   (random-ascii 32)))
> ---
>
> Could you point me in the right direction for finding the problem?

The Guix package has this patch:

'(begin
   ;; Work around miscompilation on Guile 3.0.0 at -O2:
   ;; .
   (substitute* "src/md5.scm"
 (("\\(define f-ash ash\\)")
  "(define f-ash (@ (guile) ash))\n")
 (("\\(define f-add \\+\\)")
  "(define f-add (@ (guile) +))\n"))
   #t)

It’s very likely that you’re hitting this problem.

HTH!

Ludo’.

bug#39999: make install fails on mac (Catilina, Guile-3.0.1)

[Ludovic Courtès]

Hi,

Massimiliano Gubinelli  skribis:

>  make install on the last Guile 3.0.1 fails on my Mac (Catilina) with the 
> following message
>
>
>  ../build-aux/install-sh -c -d 
> '/Users/mgubi/t/guile3-usr/include/guile/3.0/libguile'
>  /usr/bin/install -c -m 644 version.h scmconfig.h 
> '/Users/mgubi/t/guile3-usr/include/guile/3.0/libguile'
> /Library/Developer/CommandLineTools/usr/bin/make  install-data-hook
>  /usr/bin/install -c -m 644 libguile-3.0-gdb.scm  
> /Users/mgubi/t/guile3-usr/lib/libguile-3.0.a-gdb.scm
> sed: -e: No such file or directory
> make[5]: *** [install-data-hook] Error 1
> make[4]: *** [install-data-am] Error 2
> make[3]: *** [install-am] Error 2
> make[2]: *** [install] Error 2
> make[1]: *** [install-recursive] Error 1
> make: *** [install] Error 2

I suppose the ‘sed’ invocation in the INSTANTIATE variable in Makefile
assumes we’re using GNU sed, which is probably not the case on your
machine.

> I found that the following change to libguile/Makefile go around the problem
>
> INSTANTIATE = \
>   $(SED) -i '' -e 's,[@]pkgdatadir[@],$(pkgdatadir),g'
>   \
> -e 's,[@]pkglibdir[@],$(pkglibdir),g' 
>   \
> -e 's,[@]GUILE_EFFECTIVE_VERSION[@],$(GUILE_EFFECTIVE_VERSION),g’

What if you move ‘-i’ last, and without ''?  That should expand to
something like:

  sed -e … -e … -e … -i libguile-3.0-gdb.scm

Thanks,
Ludo’.

bug#40008: Backtraces can contain very long strings

[Ludovic Courtès]

Hi,

 skribis:

> On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
>> I have the following backtrace:
>> 
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>8 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>> 718:2  7 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  6 (_ #(#(#)))
>> In ice-9/boot-9.scm:
>>2806:4  5 (save-module-excursion _)
>>   4351:12  4 (_)
>> In /home/jsynacek/./git.scm:
>>  72:0  3 (_)
>> 61:16  2 (change-spec _ _ "66.33" _ #)
>> 48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
>> In unknown file:
>>0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
>> 
>> ERROR: In procedure make-regexp:
>> Wrong type (expecting exact integer): "
>> 
>> "
>> 
>> While this is probably not considered an error, I guess it might be better
>> to ellipsize strings in errors such is mine that are over a certain length
>> long. The important part of the backtrace was scrolled away and I got
>> confused about the string, as I thought it was part of the output and
>> started wondering why (display ...) keeps the escaped newlines in the
>> string.
>
> Some want it, some want it not. I remember a couple of discussions
> in guile-user and guile-devel about this topic.
>
> Have you tried setting debug options `width' and/or `depth' (cf. procedure
> `debug-options')?
>
> (my current defaults are 79 columns/20 rows, this is Guile 3.0).

The backtrace itself is ellipsized, but the value displayed in the
exception (the long string above) is not.

I would rather not ellipsize anything in the exception itself.

Thoughts?

Ludo’.

bug#40014: [PATCH] typo in api-debug.texi

[Ludovic Courtès]

Hi,

Jan Synacek  skribis:

> From 8617b6a94054aafc4a58cd1e5581154e1e9ea353 Mon Sep 17 00:00:00 2001
> From: Jan Synacek 
> Date: Tue, 10 Mar 2020 15:36:03 +0100
> Subject: [PATCH] texinfo: Fix typo in api-debug.texi
>
> ---
>  doc/ref/api-debug.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I tweaked the commit log and applied.  Thanks!

Ludo’.

bug#40008: Backtraces can contain very long strings

[Mikael Djurfeldt]

On Wed, Mar 11, 2020 at 12:14 PM Ludovic Courtès  wrote:

> Hi,
>
>  skribis:
>
> > On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
> >> I have the following backtrace:
> >>
> >> Backtrace:
> >> In ice-9/boot-9.scm:
> >>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> >> In unknown file:
> >>8 (apply-smob/0 #)
> >> In ice-9/boot-9.scm:
> >> 718:2  7 (call-with-prompt _ _ #)
> >> In ice-9/eval.scm:
> >> 619:8  6 (_ #(#(#)))
> >> In ice-9/boot-9.scm:
> >>2806:4  5 (save-module-excursion _)
> >>   4351:12  4 (_)
> >> In /home/jsynacek/./git.scm:
> >>  72:0  3 (_)
> >> 61:16  2 (change-spec _ _ "66.33" _ #)
> >> 48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
> >> In unknown file:
> >>0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
> >>
> >> ERROR: In procedure make-regexp:
> >> Wrong type (expecting exact integer): "
> >> 
> >> "
> >>
> >> While this is probably not considered an error, I guess it might be
> better
> >> to ellipsize strings in errors such is mine that are over a certain
> length
> >> long. The important part of the backtrace was scrolled away and I got
> >> confused about the string, as I thought it was part of the output and
> >> started wondering why (display ...) keeps the escaped newlines in the
> >> string.
> >
> > Some want it, some want it not. I remember a couple of discussions
> > in guile-user and guile-devel about this topic.
> >
> > Have you tried setting debug options `width' and/or `depth' (cf.
> procedure
> > `debug-options')?
> >
> > (my current defaults are 79 columns/20 rows, this is Guile 3.0).
>
> The backtrace itself is ellipsized, but the value displayed in the
> exception (the long string above) is not.
>
> I would rather not ellipsize anything in the exception itself.
>
> Thoughts?
>

It would be nice if this was configurable. As Tomas pointed out this kind
of thing can be a matter of taste. Also, if debugging some specific problem
involving large strings it might be convenient to switch on for anyone.

There could be a debug-option (see (debug-options '?)) `exception-width'
(similar to `width' but for errors and exceptions).

But how is the debug-options interface regarded nowadays? Is it going to be
deprecated? I notice that the `width' option doesn't seem to have an effect
anymore. Looking into backtrace.c and (system repl debug) the width
nowadays rather seems to be controlled by the terminal width only.

Best regards,
Mikael

bug#39997: High CPU load and no return value with 3.0.0

[Roel Janssen]

On Wed, 2020-03-11 at 12:07 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Roel Janssen  skribis:
> 
> > When I use the "md5" module from guile-lib (release 0.2.6.1)
> > together
> > with the following snippet in Guile 3.0.0, it never returns, while
> > on
> > Guile 2.2.6, it returns the MD5 sum of the input string:
> > ---
> > (use-modules (md5))
> > 
> > (define (md5-from-string input)
> >   (call-with-input-string input md5))
> > 
> > (define (random-ascii length)
> >   "Returns a random string of ASCII characters of length LENGTH."
> >   (list->string
> >(map (lambda _ (integer->char (+ (random 95) 32)))
> > (iota length
> > 
> > (display
> >  (md5-from-string
> >   (random-ascii 32)))
> > ---
> > 
> > Could you point me in the right direction for finding the problem?
> 
> The Guix package has this patch:
> 
> '(begin
>;; Work around miscompilation on Guile 3.0.0 at -O2:
>;; ;.
>(substitute* "src/md5.scm"
>  (("\\(define f-ash ash\\)")
>   "(define f-ash (@ (guile) ash))\n")
>  (("\\(define f-add \\+\\)")
>   "(define f-add (@ (guile) +))\n"))
>#t)
> 
> It’s very likely that you’re hitting this problem.

Yes!  Thanks for sharing this fix.
I applied the same changes to my code and now I don't encounter the bug
anymore.

I tested the patched code with both guile-2.2 and guile-3.0.  Do you
know whether this will also work with guile-2.0?  (I'd like to keep
things compatible with guile-2.0 for a few more years).

Kind regards,
Roel Janssen

bug#39997: High CPU load and no return value with 3.0.0

[Ludovic Courtès]

Roel Janssen  skribis:

> On Wed, 2020-03-11 at 12:07 +0100, Ludovic Courtès wrote:

[...]

>> The Guix package has this patch:
>> 
>> '(begin
>>;; Work around miscompilation on Guile 3.0.0 at -O2:
>>;; ;.
>>(substitute* "src/md5.scm"
>>  (("\\(define f-ash ash\\)")
>>   "(define f-ash (@ (guile) ash))\n")
>>  (("\\(define f-add \\+\\)")
>>   "(define f-add (@ (guile) +))\n"))
>>#t)
>> 
>> It’s very likely that you’re hitting this problem.
>
> Yes!  Thanks for sharing this fix.
> I applied the same changes to my code and now I don't encounter the bug
> anymore.
>
> I tested the patched code with both guile-2.2 and guile-3.0.  Do you
> know whether this will also work with guile-2.0?  (I'd like to keep
> things compatible with guile-2.0 for a few more years).

Yes, the change above also works for Guile 2.0.

Ludo’.

bug#36811: Guix fails to build with libgc 8.0.4

[Ludovic Courtès]

Hi Jonathan,

Ludovic Courtès  skribis:

> As discussed yesterday on #guix, I tried this:
>
>   guix build guile3.0-guix --with-input=libgc@7=libgc@8

With Guile 3.0.1 + the patch for
, the command above succeeds.

Specifically:

  guix pull --commit=e4b5bdf7993590fefeb7182ae71beec4a9f69e3f
  guix build --with-input=libgc@7=libgc@8 guile3.0-guix

Could you confirm that it works for you?

Thanks,
Ludo’.

bug#39999: make install fails on mac (Catilina, Guile-3.0.1)

[Ludovic Courtès]

Hi Massimiliano,

Massimiliano Gubinelli  skribis:

> Is ok to do
>
> Horst:clean mgubi$ sed  -e 's,pippo,pluto,g' -e 's,pippo,pluto,g' -e 
> 's,pippo,pluto,g'  -i ‘' test

Does it modify the file called ‘test’ in this case?

Thanks for testing!

Ludo’.

bug#39997: High CPU load and no return value with 3.0.0

[Roel Janssen]

On Wed, 2020-03-11 at 15:05 +0100, Ludovic Courtès wrote:
> Roel Janssen  skribis:
> 
> > On Wed, 2020-03-11 at 12:07 +0100, Ludovic Courtès wrote:
> 
> [...]
> 
> > > The Guix package has this patch:
> > > 
> > > '(begin
> > >;; Work around miscompilation on Guile 3.0.0 at -O2:
> > >;; ;;.
> > >(substitute* "src/md5.scm"
> > >  (("\\(define f-ash ash\\)")
> > >   "(define f-ash (@ (guile) ash))\n")
> > >  (("\\(define f-add \\+\\)")
> > >   "(define f-add (@ (guile) +))\n"))
> > >#t)
> > > 
> > > It’s very likely that you’re hitting this problem.
> > 
> > Yes!  Thanks for sharing this fix.
> > I applied the same changes to my code and now I don't encounter the
> > bug
> > anymore.
> > 
> > I tested the patched code with both guile-2.2 and guile-3.0.  Do
> > you
> > know whether this will also work with guile-2.0?  (I'd like to keep
> > things compatible with guile-2.0 for a few more years).
> 
> Yes, the change above also works for Guile 2.0.

Thanks for the confirmation.  I'm closing this bug, as it is basically
a duplicate of #39251.

Kind regards,
Roel Janssen

bug#39999: make install fails on mac (Catilina, Guile-3.0.1)

[Massimiliano Gubinelli]

Hi Ludovic, 
 the problem seems to be the multiple -e together with -i. 

Example:

Horst:clean mgubi$ cat - > test
pippo
Horst:clean mgubi$ sed -i -e 's,pippo,pluto,g' -e 's,pippo,pluto,g' -e 
's,pippo,pluto,g'  test
sed: -e: No such file or directory
Horst:clean mgubi$ sed  -e 's,pippo,pluto,g' -e 's,pippo,pluto,g' -e 
's,pippo,pluto,g'  test
pluto
Horst:clean mgubi$ sed -i -e 's,pippo,pluto,g'  test
Horst:clean mgubi$ 

The first command give error while the other work. If I put -i at the end I get

Horst:clean mgubi$ sed  -e 's,pippo,pluto,g' -e 's,pippo,pluto,g' -e 
's,pippo,pluto,g'  -i test
sed: -i may not be used with stdin

Is ok to do

Horst:clean mgubi$ sed  -e 's,pippo,pluto,g' -e 's,pippo,pluto,g' -e 
's,pippo,pluto,g'  -i ‘' test


Best,
Max



> On 11. Mar 2020, at 12:11, Ludovic Courtès  wrote:
> 
> Hi,
> 
> Massimiliano Gubinelli  skribis:
> 
>> make install on the last Guile 3.0.1 fails on my Mac (Catilina) with the 
>> following message
>> 
>> 
>> ../build-aux/install-sh -c -d 
>> '/Users/mgubi/t/guile3-usr/include/guile/3.0/libguile'
>> /usr/bin/install -c -m 644 version.h scmconfig.h 
>> '/Users/mgubi/t/guile3-usr/include/guile/3.0/libguile'
>> /Library/Developer/CommandLineTools/usr/bin/make  install-data-hook
>> /usr/bin/install -c -m 644 libguile-3.0-gdb.scm  
>> /Users/mgubi/t/guile3-usr/lib/libguile-3.0.a-gdb.scm
>> sed: -e: No such file or directory
>> make[5]: *** [install-data-hook] Error 1
>> make[4]: *** [install-data-am] Error 2
>> make[3]: *** [install-am] Error 2
>> make[2]: *** [install] Error 2
>> make[1]: *** [install-recursive] Error 1
>> make: *** [install] Error 2
> 
> I suppose the ‘sed’ invocation in the INSTANTIATE variable in Makefile
> assumes we’re using GNU sed, which is probably not the case on your
> machine.
> 
>> I found that the following change to libguile/Makefile go around the problem
>> 
>> INSTANTIATE = \
>>  $(SED) -i '' -e 's,[@]pkgdatadir[@],$(pkgdatadir),g'
>>   \
>>-e 's,[@]pkglibdir[@],$(pkglibdir),g' 
>>   \
>>-e 's,[@]GUILE_EFFECTIVE_VERSION[@],$(GUILE_EFFECTIVE_VERSION),g’
> 
> What if you move ‘-i’ last, and without ''?  That should expand to
> something like:
> 
>  sed -e … -e … -e … -i libguile-3.0-gdb.scm
> 
> Thanks,
> Ludo’.

bug#39208: [3.0.0] Segfault while building on ARMv7

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Building 3.0.0 with Guix on ARMv7 reproducibly fails:
>
>   BOOTSTRAP GUILEC language/cps/loop-instrumentation.go
> wrote `language/cps/loop-instrumentation.go'
>   BOOTSTRAP GUILEC language/cps/peel-loops.go
> wrote `language/cps/effects-analysis.go'
>   BOOTSTRAP GUILEC language/cps/prune-top-level-scopes.go
> wrote `language/cps/licm.go'
>   BOOTSTRAP GUILEC language/cps/reify-primitives.go
> wrote `language/cps/prune-top-level-scopes.go'
>   BOOTSTRAP GUILEC language/cps/renumber.go
> wrote `language/cps/peel-loops.go'
>   BOOTSTRAP GUILEC language/cps/rotate-loops.go
> wrote `language/cps/reify-primitives.go'
>   BOOTSTRAP GUILEC language/cps/optimize.go
> wrote `language/cps/renumber.go'
>   BOOTSTRAP GUILEC language/cps/simplify.go
> wrote `language/cps/rotate-loops.go'
>   BOOTSTRAP GUILEC language/cps/self-references.go
> wrote `language/cps/optimize.go'
>   BOOTSTRAP GUILEC language/cps/slot-allocation.go
> wrote `language/cps/self-references.go'
>   BOOTSTRAP GUILEC language/cps/spec.go
> wrote `language/cps/simplify.go'
>   BOOTSTRAP GUILEC language/cps/specialize-primcalls.go
> wrote `language/cps/spec.go'
>   BOOTSTRAP GUILEC language/cps/specialize-numbers.go
> /gnu/store/nvkn00kq4x4g5wjjjvjj6rhzs0ihihxl-bash-minimal-5.0.7/bin/bash: line 
> 6: 23019 Segmentation fault  (core dumped) GUILE_AUTO_COMPILE=0 
> ../meta/build-env guild compile --target="arm-unknown-linux-gnueabihf" -O1 
> -Oresolve-primitives -L 
> "/tmp/guix-build-guile-next-3.0.0.drv-0/guile-3.0.0/module" -L 
> "/tmp/guix-build-guile-next-3.0.0.drv-0/guile-3.0.0/guile-readline" -o 
> "language/cps/specialize-primcalls.go" 
> "../module/language/cps/specialize-primcalls.scm"
> make[2]: *** [Makefile:1931: language/cps/specialize-primcalls.go] Error 139
> make[2]: *** Waiting for unfinished jobs
> wrote `language/cps/slot-allocation.go'
> wrote `language/cps/specialize-numbers.go'
> make[2]: Leaving directory 
> '/tmp/guix-build-guile-next-3.0.0.drv-0/guile-3.0.0/bootstrap'
> make[1]: *** [Makefile:1849: all-recursive] Error 1

This also is fixed by commit 7c17655cd3d859bf0c5a86d9782a7788205fc05a
().

\o/

Ludo’.