Re: Maxima can't write to /dev/stdout

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 26 07:04, Achim Gratz wrote:
> The following maxima session encounters an EACCESS error that I can't
> make sense of:
> 
> (%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$
> (%i2) write_data(m, "/dev/stdout")$
> Maxima encountered a Lisp error:
> 
> 
> UNIX error 13 (EACCES): Permission denied
> 
> Automatically continuing.
> To enable the Lisp debugger set *debugger-hook* to nil.
> (%i3)
> 
> The strace corresponding to opening /dev/stdout looks normal to me up until the
> write fails:
> [...]
>   133 28731254 [main] lisp 196 symlink_info::check: 15 =
> symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC16B0) (0x3000B)
>    28 28731282 [main] lisp 196 path_conv::check: this->path(/proc/self/fd/1),
> has_acls(1)

/dev/stdout is a symlink to /proc/self/fd/.

>    25 28731595 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFF
>    22 28731617 [main] lisp 196 fhandler_proc::exists: exists (/proc/self)
>    21 28731638 [main] lisp 196 getpid: 196 = getpid()

/proc/self is a symlink to /proc/196.

>    25 28731663 [main] lisp 196 normalize_posix_path: src /proc/196/fd
>    21 28731684 [main] lisp 196 normalize_posix_path: /proc/196/fd =
> normalize_posix_path (/proc/196/fd)

And here something goes wrong.  If I call `echo foo > /dev/stdout' in
bash, the above normalize_posix_path calls already handle the path
/proc/196/fd/1, not just /proc/196/fd as lisp does.

>    22 28731706 [main] lisp 196 mount_info::conv_to_win32_path:
> conv_to_win32_path (/proc/196/fd)
>    21 28731727 [main] lisp 196 fhandler_proc::get_proc_fhandler:
> get_proc_fhandler(/proc/196/fd)
>    22 28731749 [main] lisp 196 set_flags: flags: binary (0x2)
>    24 28731773 [main] lisp 196 mount_info::conv_to_win32_path: src_path
> /proc/196/fd, dst /proc/196/fd, flags 0x2, rc 0
>    25 28731798 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE
>    22 28731820 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd)
>    31 28731851 [main] lisp 196 lstat64: entering

Here it calls lstat(/proc/196/fd/1), which works, but doesn't
resolve the symlink.

>    [...]
>    23 28732180 [main] lisp 196 stat_worker: 0 = (/proc/196/fd/1,0xDC3B30)
>    23 28732203 [main] lisp 196 normalize_posix_path: src /proc/196/fd/1
>    23 28732226 [main] lisp 196 normalize_posix_path: /proc/196/fd/1 =
> normalize_posix_path (/proc/196/fd/1)
>    21 28732247 [main] lisp 196 mount_info::conv_to_win32_path:
> conv_to_win32_path (/proc/196/fd/1)
>    22 28732269 [main] lisp 196 fhandler_proc::get_proc_fhandler:
> get_proc_fhandler(/proc/196/fd/1)
>    21 28732290 [main] lisp 196 set_flags: flags: binary (0x2)
>    21 28732311 [main] lisp 196 mount_info::conv_to_win32_path: src_path
> /proc/196/fd/1, dst /proc/196/fd/1, flags 0x2, rc 0
>    26 28732337 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE
>    22 28732359 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd/1)

In fact, it never tried to resolve the symlink up to here.

>    29 28732388 [main] lisp 196 normalize_posix_path: src /proc/196/fd/.
>    22 28732410 [main] lisp 196 normalize_posix_path: /proc/196/fd/ =
> normalize_posix_path (/proc/196/fd/.)

...so what is it doing with /proc/196/fd/. now?

>    [...]
>    98 28757380 [main] lisp 196 stat64: entering
>    [...]
>    26 28757895 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC39E0)

Calling stat on it, but what for?

>    28 28757923 [main] lisp 196 stat64: entering
>    [...]
>    72 28758456 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC3A50)

...and again...

>    26 28758482 [main] lisp 196 open: open(/proc/196/fd/, 0x10601)

And now it opend the directory /proc/196/fd ...

>    88 28759279 [main] lisp 196 open: 4 = open(/proc/196/fd/, 0x18601)

gets the descriptor 4 ...

>   550 28759904 [main] lisp 196 write: write(4, 0xDC2480, 1)
>    38 28759942 [main] lisp 196 __set_errno: virtual ssize_t
> fhandler_virtual::write(const void*, size_t):211 setting errno 13
>    29 28759971 [main] lisp 196 write: -1 = write(4, 0xDC2480, 1), errno 13

... tries to write to it and *of course* gets an EACCES.

I don't know what lisp is trying to do here, but it doesn't look like
Cygwin's fault.  After all, echo foo > /dev/stdout works fine.  Also,
if descriptor 1 is closed, the error message looks different:

  $ echo foo 1>&- >/dev/stdout
  bash: /dev/stdout: No such file or directory


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple