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

Undetected mismatch between the input type in a I/O customization rule and the corresponding StreamerInfo element's type is silently fatal.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: master
    • Fix Version/s: None
    • Component/s: I/O
    • Labels:
      None
    • Environment:

      all

      Description

      While investigating ROOT-9784 where the automatic schema evolution was broken, we had to evolve from the old type

      map<TString,ExpensiveObject*> // type by CINT actually
      

      to the current/correct type:

      map<TString,RooExpensiveObjectCache::ExpensiveObject*>
      

      Our first attempt was the 'obvious'

      #pragma read sourceClass="RooExpensiveObjectCache" targetClass="RooExpensiveObjectCache" \  
      source="map<TString,ExpensiveObject*> _map" target="_map" version=[2] \   
      code="{ _map = onfile._map; }";
      

      but the generated code did not compiled since the type map<TString,ExpensiveObject*> does not exist.

      So we updated it to

      #pragma read sourceClass="RooExpensiveObjectCache" targetClass="RooExpensiveObjectCache" \
       source="map<TString,RooExpensiveObjectCache::ExpensiveObject*> _map" target="_map" version=[2] \
       code="{ _map = onfile._map; }";
      

      This now compiled and run until it segfaulted (most often in the execution of the rule).

      The reason is that even-though the rule listed a known type with a dictionary when setting up the 'cache' space to store the input, the I/O library used the type as spelled in the on-file StreamerInfo and did not find any dictionary for it (in this case because of the bug in the automatic schema evolution but this could happens in more general cases) and thus emulated the type, here replace the map with an 'emulated' vector<pair<TString, ExpensiveObject*>> which the rule proceeded to use as a map ...

      We need to improve TStreamerInfo's handling of I/O customization rules to detect and error-out of this type of cases (and/or insures the that type used in the rule is also used/seen by the allocating TStreamerInfo).

        Attachments

          Activity

            People

            • Assignee:
              pcanal Philippe Canal
              Reporter:
              pcanal Philippe Canal
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: