we have a problem with our ROOT-based GUI since we upgraded from 5.26.00 to 5.28.00. The problem also persists in the current stable version 5.30.00. We post a picture of the GUI so that you can understand easier what we ran into:
We created our own class SCanvas that inherits directly from TCanvas. The problem is now when we try to load graphics to the large window on the right, based on an external output file, the program stops running. There is no crash and hence no backtrace that we could evaluate. We pinned the problem down to the point where we update the SCanvas. In the function SCanvas::Update we call TCanvas::Update() which leads the program to stop. We also copied the content of TCanvas::Update into our function and found out that the program stops when calling TCanvas::PaintModified. To find more details about our problem, we disabled the painting of all the object that we paint ourselves into the canvas on the right, still the stop of the running program persists.
It would be nice if someone could give us a hint what might have been updated between the releases. We could not find anything obvious in the release notes. As the problem only arises in this more complex program, it is rather not directoly possible to present a minimum example for you to run. Of course we can provide the code or parts of it.
I tried to find cross-relations between the PaintModified and possible functions which are called before. I was able to reduce the functionality of the program until it worked again.
Before the Canvas-Update events are read from a root file to display some hit and track information in the pad. But even if I do not handle the event already the line fEventTree->GetEntry(); causes some trouble in the update. (The Tree and the content seems to be fine)
I do not really see a connection between the tree handling and pad update…
It would be great to get some idea what could cause this, or how to pin down the problem further!
As a next step I recommend that you run the failing example with valgrind and then us the resulting information.
thanks for getting back to us. I ran valgrind with memcheck and callgrind but it didn’t really show me any information on why the programs halts. The problem is certainly that there is no real crash. ROOT just jumps to 100% processor consumption and stays there. We get no real crash, so no backtrace of any sort. If I remove the offending line of course the TCanvas update doesn’t happen any more. Valgrind in this case reacts all find and finds no memory leaks whatsoever. Maybe a list of ROOT objects just before would help you? Any hints? I will try to apply a debugger if I find more time.
If the problem is that the CPU is unexpectedly 100% utilized (for a long time), one of the way to debug this is to start the example in a debugger, wait until the process is in the unexpected state, hit CTRL+C and see what is the stack trace at the time, continue a bit longer, see where the stack trace now is … and somehow infer where is the infinite loop(ing).
PS. Alternatively, if you are able to provide a complete running example that reproduce the problem we can try to take a look.
for now I produced at least a call trace. Probably not telling you too much but maybe something catches your interest. I will ask our admin if he can provide a ROOT version compiled in debug mode so that I can have a deeper look and maybe identify where it hangs.
SCanvas is our class and the Update() function calls PaintModified() from TPad. SCanvas inherits directly from TCanvas.
39 ft_mem_qrealloc() 0xb53eef8b
38 ft_mem_realloc() 0xb53ef7af
37 FT_Outline_New_Internal() 0xb53efa46
36 FT_Outline_New() 0xb53efb3d
34 FT_Get_Glyph() 0xb53f5041
33 TTF::LayoutGlyphs() 0xb6a829ec
32 TTF::GetTextExtent() 0xb6a8356a
31 TText::GetTextExtent(unsigned int&, unsigned int&, char const*) const() 0xb6a8052e
30 TPaveLabel::PaintPaveLabel() 0xb6a67545
29 TPaveLabel::Paint() 0xb6a67010
28 TPad::PaintModified() 0xb6841e48
27 SCanvas::Update() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SCanvas.cxx:230 0xb57a229a
[quote]I will ask our admin if he can provide a ROOT version compiled in debug mode so that I can have a deeper look and maybe identify where it hangs.[/quote]yes, this would be best … also it would interesting to see where/how the call are being repeated and what is slightly higher in the stack trace (i.e. level 26 and lower).
thanks for your quick answer. As far as I can see it’s really stuck in the TTF::LayoutGlyphs(). It’s address stays the same over hours. The only changes I see when I continue to run is from there upwards (35++). The rest of the call stack is here:
26 SClient::SetState() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:1587 0xb57a384c
25 SClient::HandleEvtList() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:1012 0xb57ae926
24 SClient::UpdateEvtList() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:969 0xb57af0ff
23 SClient::OpenEvtFile() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:898 0xb57af833
22 SClient::CreateMCFile() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:1260 0xb57afbee
21 SClient::HandleTabFunctions() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/src/SClient.cxx:1143 0xb57b1a22
20 G__SClientDict_305_0_23() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/libSClient/dict/SClientDict.cxx:377 0xb57bdb4e
19 Cint::G__CallFunc::Execute() 0xb7329b32
18 TCint::CallFunc_Exec(void*, void*) const() 0xb7a5c7fb
17 TQConnection::ExecuteMethod() 0xb79e8ead
16 TQObject::Emit() 0xb79ef81e
15 TGButton::Clicked() 0xb599fcca
14 TGButton::EmitSignals() 0xb5990964
13 TGButton::SetState() 0xb5990846
12 TGButton::HandleButton() 0xb5992e53
11 TGFrame::HandleEvent() 0xb59f032a
10 TGClient::HandleEvent() 0xb59af25d
9 TGClient::ProcessOneEvent() 0xb59afc8c
8 TGClient::HandleInput() 0xb59afcfd
7 TGInputHandler::Notify() 0xb59afd30
6 TUnixSystem::DispatchOneEvent() 0xb7aa225f
5 TSystem::InnerLoop() 0xb7a110a1
4 TSystem::Run() 0xb7a13ebb
3 TApplication::Run() 0xb79a4a17
2 TRint::Run() 0xb65d8c30
1 main() /afs/atlass01.physik.uni-bonn.de/user/stillings/STYX/STYXEvent/styx.cxx:30 0x08049db6
The recent fix I did in TPaveLabel might also fix your problem:
There was an infinite loop the under some conditions.
Thanks a lot! That seems to have fixed our problem. I used
ROOT 5.31/01 trunk@41068
and the hang disappeared. Thanks for all the support
Any idea when this is going to a production version?
[quote=“couet”]The recent fix I did in TPaveLabel might also fix your problem:
There was an infinite loop the under some conditions.[/quote]