Hello, I'm a final year CS B.S. student. I was looking for an interesting project / thesis for my Bachelor and my professor suggested I take a look into Genode (besides other things). I find the project fascinating, even though I don't nearly possess enough information to fully understand it. Browsing through the issue tracker, 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? I've also found one other place (and there could be more) where this happens again. The same idea -> allocated memory that doesn't get deallocated if the mapping fails. 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?
Thanks in advance, Costinteo
Hello,
I'm a final year CS B.S. student. I was looking for an interesting project / thesis for my Bachelor and my professor suggested I take a look into Genode (besides other things). I find the project fascinating, even though I don't nearly possess enough information to fully understand it. Browsing through the issue tracker, 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? I've also found one other place (and there could be more) where this happens again. The same idea -> allocated memory that doesn't get deallocated if the mapping fails.
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?
I'm not familiar with the code in base/core/, but from a cursory look it might be possible that this is simply in need of changing the subsequent line
if (!map_local())....
to also free the range before doing "return nullptr", as you said ; but from what I've seen of the Genode team, and Norman, if they filed a ticket instead of just doing the fix it could mean there are other intricacies involved ; or that they want to consider all aspects (like, are there similar unspotted problems elsewhere in the code, can it be solved with RAII instead of manual freeing, etc) before commiting the fix.
I'm guessing you ought to post to the ticket before crafting the pull request, or anyway that's how I've seen it done before (no experience with PR myself).
No matter what, I hope you give the Genode framework a test drive, and who knows, maybe settle in the Genode community. In my experience, open-source projects mainly lack developers ; they rarely lack in manpower for doc writers, localization, evangelism and so on, but mainly in the coding department.So if you know C++, I feel very much we should encourage you to contribute :-) Maybe to the "genode-world" repo, if it turns out to be more easy to reach than Genode "core" initially.
Or maybe even to community projects, as listed in J's page here : http://www.alternateapproach.com/Computing/Genode/Genode_Corner/
Though I suppose it might be going too far off target, i.e. your professor would rather you contribute to "core" Genode, which makes sense.
Cedric
Hello,
welcome Costinteo to the mailing list, and thanks Cedric for commenting on the question!
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 below.
[1] https://github.com/genodelabs/genode/issues/4324 [2] https://github.com/genodelabs/genode/issues/4323
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. ;-)
[3] https://github.com/nfeske/genode/commit/d65820a8326c77865d53887ce552c9f0c94b...
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 Genodians.org [6] to get a tangible feeling about current topics of interest.
[4] https://github.com/genodelabs/genode-world/ [5] https://genode.org/about/challenges [6] https://genodians.org
Cheers Norman
There are lots of things to work on. For example, the current AHCI driver doesn't work on AMD hardware that I have tried it on. To be clear, I've tried to solve this, but haven't succeeded yet. I have other stuff to work on for school and personal projects, so I'm not sure when I might get around to trying to solve it again.
Is there a place to put these? There are open issues, but lots of issues have been closed simply because people stopped working on them. It seems like a good idea to have a place that lists all the tasks that would be appreciated if someone were to pick them up, with links to the corresponding GitHub issues.
On Mon, Nov 15, 2021, 3:29 AM Norman Feske norman.feske@genode-labs.com wrote:
De : Nobody III hungryninja101@gmail.com
There are lots of things to work on. For example, the current AHCI driver doesn't work on AMD hardware that I have tried it on. To be clear, I've tried to solve this, but haven't succeeded yet. I have other stuff to work on for school and personal projects, so I'm not sure when I might get around to trying to solve it again.
Is there a place to put these? There are open issues, but lots of issues have been closed simply because people stopped working on them. It seems like a good idea to have a place that lists all the tasks that would be appreciated if someone were to pick them up, with links to the corresponding GitHub issues.
I could suggest my 'ttcoder' repository hosted by the chiselapp.com service as a place for community members to use (i.e. its integrated wiki, integrated ticketing system etc) though I'm skeptical it would bring value over the github ecosystem and Genode's github repo, even if users overcame the "barrier to entry" inherent in switching over from git to fossil SCM ; most likely, instead of being complementary it would fragment bug listings and make it more complicated to track issues in two differents places. I'm not hostile to the idea though, maybe my concerns will be proven to be wrong :-)
Initially I wouldn't have much time or energy to contribute to administration/management efforts, since I have been and remain in "crunch time" until my software is ported to Genode...
Cedric
-
Costin Grigore -
Nobody III -
Norman Feske -
ttcoder＠netcourrier.com