Rm_session_cap invalid

Norman Feske norman.feske at ...1...
Fri May 28 14:10:58 CEST 2010


Hi Steffen,

> Genode::Process::Process(Genode::Dataspace_capability, \
> 	Genode::Ram_session_capability, Genode::Cpu_session_capability,\
> 	Genode::Parent_capability, const char*, char* const*):\
> 	name="init" rm_session_cap().cap()=9000\
> 	rm_session_cap().local_name()=16
> 
> So after the Process::Process ran, _process->rm_session_cap() should
> return the correct capabilities... Lets see:

So far, that looks good.

> virtual Genode::Session_capability
> 	Genode::Child::session(const char*, const char*):
> 		_ram_session_cap.cap()=9000 local_name=7
> 
> virtual int
> 	Genode::Parent_server::dispatch(int, Genode::Ipc_istream&,
> 	Genode::Ipc_ostream&):
> 		server name="Env::ram_session" args="" cap()=9000
> 		local_name=7
> 
> Ok, worked for the ram_session.
> 
> virtual Genode::Session_capability
> 	Genode::Child::session(const char*, const char*):
> 		_cpu_session_cap.cap()=9000 local_name=10
> 
> virtual int
> 	Genode::Parent_server::dispatch(int, Genode::Ipc_istream&,
> 	Genode::Ipc_ostream&):
> 		server name="Env::cpu_session" args="" cap()=9000
> 		local_name=10

So the init process is running and uses the RPC interface to the parent
to issue session requests to construct its 'env()' object. So init's RM
session is definitely working at this point because it is already used
to resolve the page faults of init.

> Ok, worked for the cpu_session as well.
> 
> virtual Genode::Session_capability
> 	Genode::Child::session(const char*, const char*):
> 		_process.rm_session_cap().cap()=0 local_name=0
> 
> virtual int
> 	Genode::Parent_server::dispatch(int, Genode::Ipc_istream&,
> 	Genode::Ipc_ostream&):
> 		server name="Env::rm_session" args="" cap()=0
> 		local_name=0
> 
> Did not work for the rm_session. Do you have any ideas?

There should be no difference about how the 'Env::Rm_session' and
'Env::Cpu_session' is handled. I suppose the memory where the process
object is stored gets corrupted. Maybe a core-allocator problem? Could
you check the page table entry of the memory location of the process
object at the creation time of the process object and at the time when
the error occurs? It should definitely not change. You could also
inspect the memory around the process object to see a possible pattern
of memory corruption.

Norman




More information about the users mailing list