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

RNTuple fields have unexpected 4 bytes when recent master ROOT version is used #1288

Open
giedrius2020 opened this issue Sep 16, 2024 · 0 comments
Labels
bug (unverified) The problem described would be a bug, but needs to be triaged

Comments

@giedrius2020
Copy link
Contributor

giedrius2020 commented Sep 16, 2024

Version and files:

Issue summary:

After creating RNTuple files with ROOT converter, we tried to read RNTuple files with uproot. When using ROOT_632 version, uproot could successfully read all arrays. However, when using ROOT_6_X converter, uproot could not read the file.

Issue analysis:

After trying to access keys() or RNTuple file, and error occured:

File ~/uproot5/src/uproot/source/chunk.py:452, in Chunk.get(self, start, stop, cursor, context)
    449             return self._raw_data[local_start:local_stop]
    451         else:
--> 452             raise uproot.deserialization.DeserializationError(
    453                 f"""attempting to get bytes {start}:{stop}
    454 outside expected range {self._start}:{self._stop} for this Chunk""",
    455                 self,
    456                 cursor.copy(),
    457                 context,
    458                 self._source.file_path,
    459             )

DeserializationError: attempting to get bytes 64473:1330838489
outside expected range 0:144472 for this Chunk
in file /home/cms-jovyan/my_root_files/rntuple_v7_6_0909.root

Following the trace-back, I analyzed memory differences near 64473 byte for ROOT_632 and ROOT_6_X files. Analysis results showed that files had different structure. Difference is shown in the picture below:
632 vs 6_X byte comparison

In this example, there is a moment when uproot expect to find the length of field name string ([17 0 0 0] for CorrT1METJet_area), but finds some unexpected value [69 2 0 0] and registers it as next string len instead. This break all cursor readings afterwards.

Conclusion:

Based on these results, I assume that recent ROOT_6_X version had an updated RNTuple file structure format with additional 4 bytes. Field has ROOT::VecOps::RVec type. Uproot is unable to read the file, because it expects different format. These additional 4 bytes need to be analyzed further and uproot needs to be updated to support older and recent version of RNTuple files.

@giedrius2020 giedrius2020 added the bug (unverified) The problem described would be a bug, but needs to be triaged label Sep 16, 2024
@giedrius2020 giedrius2020 changed the title RNTuple files cannot be read when created with ROOT_6_X version (different field structure) RNTuple fields have unexpected 4 bytes when ROOT_6_X version is used Sep 16, 2024
@giedrius2020 giedrius2020 changed the title RNTuple fields have unexpected 4 bytes when ROOT_6_X version is used RNTuple fields have unexpected 4 bytes when recent master ROOT version is used Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug (unverified) The problem described would be a bug, but needs to be triaged
Projects
None yet
Development

No branches or pull requests

1 participant