Project

General

Profile

Bug #7076

LArSoft v03_00_00 unable to read recob::Wire from MicroBooNE MCC 5 files

Added by Gianluca Petrillo about 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
Other
Target version:
-
Start date:
09/26/2014
Due date:
% Done:

100%

Estimated time:
Occurs In:
Experiment:
MicroBooNE
Co-Assignees:
Duration:

Description

Tracy Usher signals that the evend display crashes when trying to read recob::Wire objects from the caldata product.

Steps to reproduce:
  1. open an event display on a file with reconstructed information (Reco2D phase or later). E.g. a copy of /uboone/data/users/petrillo/LArSoft/develop/e6_prof/input/ana/bnb_nu_cosmic/prodgenie_bnb_nu_cosmic_uboone_53048_6_gen_53056_6_g4_75611_6_detsim_75619_6_reco2D_75679_6_reco3D_75707_6_merged.root
  2. ask for "reconstructed" data

The event display crashes with a segmentation fault while trying to read information to fill the lower (wire) histogram, while executing art::Event::getByLabel("caldata", wcol); in RecoBaseDrawer::GetWires() (lareventdisplay/EventDisplay/RecoBaseDrawer.cxx line 1979).
The crash does not manifest in LArSoft v02_06_02.
Processing files with recob::Wire created in v03_00_00 does not show any issue.

History

#1 Updated by Gianluca Petrillo about 5 years ago

  • Priority changed from Normal to High

Confirmed by running only GausHitFinder module, that uses the same recob::Wire branch as input.

#2 Updated by Gianluca Petrillo about 5 years ago

The following analysis show where the problem happens.

The run crashes while trying to read a member ranges of recob::Wire.

That member is of type lar::sparse_vector<float>::datarange_t, roughly declared as:

template <typename SIZE>
class range_t {
  SIZE offset, last;
};

class datarange_t: public range_t<unsigned long> {
  std::vector<float> values;
};

In TStreamerInfo::ReadBuffer(), within the streamer info of lar::sparse_vector<float>::datarange_t, on line 1355, aElement is the streamer info for lar::range_t<unsigned long>; when calling TStreamerBase::GetBaseStreamerInfo(), aElement returns a null pointer.

This code was changed from the previous ROOT version:

ROOT 5.34/18, root/io/io/src/TStreamerInfoReadBuffer.cxx line 1400:

       case TStreamerInfo::kBase:
          if (!(arrayMode&1)) {
             if(pstreamer)  {kase = TStreamerInfo::kStreamer; goto SWIT;}
             DOLOOP { ((TStreamerBase*)aElement)->ReadBuffer(b,arr[k]);}
          } else {
             // FIXME: what is that?
             Int_t clversion = ((TStreamerBase*)aElement)->GetBaseVersion();
             TStreamerInfo *binfo = ((TStreamerInfo*)cle->GetStreamerInfo(clversion));
             if (!binfo->TestBit(kCannotOptimize) && binfo->IsCompiled()) { 
                binfo->SetBit(kCannotOptimize);
                binfo->Compile();
             }
             binfo->ReadBuffer(b,arr,-1,narr,ioffset,arrayMode);
          }
          continue;

ROOT 5.34/21, root/io/io/src/TStreamerInfoReadBuffer.cxx line 1346:

       case TStreamerInfo::kBase:
          if (!(arrayMode&1)) {
             if(pstreamer)  {kase = TStreamerInfo::kStreamer; goto SWIT;}
             DOLOOP { ((TStreamerBase*)aElement)->ReadBuffer(b,arr[k]);}
          } else {
             // FIXME: Rather than relying on the StreamerElement to
             // contain the base class version information we should
             // embed it in the bytestream even in the member-wise case.
             // For now rely, on the StreamerElement:
             TStreamerInfo *binfo = ((TStreamerInfo*)((TStreamerBase*)aElement)->GetBaseStreamerInfo());
             binfo->ReadBuffer(b,arr,binfo->fCompFull,0,binfo->fNfulldata,narr,ioffset,arrayMode);
          }

There is a new method of getting the streamer (binfo) of the base class.
Both methods seem self-consistent, but they seem incompatible with each other and the latter code on data crated with the former returns binfo = 0.

#3 Updated by Gianluca Petrillo about 5 years ago

The change in ROOT is commit 5a5ac2c50c0a8487d046a2b493c87572ae92b2f0 by Philippe Canal.

#4 Updated by Gianluca Petrillo about 5 years ago

  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo

The bug has been reported to ROOT tracker as ROOT-6765.

#5 Updated by Gianluca Petrillo about 5 years ago

  • Priority changed from High to Immediate

Priority increased due to the relevance for MicroBooNE experiment.

#6 Updated by Philippe Canal about 5 years ago

Hi,

The problem has been resolved in the v5.34/00 and v6.02/00 patch branch as well as the master of the ROOT source code.

Cheers,
Philippe

#7 Updated by Gianluca Petrillo about 5 years ago

Lynn Garren has extracted the patch and applied it to our ROOT.
I have run a test using that patched ROOT (v5_34_21b).
The problem seems to be solved: wire data from large MCC5 (LArSoft 2.5.1) files is correctly displayed in the event display.

For the record, Philippe Canal has reported that the issue should show only on large files (> 2 GB).

#8 Updated by Lynn Garren about 5 years ago

  • Status changed from Assigned to Resolved
  • Assignee changed from Gianluca Petrillo to Lynn Garren
  • % Done changed from 0 to 100

larsoft v03_02_00 has been tagged, built, and installed on /grid/fermiapp/products/larsoft. This release includes root v5_34_21b with the patch supplied by Philippe Canal.

#9 Updated by Lynn Garren almost 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF