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

Is passing NULL to Node::set_external valid behavior? #1219

Open
BradWhitlock opened this issue Dec 22, 2023 · 4 comments
Open

Is passing NULL to Node::set_external valid behavior? #1219

BradWhitlock opened this issue Dec 22, 2023 · 4 comments

Comments

@BradWhitlock
Copy link
Member

I am debugging some code in which a host code exposes some of its internal data as a Blueprint tree of data. The code makes a topology and some fields. Some of the fields were apparently allocated later. At the time the Blueprint fields are created, some of the arrays are NULL and the host makes nodes anyway and calls set_external(), passing NULL pointers! Back in my library, I get the host code's node (which contains some NULLs) and I passed this node to conduit::relay::io::save() to save a conduit_json representation of the host code's mesh and fields. This causes relay to die because some of the external nodes are NULL.

  1. I think Node::set_external(T*, len) should have immediately thrown an exception when given a NULL pointer.
  2. The conduit_json method in relay should have scanned its input nodes and thrown when it found an external node with NULL data.
  3. Various verify() methods should flag this case as invalid

This was hard to track down and it was all because the host code was sloppy about how it made the Blueprint mesh.

@cyrush
Copy link
Member

cyrush commented Dec 22, 2023

@BradWhitlock sorry this caused you frustration.

I don't recommend it, but I think there are folks that will want to use NULL w/ set external.

I agree that blueprint verify should flag invalid if pointers are NULL, and that the to_string methods (json / yaml) should error instead of crashing if they encounter null pointers.

@BradWhitlock
Copy link
Member Author

I can possibly see allowing NULL to act as a placeholder for data that is not created yet. Still, it makes a Blueprint tree that is not valid and cannot be used with relay, partitioning, or other algorithms that do not expect to get NULL data in field values. It's easier just to not allow in the first place.

@rhornung67
Copy link
Member

rhornung67 commented Dec 22, 2023

@cyrush don't we do this sort of thing (set up a BP tree with null external data ptrs) in Sidre when we read in a restart dump for a Fortran code, for example? IIRC, the BP tree is defined first, then Fortran app allocates the data arrays, then Conduit reads the data into those arrays from an HDF5 file.

@BradWhitlock maybe still allow this process, but don't allow using relay, etc. on an invalid BP tree?

@cyrush
Copy link
Member

cyrush commented Dec 22, 2023

@rhornung67 yes, that is a case I was thinking about.

I don't know the exact order of the steps, we may not use NULLs, but that type of case is one where if folks are careful it makes sense for this to be allowed.

Error checking for null in verify and in other places is something we should add.

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

3 participants