Skip to content

Issue with reading custom classes in TTree branches #1455

@gpronost

Description

@gpronost

Hello,

When trying to read a TTree with branches filled with custom classes in uproot, some branches are properly loaded while some failed with a cursor check error.
I assume it's a bug, but it may just be a limitation of uproot, I couldn't find documentation about uproot and custom classes.

You can find here the tests I did:

dummy.root.txt>

Python 3.10.14 (main, May  6 2024, 19:42:50) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import uproot
>>> uproot.__version__
'5.6.2'
>>> f = uproot.open("dummy.root")
>>> f["dummy"].keys()
['HKDummyV2.', 'HKDummyRecoV1.', 'HKDummyCollectionV2']
>>> f["dummy"]["HKDummyRecoV1."].array()
<Array [{m_vertex: {...}, ...}, ..., {...}] type='10 * HKDummyRecoV1[m_vert...'>
>>> f["dummy"]["HKDummyV2."].array()

...

uproot.deserialization.DeserializationError: while reading

    HKDummyV2 version 1 as uproot.dynamic.Model_HKDummyV2_v1 (12 bytes)
        HKDummy version 1 as uproot.dynamic.Model_HKDummy_v1 (6 bytes)
            (base): <HKObject (version 1) at 0x782477548a00>
Base classes for HKDummy: (HKObject)

expected 6 bytes but cursor moved by 8 bytes (through HKDummy)
in file dummy.root
in object /dummy;1

>>> f["dummy"]["HKDummyCollectionV2"].array(library="np")
array([<STLVector [] at 0x72ebdadd3af0>, <STLVector [] at 0x72ebdadd39a0>,
       <STLVector [] at 0x72ebdadd3340>, <STLVector [] at 0x72ebdadd39d0>,
       <STLVector [] at 0x72ebdadd3f40>, <STLVector [] at 0x72ebdadd3430>,
       <STLVector [] at 0x72ebdadd3d90>, <STLVector [] at 0x72ebdadd3df0>,
       <STLVector [] at 0x72ebdadd3eb0>, <STLVector [] at 0x72ebdadd3e80>],
      dtype=object)

The main difference between HKDummyReco and HKDummy is that HKDummyReco has some ROOT dependencies while HKDummy doesn't:

>>> f.file.show_streamers("HKDummyRecoV1")
ROOT::Math::Cartesian3D<double> (v1)
    fX: double (TStreamerBasicType)
    fY: double (TStreamerBasicType)
    fZ: double (TStreamerBasicType)

ROOT::Math::DisplacementVector3D<ROOT::Math::Cartesian3D<double>,ROOT::Math::DefaultCoordinateSystemTag> (v1)
    fCoordinates: ROOT::Math::Cartesian3D<double> (TStreamerObjectAny)

HKRecoBaseDirection (v1): HKObject (v1)
    m_direction: ROOT::Math::DisplacementVector3D<ROOT::Math::Cartesian3D<double>,ROOT::Math::DefaultCoordinateSystemTag> (TStreamerObjectAny)
    m_direction_goodness: double (TStreamerBasicType)

HKObject (v1)

HKRecoBaseVertex (v1): HKObject (v1)
    m_vertex: ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> > (TStreamerObjectAny)
    m_vertex_goodness: double (TStreamerBasicType)

HKDummyReco (v1): HKRecoBaseVertex (v1), HKRecoBaseDirection (v1)

HKDummyRecoV1 (v1): HKDummyReco (v1)

>>> f.file.show_streamers("HKDummyV2")
HKObject (v1)

HKDummy (v1): HKObject (v1)

HKDummyV2 (v1): HKDummy (v1)
    m_a: int (TStreamerBasicType)
    m_b: double (TStreamerBasicType)
    m_c: double (TStreamerBasicType)
    m_d: double (TStreamerBasicType)

HKDummyCollectionV2 is a vector of std::unique_ptr, uproot can deserialize the vector without issue but doesn't understand the std::unique_ptr, which I assume is expected.
What I assume is a bug is that reading HKDummyV2 fails whereas HKDummyRecoV1 seems to be read properly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug (unverified)The problem described would be a bug, but needs to be triaged

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions