bug#56503: Poor error message on missing file using substitute*

bug#56503: Poor error message on missing file using substitute*

[Maxim Cournoyer]

Hello Guix,

When substitute* encounters a nonexistent file, the error is reported to
the guix CLI like so:

--8<---------------cut here---------------start------------->8---
error: in phase 'bake-tor': uncaught exception:
system-error "mkstemp" "~A" ("No such file or directory") (2) 
phase `bake-tor' failed after 0.0 seconds
Backtrace:
          11 (primitive-load "/gnu/store/0i9iay6rahmps8by40aja6qz1fv…")
In guix/build/gnu-build-system.scm:
    906:2 10 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
    634:9  8 (for-each #<procedure 7ffff49ef640 at guix/build/gnu-b…> …)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   927:23  6 (_)
In ice-9/eval.scm:
    619:8  5 (_ #(#(#<directory (guile-user) 7ffff5fdbc80>) (# # …)))
In srfi/srfi-1.scm:
    634:9  4 (for-each #<procedure substitute-one-file (a)> _)
In guix/build/utils.scm:
   843:19  3 (with-atomic-file-replacement "desktop/src/onionshare/…" …)
In unknown file:
           2 (mkstemp! "desktop/src/onionshare/gui_common.py.XXXXXX" #)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure mkstemp: No such file or directory
note: keeping build directory `/tmp/guix-build-onionshare-cli-2.5.drv-0'
--8<---------------cut here---------------end--------------->8---

The main error message, "system-error "mkstemp" "~A" ("No such file or
directory") (2)" is malformed and doesn't report the actual file which
is missing; one must decipher the backtrace for clues as to which file
caused the error.

We should improve it :-).

Maxim

bug#56503: Poor error message on missing file using substitute*

[Daniel Meißner via Bug reports for GNU Guix]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> When substitute* encounters a nonexistent file, the error is reported
> to the guix CLI like so:
>
> [...]
>
> The main error message, "system-error "mkstemp" "~A" ("No such file or
> directory") (2)" is malformed and doesn't report the actual file which
> is missing; one must decipher the backtrace for clues as to which file
> caused the error.
>
> We should improve it :-).

I am Guix and Guile newbie but looking at the definition of the
procedure ‘with-atomic-file-replacement’ I think we have to catch the
(possible) exception of the call to ‘mkstemp!’ and provide a custom
error message.

This is because the exception thrown by ‘mkstemp!’ does not contain any
information about which file was tried.  Try this snippet in a Guile
REPL:

--8<---------------cut here---------------start------------->8---
(with-exception-handler (lambda (x) (write x) (newline))
  (lambda ()
    (mkstemp! "/non/existing/path/foo.XXXXXX")))
--8<---------------cut here---------------end--------------->8---

It prints:

--8<---------------cut here---------------start------------->8---
#<&compound-exception components: (#<&external-error> #<&origin origin: "mkstemp"> #<&message message: "~A"> #<&irritants irritants: ("Datei oder Verzeichnis nicht gefunden")> #<&exception-with-kind-and-args kind: system-error args: ("mkstemp" "~A" ("Datei oder Verzeichnis nicht gefunden") (2))>)>
--8<---------------cut here---------------end--------------->8---

So maybe this is a bug in Guile? Shouldn’t ‘mkstemp!’ list the path in
the irritants?

Best

-- 
Daniel

bug#56503: Poor error message on missing file using substitute*

[Liliana Marie Prikler]

Am Mittwoch, dem 13.07.2022 um 12:23 +0200 schrieb Daniel Meißner:
> Hi,
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> 
> > When substitute* encounters a nonexistent file, the error is
> > reported
> > to the guix CLI like so:
> > 
> > [...]
> > 
> > The main error message, "system-error "mkstemp" "~A" ("No such file
> > or
> > directory") (2)" is malformed and doesn't report the actual file
> > which
> > is missing; one must decipher the backtrace for clues as to which
> > file
> > caused the error.
> > 
> > We should improve it :-).
> 
> I am Guix and Guile newbie but looking at the definition of the
> procedure ‘with-atomic-file-replacement’ I think we have to catch the
> (possible) exception of the call to ‘mkstemp!’ and provide a custom
> error message.
> 
> This is because the exception thrown by ‘mkstemp!’ does not contain
> any
> information about which file was tried.  Try this snippet in a Guile
> REPL:
> 
> --8<---------------cut here---------------start------------->8---
> (with-exception-handler (lambda (x) (write x) (newline))
>   (lambda ()
>     (mkstemp! "/non/existing/path/foo.XXXXXX")))
> --8<---------------cut here---------------end--------------->8---
> 
> It prints:
> 
> --8<---------------cut here---------------start------------->8---
> #<&compound-exception components: (#<&external-error> #<&origin
> origin: "mkstemp"> #<&message message: "~A"> #<&irritants irritants:
> ("Datei oder Verzeichnis nicht gefunden")> #<&exception-with-kind-
> and-args kind: system-error args: ("mkstemp" "~A" ("Datei oder
> Verzeichnis nicht gefunden") (2))>)>
> --8<---------------cut here---------------end--------------->8---
> 
> So maybe this is a bug in Guile? Shouldn’t ‘mkstemp!’ list the path
> in the irritants?
IMHO this matters little, as one can let-bind the filename or (as we do
it) take it as argument.  The reason Guile does not report it is
probably because it's converted from a POSIX errno, which lacks that
context :)

What's a little more confusing is that a throw-handler is installed
directly after mkstemp!, which re-raises the exception.  This is an
alternative way of failing when the file does not exist, as it wraps
call-with-input-file.

Cheers

bug#56503: Poor error message on missing file using substitute*

[Ludovic Courtès]

Hi,

Daniel Meißner <daniel.meissner-i4k@ruhr-uni-bochum.de> skribis:

> It prints:
>
> #<&compound-exception components: (#<&external-error> #<&origin origin: "mkstemp"> #<&message message: "~A"> #<&irritants irritants: ("Datei oder Verzeichnis nicht gefunden")> #<&exception-with-kind-and-args kind: system-error args: ("mkstemp" "~A" ("Datei oder Verzeichnis nicht gefunden") (2))>)>
>
> So maybe this is a bug in Guile? Shouldn’t ‘mkstemp!’ list the path in
> the irritants?

Yes, it should, but it’s a change that’s probably not safe to do within
a Guile stable series.

For the record, (guix ui) works around this for selected procedures—look
for ‘error-reporting-wrapper’.  These are not used (and cannot be used)
in (guix build utils) though.

Ludo’.