When running the test case from https://github.com/genodelabs/genode/issues/559 on 64-bit Fiasco.OC, the kernel runs out of memory after the sequential construction and destruction of tasks. I've added some debug output to the kernel which tracks the kernel memory allocations and deallocations. The attached log files cover the creation and destruction of one task on 64-bit and 32-bit Fiasco.OC.
In the 64-bit case the allocations reported in lines (05/06), (07/08), (12/13), (14/15), (20/21) and (24/25) don't have matching calls of 'free()'. These allocations belong to the 'Ptab::Walk::sync()' and 'Ptab::Walk::walk()' functions. It looks like only a part of the page table gets destroyed during 'Mem_space::dir_shutdown()'.
In the 32-bit case the amout of memory available after the destruction of the task is the same as before the construction, but what I found odd about the log output is that the allocations reported in lines (10/11) and (14/15) don't have matching calls of 'free()', whereas the allocations reported in lines (09) and (12/13) each have two calls of 'free()' (in lines (22/25) and (28/32)), which makes the amount of memory available balanced again.
Christian
On Tue Dec 11, 2012 at 21:04:14 +0100, Christian Prochaska wrote:
When running the test case from https://github.com/genodelabs/genode/issues/559 on 64-bit Fiasco.OC, the kernel runs out of memory after the sequential construction and destruction of tasks. I've added some debug output to the kernel which tracks the kernel memory allocations and deallocations. The attached log files cover the creation and destruction of one task on 64-bit and 32-bit Fiasco.OC.
In the 64-bit case the allocations reported in lines (05/06), (07/08), (12/13), (14/15), (20/21) and (24/25) don't have matching calls of 'free()'. These allocations belong to the 'Ptab::Walk::sync()' and 'Ptab::Walk::walk()' functions. It looks like only a part of the page table gets destroyed during 'Mem_space::dir_shutdown()'.
In the 32-bit case the amout of memory available after the destruction of the task is the same as before the construction, but what I found odd about the log output is that the allocations reported in lines (10/11) and (14/15) don't have matching calls of 'free()', whereas the allocations reported in lines (09) and (12/13) each have two calls of 'free()' (in lines (22/25) and (28/32)), which makes the amount of memory available balanced again.
Thanks for the report. Interestingly we have found the same (or at least very similar issue) just a few days ago. We'll look into this.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Christian Prochaska