Questions regarding Issue #4323
norman.feske at genode-labs.com
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  and opened the
separate issue #4323  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 ). 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  along the way. To get
inspiration for potential topics to work on, you may find the
"Challenges" page  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
Genodians.org  to get a tangible feeling about current topics of
Dr.-Ing. Norman Feske
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users