Hi Marc,
Marc CHALAND wrote:
2008/8/13 Norman Feske <norman.feske@...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