bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: symbolic links: bug?


From: Thomas Schwinge
Subject: Re: symbolic links: bug?
Date: Tue, 1 Mar 2005 11:00:36 +0100
User-agent: Mutt/1.4.2.1i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]