Hi Frank,
thanks for your investigation. We have also hit this issue (hence my initial guess) on real hardware and it will be fixed in the upcoming release. Until then, I hope you are fine with the interim solution of appending the zero-termination manually. Of course, the pending null character does not comply to the XML syntax. It's just a work-around.
Regards Norman
Frank Kaiser wrote:
Your guess is right: The page fault is caused while parsing the config file. The trigger is the method /Xml_node::content()/, which tries to copy the process’ filename from the config file, but the root cause is a nasty bug in function /Genode::strncpy()/ which is used to obtain the filename. In the function’s first line /Genode::strlen()/ is used to determine the length of the source string. In the given case, where the source is a tagged item of the config file having no null termination, /strlen()/ runs thru the memory until it randomly finds a null character. For my opinion /Genode::strncpy()/ is not allowed to parse the source string beyond the given /size/ argument. Your suggestion of appending a null character to the config file (by the way: how is this to be done w/o corrupting the XML syntax?) heals a symptome, but does not solve the root cause.
I tried to fix /Genode::strncpy()/ myself. Since there is no function /Genode::strnlen()/, I made the following change:
size_t i = 0; while (i < size) { if (src[i] == 0) { size = i; break; } ++i; }Interestingly this seem to trigger another problem. Now I get on all platforms the following two errors:
virtual Genode::Session_capability Genode::Core_parent::session(const char*, const char*): service_name="RM" arg="ram_quota=4K" not handled
virtual Genode::Session_capability Genode::Core_parent::session(const char*, const char*): service_name="PD" arg="ram_quota=4K" not handled
Could it be that there are already some workarounds for buggy /Genode::strncpy()/, which do not work anymore once the function is fixed?
Frank