First trouble with core

[Norman Feske]

Hi Marc,

Marc CHALAND wrote:
> 2008/8/13 Norman Feske <norman.feske at ...1...>:
>> Indeed, the current version of Genode locates stacks in the heap,
>> which is generally a bad idea because this makes it really hard
>> to detect stack overflows.
> 
> Sure. Better, stack should not be executable. The best would be that
> genode provide a way to prevent memory from being both writable and
> executable. On TUDOS, we found something : create a DM_Phys task
> (nxdm_phys for example) which provides only nx memory. Then only
> loader should get memory from normal dm_phys and provide not writable
> executable memory to launched processes. But, I know, fiasco doesn't
> provide abstraction to nx bit.

Supporting the NX bit makes much sense and it would also fit nicely
into the Genode interfaces. However, this would not help for the
current problem because both the stack and the heap are read/writable.

>> For solving your current problem, it would be helpful to be able
>> to reproduce it. How do you trigger the bug and how does your
>> config file look like? Could you provide us with the backtraces
>> of Core's threads?
> 
> This is very easy to produce with svn 9 revision.
> My menu.lst is :
> set MCGEN="(nd)/tftpboot/l4-test3/marc/genode-build"
> 
> title Genode marc - demo
> kernel $(MCGEN)/3rd/l4env/bin/x86_586/bootstrap
> modaddr 0x03000000
> module $(MCGEN)/3rd/fiasco_x86/main -serial_esc -comspeed 115200 -comport 1
> module $(MCGEN)/3rd/l4env/bin/x86_586/l4v2/sigma0
> module $(MCGEN)/genode_fiasco/bin/core
> module $(MCGEN)/genode_fiasco/bin/init
> module $(MCGEN)/genode_fiasco/bin/config
> module $(MCGEN)/genode_fiasco/bin/ps2_drv
> module $(MCGEN)/genode_fiasco/bin/vesa_drv
> module $(MCGEN)/genode_fiasco/bin/nitpicker
> module $(MCGEN)/genode_fiasco/bin/timer
> module $(MCGEN)/genode_fiasco/bin/launchpad
> module $(MCGEN)/genode_fiasco/bin/testnit
> module $(MCGEN)/genode_fiasco/bin/scout
> module $(MCGEN)/genode_fiasco/bin/nitlog
> module $(MCGEN)/genode_fiasco/bin/liquid_fb
> 
> If I remove applications after launchpad, there is no more problem but
> I cannot launch anything :/.
> Config file is :
> <config>
> 	<start>
> 		<filename>timer</filename>
> 		<ram_quota>1M</ram_quota>
> 	</start>
> 	<start>
> 		<filename>ps2_drv</filename>
> 		<ram_quota>1M</ram_quota>
> 	</start>
> 	<start>
> 		<filename>vesa_drv</filename>
> 		<ram_quota>1M</ram_quota>
> 	</start>
> 	<start>
> 		<filename>nitpicker</filename>
> 		<ram_quota>1M</ram_quota>
> 	</start>
> 	<start>
> 		<filename>launchpad</filename>
> 		<ram_quota>32M</ram_quota>
> 	</start>
> </config>

Thank you for your configuration but unfortunately, I was not able to
trigger the bug. Are you using the tool chain from our website?

> _curr_obj is at 0x647a4. bt of 4.04 is :
> backtrace (thread 4.04, fp=000647a8, pc=010024dc):
>   #1 000647a8 010024dc
>   #2 000647f8 01002726
>   #3 00064928 0100337b
>   #4 00064a58 0100285e
>   #5 00064b88 0100285e
>   #6 00064cb8 0100285e
>   #7 00064de8 0100285e
>   #8 00064f18 0100285e
>   #9 00065048 0100285e
>  #10 00065178 0100285e
>  #11 000652a8 0100285e
>  #12 000652c8 01000a1c
>  #13 00065318 0100227e
>  #14 00065338 01003c13
>  #15 00065358 010000e7
>  #16 00065378 0100030f
>  #17 00065398 01000854
>  #18 000653c8 010008c6
>  #19 00065408 01002215
>  #20 00065428 010264f5
>  #21 00065458 01031629
>  #22 00065498 0100f959
>  #23 000654b8 010040d1
>  #24 000654d8 01025c00
>  #25 00065528 0102c062
>  #26 00065658 0102b6ac
>  #27 000656c8 01026240
>  #28 00065748 010181aa
>  #29 000657a8 01036278
> 
>  --kernel-bt-follows--
>   #2 f005f438 f000c216
>   #3 f005f4c4 f002a306
>   #4 f005f4dc f001b04d
>   #5 f005f4f4 f001af1f
>   #6 c0204f2c f0023ac2
>   #7 c0204fa4 f0022491
>   #8 c0204fac f003aa04

This backtrace explains me where the problem lies as the
difference between the first and the last stack frame are
exactly 4K, which corresponds the the stack dimensioning
of Core's Init-Child thread (4.4). The problem occurs when
opening a new RM session, which requires memory allocation
for the session object. During this memory allocation, a
slab block fills up completely, requiring the allocation
of another slab block. This nested allocation eats more
than 4K. Could you try setting the stack size of to 8192
instead of 4096? Just modify the template argument for
the server activation at

  base/include/base/child.h:124

Best regards

Norman

-- 
Norman Feske
Genode Labs

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