Re: The problems for the rootless subhurd

[Da Zheng]

olafBuddenhagen@gmx.net wrote:
> > However, it seems to be the source of the most serious  bug in my
> > modified boot.
> >
> > BUG: After I added the proxy for all RPCs to 'boot', I find that
> > subhurd  sometimes failed to boot. For example, it sometimes stops
> > booting after  the system displays "GNU 0.3 (hurd) (console)" and it
> > sometimes boots  successfully and displays "login>" but stops working
> > after I try to  login. Sometimes, it even prints the error message
> > like
> >     
>
>   
> >    getty[47]: /bin/login: No such file or directory Use `login USER'
> >    to login, or `help' for more information.
> >     
>
>   
> > Of course, sometimes subhurd can boot and I can login successfully.
> >     
>
> Sounds like some kind of race condition... But I don't know where.
>
> You could try tracing all RPCs made to the proxy (using some logging
> mechanism in the proxy itself, or perhaps rpctrace), and comparing the
> results of various runs...
I logged all RPCs and tried to analyze them. (antrik, I was wrong. There 
aren't 100, 000 RPCs. The number of RPCs to the Mach during the subhurd 
booting is about 20,000 - 60,000).
I found something abnormal, but I am not sure if it should be considered 
as errors. I list all of errors below:

   * Lots of mach_port_deallocate are called to deallocate the port 
with the name 0. A few of them deallocate a port with the name -1. Some 
try to deallocate a port whose name is positive but still fail.
   * some mach_port_request_notification returns invalid name. All of 
these failed RPCs are sent from the same task and try to cancel the DEAD 
NAME previous notification request.
   * some vm_region returns "no space available". I assume that it is a 
normal case. It's possible that there is no region at or above address 
in the specified task.
   * some task_info return "invalid argument" error, probably because 
the task has already died.

The errors below are a bit rare. They don't always appear and don't seem 
to be related to whether the subhurd can be booted successfully or not.
   * some vm_allocate returns "invalid argument" error. The Mach 
reference doesn't mention that vm_allocate can return this type of 
error. I assume the target task has died.
   * I also see mach_port_allocate and mach_port_mod_refs return 
"invalid task" error once.

I don't understand why some programs try to deallocate MACH_PORT_NULL or 
even -1.
With regard to the failure of mach_port_request_notification, I guess 
it's because the port of that name has already died. But I fail to 
understand why there is more failure than success when the program tries 
to cancel the previous notification request. As far as I see, only 
'console' tries to cancel the notification request.
That's all I find for now.

Zheng Da