Questions regarding Issue #4323

Norman Feske norman.feske at
Mon Nov 15 11:29:07 CET 2021


welcome Costinteo to the mailing list, and thanks Cedric for commenting
on the question!

> Costinteo wrote:
> I saw Issue #4323, regarding a possible memory
> leak. To my understanding, this would be a very easy fix, just 
> free the void pointer that was allocated. Is that enough?

Your understanding is right.

The issue is indeed rather marginal and simple to fix. In practice, I
have not witnessed a failure of map local. However, I spotted this
potential problem while working on issue #4324 [1] and opened the
separate issue #4323 [2] as a matter of hygiene instead of silently
fixing it as I went. But there is also the broader observation, outlined


> Cedrik wrote:
> [...] are there similar unspotted problems elsewhere in the code,
> can it be solved with RAII instead of manual freeing [...]

I think that issue #4323 highlights a fragile programming pattern of
manually rolling back operations in the error case. So Cedrik's
mentioning of RAII as an alternative is spot-on.

When reviewing the core code related to 'map_local' - especially when
looking at more than one base platform - one can observe the repeated
sequence of allocating a physical range, allocating a virtual range,
installing the mapping, accessing the mapped memory, unmapping, and
releasing the virtual range. The manual repetition of this sequence
ought better be replaced by a single implementation (using a lambda
function for accessing the content similar to [3]). Once when going
forward with implementing this general improvement, one can conveniently
reference issue #4323 as the underlying motivation. ;-)


> How should I go about helping with this? Search for such spots and
> add a deallocation for each I find, then create a pull request?

Reports about potential bugs are highly appreciated. Should you
encounter code that raises your eyebrows, please bring it up. So we can
either explain why it looks the way it is (and likely comment the code)
or improve/fix it.

I'd not rush issuing pull requests to Genode's main repository in the
beginning. To get familiar with the project and the community, it is
certainly best to pursue a custom project of your genuine research
interests, maybe contributing to genode-world [4] along the way. To get
inspiration for potential topics to work on, you may find the
"Challenges" page [5] insightful. Note that some of these topics are
already being worked on. To coordinate, please don't hesitate to post
your plans to this mailing list.

You may also have a look at the recently published articles at [6] to get a tangible feeling about current topics of



Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list