> > First you can try "trap '' SIGLOST" to ignore the signal [...]
>
> ... `mkfs.ufs' tells me about a `(ipc/send) invalid destination port',
> when SIGLOST is trapped.
Ok. That's what I was expecting. The details of the message you looked at
don't tell you anything without examining the port name space of the task.
The port numbers are just 32-bit per-task names for a system global concept
called a port. I don't recall if the Hurd native gdb has any special
support for examining the inferior task's ports. But you can use the
`portinfo' program, e.g. `portinfo 123 456' if 123 is the PID of the
mkfs.ufs process (this should work while it's stopped in gdb) and 456 is
the port name you found in the message. You should be able to examine
_hurd_fd[FD] for the FD that lseek is called on and see what the port is
there. You can also insert `getdport (fd)' calls at various places to
check that the fd hasn't gone bad, like this:
{
mach_port_t dport = getdport(fd);
if (dport == MACH_PORT_NULL)
error(0,errno,"fd %d gone bad",fd);
else
/* don't leak the send right */
mach_port_deallocate(mach_task_self(),dport);
}
Some call somewhere either clobbers the _hurd_fd[fd] data structure, or
consumes the send right. With these techniques, you should be able to tell
which and where.
> Perhaps you could test whether `mkfs.ufs' fails for `root' on your
> system too, with running
>
> dd if=/dev/zero of=./testfs bs=1024 count=1024
> mkfs.ufs --track=1 --sectors=63 ./testfs
Unfortunately I don't have a test system currently. But there are others
here who can give this a try and debug it if it fails.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
