Uploaded image for project: 'ROOT'
  1. ROOT
  2. ROOT-7500

uint64_t streaming in derived class across Mac/linux broken since v5.34/19

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 6.00.00, 6.00.01, 6.00.02, 6.02.00, 6.04.00, 6.02/01, 6.02/02, 5.34/24, 6.02/03, 5.34/25, 6.02/04, 5.34/26, 6.02/05, 6.02/08, 5.34/28, 5.34/30, 6.02/10, 6.02/12, 6.04/02, 5.34/32
    • Fix Version/s: None
    • Component/s: I/O
    • Labels:
      None
    • Environment:

      Linux and Mac

      Description

      We have software deployed on a linux cluster (PDSF at NERSC running Scientific Linux 6.4) and many users with Mac laptops. We found that our analysis files created on linux could not be opened on Macs, and vice versa: if we loaded our software libraries, root would crash as soon as we tried to call TFile::Open().

      We narrowed the problem down to a couple of classes, which we noticed were all classes that used uint64_t in a base class. So I constructed a test case that eliminates any of our complicated code, and sure enough, it crashes in the same way.

      So it appears is that streaming is broken across platforms for classes that have a base class with a uint64_t data member. Please see the attached code and their associated Makefiles on their respective systems. The macro fileError.C, when run on linux, creates a file that contains a tree with a branch "fI" that tree->Print() says is a ULong_t, and the file can't be opened on a Mac if libMyLib.so is loaded first. When run on mac, the macro creates a file that contains a tree with also with a branch "fI", but this time tree->Print() says it is a ULong64_t, and the file can't be opened on linux if libMyLib.so is loaded first.

      Interestingly, if the tree is filled with the base class instead of the derived class, the file opens just fine! However, fI is still given the different type (ULong_t vs ULong64_t) on the two different systems.

      We did extensive testing to see when this problem started, and it occurs in root6 as well as in root_v5.34/19 and subsequent patches.

      Please help! This is a big problem for us, and means that we have to fix it and reprocess all of our data before our disks fill up with data coming in.

        Attachments

          Activity

            People

            • Assignee:
              pcanal Philippe Canal
              Reporter:
              c6fd1bdce1febe5322c3 Jason Detwiler
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: