Poor error message on missing file using substitute*

  • Open
  • quality assurance status badge
Details
4 participants
  • Daniel Meißner
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 12 Jul 2022 00:16
(name . bug-guix)(address . bug-guix@gnu.org)
87r12r9txi.fsf@gmail.com
Hello Guix,

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

Toggle snippet (32 lines)
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'

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
D
D
Daniel Meißner wrote on 13 Jul 2022 12:23
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 56503@debbugs.gnu.org)
8735f51fbw.fsf@ruhr-uni-bochum.de
Hi,

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

Toggle quote (12 lines)
> 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:

Toggle snippet (5 lines)
(with-exception-handler (lambda (x) (write x) (newline))
(lambda ()
(mkstemp! "/non/existing/path/foo.XXXXXX")))

It prints:

Toggle snippet (3 lines)
#<&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?

Best

--
Daniel
L
L
Liliana Marie Prikler wrote on 13 Jul 2022 21:46
(address . 56503@debbugs.gnu.org)
92fd1571a14de00c9c1deaf2138187ba0530c7eb.camel@gmail.com
Am Mittwoch, dem 13.07.2022 um 12:23 +0200 schrieb Daniel Meißner:
Toggle quote (48 lines)
> 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
L
L
Ludovic Courtès wrote on 18 Jul 2022 14:57
(name . Daniel Meißner)(address . daniel.meissner-i4k@ruhr-uni-bochum.de)
877d4azihn.fsf@gnu.org
Hi,

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

Toggle quote (7 lines)
> 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’.
?