Skip to content

Conversation

@erthalion
Copy link
Collaborator

There are two acknowledged exception cases, which are handled inside
falcolibs, but contain an unconditional ASSERT. One happens when reading
information about the cgroup for the process (the process can disappear
in the meantime, leaving the library failing on trying to open a
corresponding procfs entries), another one at reading information about
the process itself (the same story, the process can be already finished
at this point, leaving no procfs entries).

Both errors are valid from the design point of view, and they do not
represent any significant issue, so it doesn't make sense to throw an
ASSERT in the debug mode. Note, that there are more ASSERTS(false),
but only those two are proven to be fine to remove at the moment.

There are two acknowledged exception cases, which are handled inside
falcolibs, but contain an unconditional ASSERT. One happens when reading
information about the cgroup for the process (the process can disappear
in the meantime, leaving the library failing on trying to open a
corresponding procfs entries), another one at reading information about
the process itself (the same story, the process can be already finished
at this point, leaving no procfs entries).

Both errors are valid from the design point of view, and they do not
represent any significant issue, so it doesn't make sense to throw an
ASSERT in the debug mode. Note, that there are more `ASSERTS(false)`,
but only those two are proven to be fine to remove at the moment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant