mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-21 06:33:31 +00:00
53a990579b
This was discovered when building the code with clang instead of GCC. In this setup the run/ping on base-hw/arm_v8a/virt_qemu would crash on shutdown due to uncaught Deref_unconstructed_object exception thrown for Genode::Reconstructible<Genode::Account<Genode::Ram_quota>>. The specific instance throwing this exception was Pd_session_component::_ram_account. My investigation exposed the following problem: 1. The Pd_session_component has a _sliced_heap member backed by _constrained_ram_alloc which in turn uses Pd_session_component itself as its Ram_allocator. 2. When ~Pd_session_component is called it first destroys _ram_account, followed by _signal_broker. 3. The signal broker holds a reference to Pd_session_component::_sliced_heap as Signal_broker::_md_alloc. 4. The base-hw implementation of ~Signal_broker destroys some contexts and does this by calling Genode::destroy on some slabs using the _md_alloc (ref to Pd_session_component::_sliced_heap). 5. The Genode::Slab calls the Ram_allocator::free which ends up calling Pd_session_component::free. 6. The Pd_session_component::free can among other things call replenish method on Pd_session_component::_ram_account which has already been freed at this point. From my POV calling replenish at this point is basically an undefined behavior. The Genode::Constructible holding the Genode::Account was already detroyed at this point. GCC builds happen to somehow manage to go through the -> operator call without raising any alarms, while clang builds trip on the _check_constructed() call. This fix moves the _ram_account a bit higher in class declaration to ensure its destroyed after _sliced_heap. This seems like the simpliest solution for this problem. Fixes #3941 |
||
|---|---|---|
| .. | ||
| etc | ||
| include | ||
| lib | ||
| mk | ||
| ports | ||
| recipes | ||
| run | ||
| src | ||
| xsd | ||
| README | ||
This is generic part of the Genode implementation. It consists of two parts: :_Core_: is the ultimate root of the Genode application tree and provides abstractions for the lowest-level hardware resources such as RAM, ROM, CPU, and generic device access. All generic parts of Core can be found here - for system-specific implementations refer to the appropriate 'base-<system>' directory. :_Base libraries and protocols_: that are used by each Genode component to interact with other components. This is the glue that holds everything together. _Core_ may export information about the hardware platform by an ROM called 'platform_info'. Depending on the platform, e.g. ARM or x86 or riscv, and depending on the boot mode and boot loader and kernel, some nodes may not be populated. !<platform_info> ! <acpi revision="2" rsdt="0x1fe93074" xsdt="0x1fe930e8"/> ! <boot> ! <framebuffer phys="0x7300000" width="1024" height="768" bpp="32"/> ! </boot> !</platform_info> If the ACPI RSDT and XSDT physical pointer is reported by the used kernel and/or bootloader, _Core_ may provide this information by the ROM. If the graphic device is initialised and can be directly used by a framebuffer driver, _Core_ may provide the physical pointer to the framebuffer, the resolution and color depth in bits.