On Tue, Mar 01, 2005 at 03:16:14AM +0100, Alfred M. Szmidt wrote:
> $ rpctrace cat /tmp/d/0123/a/f > rpctrace-2 2>&1
>
> When doing a rpctrace, use the -I option to include msgid files. That
> way the numbers get converted to readable function names.
#v+
$ find /include/ -name '*.defs' | while read f; do echo "$f": >&2 && mig -n
-list /dev/stdout "$f"; done | sort | uniq > /tmp/rpc-list
#v-
I used uniq because there were a few doubled entries. Correct?
According to mig, some of the files could not be processed. Correct?
> Is someone able to reproduce this?
> How can I help to debug this?
>
> I haven't been able to reproduce
Could someone else please try to do so?
> are you using glibc from Debian?
Yes.
> That might be the culprint (as usual). To debug it further, you could
> attach gdb to mv
Note that it's not mv which is failing, but cat.
bash also acts strangely:
#v+
$ cd /tmp/d/0123/a
bash: cd: /tmp/d/0123/a: No such file or directory
$ cd /tmp/d/0123
$ pwd
/tmp/d/0123
$ cd a
$ pwd
/tmp/e/d/c/a
$ # should be /tmp/d/0123/a
$ cat f
OK.
$ cd /tmp/d/0123
$ cat a/f
OK.
$ cd ..
$ pwd
/tmp/d
$ cat 0123/a/f
OK.
$ cd ..
$ pwd
/tmp
$ cat d/0123/a/f
cat: d/0123/a/f: No such file or directory
#v-
#v+
$ rpctrace -I /tmp/rpc-list cat /tmp/d/0123/a/f
[...]
task9638->mach_port_deallocate (pn{ 12}) = 0
97->term_open_ctty (9638 9636) = 0 107
99->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID)
99->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID)
task9638->vm_deallocate (16900096 12) = 0
task9638->vm_protect (134533120 135168 0 7) = 0
99->io_stat_request () = 0 {21 56 0 0 0 0 0 4096 0 0 0 0 0 0 0 1109668673
550000 0 0 65536 0 0 0 0 0 0 0 0 0 0 0 0}
101->dir_lookup ("tmp/d/0123/a/f" 1 0) = 0 3 "/tmp/d/c//d/" (null)
101->dir_lookup ("tmp/d/c//d/" 1 0) = 0x40000002 (No such file or directory)
cat: 99->io_write_request ("cat: " -1) = 0 5
/tmp/d/0123/a/f 99->io_write_request ("/tmp/d/0123/a/f" -1) = 0 15
: No such file or directory 99->io_write_request (": No such file or
directory" -1) = 0 27
99->io_write_request ("
" -1) = 0 1
task9638->mach_port_deallocate (pn{ 7}) = 0
103->proc_mark_exit_request (256 0) = 0
task9638->task_terminate () = 0
Child 9638 exited with 1
#v-
To my untrained eyes it looks like dir_lookup() is failing. Might the
problem be located in hurd/libdiskfs/dir_lookup.c? Or rather somewhere
in glibc?
Is it sufficient to recompile e.g. cat using a newer glibc or do I also
have to recompile (parts of) the Hurd package?
> and step through it and see what is going on, and
> where it went wrong. That would help quite a lot.
Everytime I try to do anything in gdb (the Debain one, again), I'm
getting only "Can't fetch registers from thread 4: No such thread" and
it does not seem to react to my commands.
I just noticed that gdb works as expected when running it as root?!
How can I grant access to "thread 4" for ordinary users?
Regards,
Thomas
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
