Migrating GUI Elements from ROOT5 to ROOT6


Please read tips for efficient and successful posting and posting code

Please fill also the fields below. Note that root -b -q will tell you this info, and starting from 6.28/06 upwards, you can call .forum bug from the ROOT prompt to pre-populate a topic.

ROOT Version: 6.32.02
Platform: Debian Linux 6.10
Compiler: g++ 12.2

Hi, I am currently trying to migrate a set of codes my collaboration has been using for a long time from ROOT5 to ROOT6. If I compile the codes in ROOT 5.34/38, everything runs flawlessly, as it ever did. If I try ROOT 6.32.02, however, several different elements of the GUI are broken. The codes are a TApplication with a user interface for browsing detector signals, and for ROOT6 compilation I cannot use zoom on TPads. Furthermore, the GUI uses some colored markers, which disappear when clicked on after ROOT6 compilation. Lastly, after browsing several signals, the program segfaults with

free(): invalid next size (fast)

which never happens in ROOT5 compilation. I have tried troubleshooting the segfault part of it myself in hopes that it would lead me to other problems, but I could not find the issue. I have tried using Valgrind 3.19 with root-suppression, but itā€™s that annoying case where the crash disappears in Valgrind. I have also tried using GDB 13.1, but as often happens with segfaults, I get a different crash everytime, so GDB backtrace did not yield anything useful.

I did not post any sample codes here because the code is rather large, and the GDB-identified source of the segfault drifts around (as stray pointers do). Moreover, since I would like to restore graphical functionality (like zooming), I was not sure which of the many parts of the code could have changed behaviour between ROOT versions to cause it.

I tried reading ROOT versioning history of ROOT6 for hints, but also didnt identify anything obvious. I would appreciate any hints on what sort of graphical changes occurred between the two ROOT versions I try that in your experience could result in such behaviour, and then I can try to troubleshoot it from there. I can post corresponding snippets of the code as well for anything you would expect to go astray based on the description of the problem. Thanks in advance for any help!


Hi @NSos, welcome back to the forum. Iā€™m not an expert on graphics.

I will add our graphics expert @couet in the loop, but heā€™s on vacation this week.

I know you mentioned that the code is rather large, but would it be possible for you to submit small snippets of code or the logs? This would make it easier for us to pinpoint exactly where the problem is.

1 Like

Thatā€™s brilliant, thanks! I will wait for him to get back then.

Here is a link to the code stored on my Dropbox. The code is not self-sufficient, so it probably wonā€™t compile (and anyhow, it would require signal data file inputs to run), but it will perhaps be sufficient to get the idea of what we are doing.

One more thing, based on GDB backtrace, crashes seem to often cluster around line 1658, where TCanvas objects are cleared. I have tried tracking their behaviour through the code, but it seems fine to my unprofessional eye (and again, it works fine in ROOT5!). And also, itā€™s not just the crash, but also GUI not behaving correctly that I would like to fix, and I doubt itā€™s TCanvas clearing that causes zooming to malfunction (although with memory allocation problems, who knowsā€¦).

Letā€™s split the problems and face them one by one.

I would suggest that you create a simple example containing just one TPad, where zoom works on ROOT5 but not on ROOT6. It should be a self-contained snippet of code.

Then, a separate one where the colored marker disappear.

For the segfault, two options:

  • I tried your dropbox link, but it is missing gui.h, PSADetector.h etc. so I cannot debug myself. If you add the rest of the files, I can try to help.
  • Debug yourself with a ROOT version built from source in ā€˜debugā€™ mode, not in ā€˜release modeā€™, which is the usual one when you download from binary.
1 Like

Hi, thanks for having a look. Thanks also for the offer of having a read, but there are other dependencies, which involve my collaborationā€™s analysis codes, which I am hesitant to share publicly. I also have simply inherited this code, so I was planning on making test codes only as a last resort, as that would involve a lot of digging through whatā€™s already there.

A debug mode is a great idea though, thanks! I did not realize that ROOT offers such functonality. My ROOT is installed from source, so I will recompile it. Would I simpy need to set compilation flag CMAKE_BUILD_TYPE=ā€œDebugā€? Or is there more to it?

In coming to these forums, I mostly hoped to check whether there are some known major graphical changes between the versions, which have previously compromised functionality like zooming, so that I could use that as guides for debugging myself.

Yes, thatā€™s it.

You can also use an IDE to help yourself, see eg: Coding in ROOT with the horsepower of an F1 - ROOT

1 Like

Brilliant, thanks! I will give this a try, and will post a solution if I find it. In the meanwhile, if anyone on the team happens to remember some similar issues cropping up previously, I would still appreciate any hints.

You could remove those files and comment out the part of the code that uses those classes from within the mainwindow.

I donā€™t think there is any change in zooming between 5 and 6. But as said, try to create a minimal reproducer script with a TPad to facilitate giving you more help.

Another option would be to check the release notes.
For example, in 6.04: It was possible to interactively zoom outside the histogramsā€™ limits. Protections have been added.

1 Like

@ferhue has looked at the issues I listed here via direct messages, and two main problems were identified. Firstly, functions that return pointers to objects like TMultiGraph had if/else clauses, which provided correct returns, but the end of the function itself had no return NULL;. After adding this, segfaults went away.

Secondly, axes were initialized with huge limits like 1e100. While I am unsure why this changes behaviour between ROOT versions, changing all instances of this to 1e4 has fixed axis behaviour.

Thanks again for huge help, @ferhue! Issue solved.

That doesnā€™t sound correct, if the if-else had returns already, adding something at the end should not change anything, as it should be unreachable.

I believe the other problem with the crash/leak might be with calling gDirectory->Delete(ā€œnameā€)
as the name of TGraphs were not being initialized, they had all the same name, so nasty things could happen. So giving each TGraph a distinct name via SetName might prevent this. Or maybe itā€™s something different and it only happens from time to time due to a different reason.

Hmm, that was my initial reaction, but then after adding that and changing those unsurprsingly-problematic large numbers, the code works properly. Previously it was essentially guaranteed to crash at several points, and now I have been looking at graphs for an hour, and no problems.

I have also added the SetName() functions for every instance of a declaration of a TGraph*, TMultiGraph* or TH1F* in a function, but that hasnā€™t changed anything. It makes sense to me as a good practice though, so I will keep it there.

Either way, changing colossal numbers to more sensible ones definitely made a difference!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.