Roland McGrath <[EMAIL PROTECTED]> writes:
> [...] 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.
Thanks for your helpful advice; fd_get_device() in `dlabel.c' -- this
file is used for providing a disklabel determining function for being
used by mkfs.ufs -- is the place, where the behaviour comes from:
,----------------------------------------------------------------------------
| file_t node = getdport (fd);
|
| if (node == MACH_PORT_NULL)
| return errno;
|
| err = store_create (node, 0, 0, &store);
| if (! err)
| {
| [...]
| store_free (store);
| }
|
| mach_port_deallocate (mach_task_self (), node);
´---------------------------------------------------------------------------
If run as non-root user, there's no store created, `err' is EPERM; so
mach_port_deallocate() correctly ends the use of `node' (I don't know
whether I am using the right terms, when speaking of freeing or
deallocating ports etc.).
When run as root, a store is created that has store->source set to
`node'. `err' is zero, so that after some lines of code the store will
be freed. But within the implementation of store_free() there already
is a call to mach_port_deallocate(self, store->source), if
store->source is not MACH_PORT_NULL.
Since store->source == node, the next call to mach_...(self, node)
seems to destroy the send right or make the port invalid.
A line `store->source = MACH_PORT_NULL;' before the store_free() call
does it fix, but maybe that's dirty. As far as I unterstand it, the
store mechanism takes over the control of the source port when
creating a store, so the source port is deallocated when calling
store_free(). If this is wanted, the line above could probably be one
solution.
The Store Library info entry for store_free() only tells about
deallocation of the underlying stores. Maybe the source should not be
deallocated there since there is store_close_source() to do that?
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
