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’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 56503@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56503
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch