[ROOT-5483] Custom converter broken in v5-34-10 and up Created: 08/Sep/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

Status: Closed
Project: ROOT
Component/s: I/O
Affects Version/s: 5.34/00
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Attila Krasznahorkay Assignee: Philippe Canal
Resolution: Fixed Votes: 0
Labels: None

SLC6, GCC 4.7, but got the same results on MacOS X 10.8 as well.

Attachments: File converterIssue.tar.gz    


Hi Philippe,

It seems that some new issue crept into v5-34-00-patches not too long ago. One of the custom converters that the ATLAS TF1 demonstrator code uses is not functional with v5-34-10 or v5-34-00-patches. But it works fine with v5-34-09. The custom converters are not broken on principle, I needed to extract the exact class from our code to demonstrate the issue. (Wasn't able to create the issue with much simpler classes.)

Attached is a code demonstrating the issue. fileWriter.cxx creates a branch using EventFormat_p1, and fileReader.cxx tries to read it back using edm::EventFormat. When compiling the code against v5-34-09, I get the output that I expect:

> ./fileReader
Info in <fileReader>: Opened the input file
Info in <fileReader>: Input tree accessed
1. element: Branch name: Test1, Class name: Bla1, Hash: 0x00000001
2. element: Branch name: Test2, Class name: Bla2, Hash: 0x00000002

But when I compile the code against v5-34-10 (or the head of the patch branch), the last two lines are not printed. I only looked at the converter a bit closer, it's obvious that my user code is never called for the conversion. But I have no idea why.

Custom converters are of course very central to the ATLAS developments, this is why I gave the issue such a serious priority. (As the EDM demonstrator is not functional with this latest ROOT version...)


Comment by Philippe Canal [ 17/Sep/13 ]

Hi Attila,

Thanks for reporting this issue (Properly call an I/O rule that applies to a whole object that is split). It has been fixed in the trunk and in the v5-34 patch branch.


Generated at Tue Aug 11 06:39:29 CEST 2020 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.