Mail Archives: cygwin/2012/07/26/04:18:27
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
- Raw text -