Associating Threads with Process Rm's

[Norman Feske]

Hi Bob,

> I've stripped down the problem to a simple main routine, a threaded
> object that is instantiated in main and contains only the code to create
> the object that accesses the file system. This stripped down version
> results in the same pager issue.
> 
> The attached tar contains the main, the simplified code of the
> thread-based class, the file server access code, the run scipt I used
> for testing, and the console log.
> 
> The main routine contains a fault handler that I copied from a test
> program in base/src and that thread is started prior to starting the
> problem thread.
> 
> I can instantiate the file system object in main and the initialization
> routine successfully access the file system, so the code in there does work.

thanks for stripping down the test case. I just tried it out and could
reproduce the behavior. The problem is quite mundane though: You
dimensioned the stack of the 'CommandTerminal' to be 4096 bytes. This is
too low for a thread that calls the libc. I just increased the value by
a factor of 10 and it works.

It has really nothing to do with the RM fault handling. The code of your
example does not even use the RM connection that you created as a
managed dataspace.

Admittedly, the error message printed by the base-hw version of core is
not very instructive to identify such a stack-overflow problem. But
thanks to your stripped-down example, I could execute it quickly on
nova_x86_32, where a far more useful message appears:

  static void Genode::Pager_object::_page_fault_handler(): unhandled
page fault, 'pager:Command Terminal' address=0xa03fd8c0 ip=0x10a4327

Here we see the name of the thread that just crashed ("pager:Command
Terminal"), the instruction pointer (ip), and the fault address. The
fault address lies within the so-called thread-context area (defined in
base-nova/include/base/native_types.h). This virtual-memory area hosts
all the stacks. If a page fault occurs within the thread-context area,
it is most likely a stack overflow.

We should really add a more useful diagnostic message to the base-hw
version of core. I just created an issue for that:

  https://github.com/genodelabs/genode/issues/1382

For reference, I have attached the run script and target.mk file that I
used for reproducing the issue.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
-------------- next part --------------
build "core init drivers/timer test/pager_issue"

create_boot_directory

install_config {
<config>
	<parent-provides>
		<service name="LOG"/>
		<service name="RM"/>
		<service name="ROM"/>
		<service name="CAP"/>
		<service name="IO_MEM"/>
		<service name="IO_PORT"/>
		<service name="IRQ"/>
		<service name="SIGNAL"/>
		<service name="RAM"/>
	</parent-provides>
	<default-route>
		<any-service> <parent/> <any-child/> </any-service>
	</default-route>
	<start name="timer">
		<resource name="RAM" quantum="1M"/>
		<provides><service name="Timer"/></provides>
	</start>
	<start name="test-pager_issue">
		<resource name="RAM" quantum="10M"/>
		<config ld_verbose="yes"/>
	</start>
</config>
}

build_boot_image "core init timer test-pager_issue ld.lib.so libc.lib.so"

append qemu_args "-nographic -m 64"

run_genode_until forever

puts "Test succeeded"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: target.mk
Type: text/x-makefile
Size: 99 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20150125/460835fd/attachment.bin>