Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add exception handling in mountinfo enumeration path #1515

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

atcuno
Copy link
Contributor

@atcuno atcuno commented Jan 3, 2025

The lack of exception handling caused backtraces in many samples in mass testing.

@atcuno atcuno requested a review from ikelos January 3, 2025 18:57
# invalid superblocks being return
# mnt_parent can also smear so we check both
try:
parent_id: int = mnt.mnt_parent.mnt_id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mnt_parent is a pointer.. this should be:

if not (mnt.mnt_parent and mnt.mnt_parent.is_readable()):
    return None

Same thing for superblock:

    def get_mnt_sb(self) -> int:
        """Returns a pointer to the super_block"""

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would generally err towards testing before accepting (especially if there's gonna be extra code required either way). I've tried in this project to be a little happier about exception handling, although ideally they'd only occur in exceptional circumstances not expected ones. The good part about exception handling is that the try/catch can cover much larger chunks of code regardless of what exactly the issue was, so I'm trying to encourage try/except blocks that cover as much as could go wrong if something were to go wrong (but no more than that) so usually the body of a loop for instance, or something of that nature.

I'm gonna leave you two to figure out what's best ask permission/seek forgiveness, once you come to a consensus let me know, at the moment either one seems ok to me unless someone presents an argument as to why one is better or actively detrimental...

Copy link
Member

@ikelos ikelos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks ok to me, but I'll leave @atcuno and @gcmoreira to come to a compromise they're both happy with and then go with that...

# invalid superblocks being return
# mnt_parent can also smear so we check both
try:
parent_id: int = mnt.mnt_parent.mnt_id
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would generally err towards testing before accepting (especially if there's gonna be extra code required either way). I've tried in this project to be a little happier about exception handling, although ideally they'd only occur in exceptional circumstances not expected ones. The good part about exception handling is that the try/catch can cover much larger chunks of code regardless of what exactly the issue was, so I'm trying to encourage try/except blocks that cover as much as could go wrong if something were to go wrong (but no more than that) so usually the body of a loop for instance, or something of that nature.

I'm gonna leave you two to figure out what's best ask permission/seek forgiveness, once you come to a consensus let me know, at the moment either one seems ok to me unless someone presents an argument as to why one is better or actively detrimental...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants