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

Check for missing fields #18

Open
MatthieuSchaller opened this issue Sep 4, 2018 · 0 comments
Open

Check for missing fields #18

MatthieuSchaller opened this issue Sep 4, 2018 · 0 comments

Comments

@MatthieuSchaller
Copy link
Collaborator

MatthieuSchaller commented Sep 4, 2018

When running VELOCIraptor on a HDF5 snapshot (SWIFT in this case) and a field is missing (e.g. the masses), the code throws an exception while reading:

terminate called after throwing an instance of 'H5::GroupIException'

This exception is not caught and the code does not die cleanly, leaving nasty things behind on the compute node.

I'd recommend catching these HDF exceptions and cleaning up before escaping.

It may also be worth checking whether the fields exist before attempting to read it as this would prevent this exception altogether whilst also crashing at the very start before having read some of the fields that actually exist.

jchelly pushed a commit to jchelly/VELOCIraptor-STF that referenced this issue Oct 1, 2020
The different functions calculating accumulated metrics over the extra
gas/star/bh properties shared a common signature (made explicitly by the
ExtraPropFunc typedef) signaling that a double value should be returned.
However, in reality none of these functions performed a return. This in
seems to have contributed to the introduction of UB, resulting in
hard-to-debug errors.

This commit modifies the ExtraPropFunc typedef to indicate that
functions adjusting to this type don't need to return a double, and
should return void instead. The signature of all the functions that are
used through this typedef are then adjusted to reflect this change.

Although it looks unrelated, this patch fixes the problem described in
issue pelahi#18. This is consistent with the fact that the problem surfaced
only after certain optimization levels were introduced, and with some of
debugging information shown by gdb (although at the time it wasn't
obvious what the problem was).

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
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

No branches or pull requests

1 participant