ROOT Gui problem


I have a ROOT Gui. It is not standalone but It is in one big Cint macro file. It works as it is and does the job.
But when I just start it and immediately exit from the Gui (so it doesn’t do anything but just creating the Gui itself and exit) I get this message:

root [1] *** glibc detected *** /usr/local/src/root/bin/root.exe: free(): invalid next size (fast): 0x08520a20 ***
======= Backtrace: =========
======= Memory map: ========
08048000-0804a000 r-xp 00000000 08:08 1293904 /usr/local/src/root/bin/root.exe
0804a000-0804b000 r–p 00001000 08:08 1293904 /usr/local/src/root/bin/root.exe
0804b000-0804c000 rw-p 00002000 08:08 1293904 /usr/local/src/root/bin/root.exe
0804c000-08704000 rw-p 0804c000 00:00 0 [heap]
b5200000-b5221000 rw-p b5200000 00:00 0
b5221000-b5300000 —p b5221000 00:00 0
b5364000-b58de000 rw-p b5364000 00:00 0
b58de000-b5964000 r-xp 00000000 08:08 1490616 /usr/local/src/root/lib/
b5964000-b5966000 r–p 00085000 08:08 1490616 /usr/local/src/root/lib/
b5966000-b5967000 rw-p 00087000 08:08 1490616 /usr/local/src/root/lib/
b5967000-b5968000 rw-p b5967000 00:00 0
b5968000-b597d000 r-xp 00000000 08:08 1031846 /usr/lib/
b597d000-b597f000 rw-p 00014000 08:08 1031846 /usr/lib/
b597f000-b5981000 rw-p b597f000 00:00 0
b5981000-b5988000 r-xp 00000000 08:08 1032056 /usr/lib/
b5988000-b598a000 rw-p 00006000 08:08 1032056 /usr/lib/
b598a000-b59ad000 r-xp 00000000 08:08 1031962 /usr/lib/
b59ad000-b59af000 rw-p 00022000 08:08 1031962 /usr/lib/
b59af000-b5a00000 r-xp 00000000 08:08 1370929 /usr/lib/
b5a00000-b5a01000 r–p 00051000 08:08 1370929 /usr/lib/
b5a01000-b5a03000 rw-p 00052000 08:08 1370929 /usr/lib/
b5a03000-b5a21000 r-xp 00000000 08:08 1031703 /usr/lib/
b5a21000-b5a23000 rw-p 0001d000 08:08 1031703 /usr/lib/
b5a2c000-b5a3a000 r-xp 00000000 08:08 1426230 /usr/local/src/root/cint/include/stdfunc.dll
b5a3a000-b5a3b000 r–p 0000d000 08:08 1426230 /usr/local/src/root/cint/include/stdfunc.dll
b5a3b000-b5a3c000 rw-p 0000e000 08:08 1426230 /usr/local/src/root/cint/include/stdfunc.dll
b5a3c000-b5b2b000 r-xp 00000000 08:08 1490665 /usr/local/src/root/lib/
b5b2b000-b5b2f000 r–p 000ef000 08:08 1490665 /usr/local/src/root/lib/
b5b2f000-b5b31000 rw-p 000f3000 08:08 1490665 /usr/local/src/root/lib/
b5b31000-b5b3d000 rw-p b5b31000 00:00 0
b5b3d000-b5ce7000 r-xp 00000000 08:08 1490551 /usr/local/src/root/lib/
b5ce7000-b5cee000 r–p 001aa000 08:08 1490551 /usr/local/src/root/lib/
b5cee000-b5cf0000 rw-p 001b1000 08:08 1490551 /usr/local/src/root/lib/
b5cf0000-b5cf2000 rw-p b5cf0000 00:00 0
b5cf2000-b5de6000 r-xp 00000000 08:08 1490547 /usr/local/src/root/lib/
b5de6000-b5deb000 r–p 000f3000 08:08 1490547 /usr/local/src/root/lib/
b5deb000-b5ded000 rw-p 000f8000 08:08 1490547 /usr/local/src/root/lib/
b5ded000-b5dee000 rw-p b5ded000 00:00 0
b5dee000-b5e61000 r-xp 00000000 08:08 1490629 /usr/local/src/root/lib/
b5e61000-b5e65000 r–p 00073000 08:08 1490629 /usr/local/src/root/lib/
b5e65000-b5e66000 rw-p 00077000 08:08 1490629 /usr/local/src/root/lib/
b5e66000-b5e67000 rw-p b5e66000 00:00 0
b5e67000-b5e6b000 r-xp 00000000 08:08 1032891 /usr/lib/
b5e6b000-b5e6d000 rw-p 00003000 08:08 1032891 /usr/lib/
b5e6d000-b5e75000 r-xp 00000000 08:08 1371247 /usr/lib/

I’ve attached it. It is pretty big (~2300 lines) but I hope some expert will be able to figure
out what I’ve done incorrectly. Just run it from Root, e.g.:

root -l TestGui.C

and then go to “Event list” --> “Exit” and say “Yes” for exit. The piece of code where this exit is done is in the Bool_t TGAppMainFrame::CloseWindow() function which is at line 964.

Thanks for the help,
TestGui.C (78 KB)

Hi Balint,
Could you try to add fMain->CloseWindow() as shown there:

if (ret == kMBYes){ fMain->CloseWindow(); gApplication->Terminate(0); }

Hi Bertrand,

I did it but the result is all the same. I use:

ROOT 5.18/00 (trunk@21744, Jun 02 2008, 11:59:00 on linux)

CINT/ROOT C/C++ Interpreter version 5.16.29, Jan 08, 2008


OK, I will try to reproduce the problem and let you know.
Cheers, Bertrand.


First of all, try to compile your macro with ACLiC (.x TestGui.C+ or .L TestGui.C+) to get rid of all the errors you have in your code, and then try again, or re-post it if you want me to take a look…


Okay, there are 2 things:

  1. I am not sure I like that I have to work with Cint but somehow for the time being that’s the
    way I have to work. And why does the code works in Cint without any error messages (except at the end) which would correspond to those that I get when I compile the code…??

  2. I don’t actually run anything when this thing occurs but only the class’s constructor is called. Within the constructor nothing happens but only the Gui classes are created and some initialization is done, so from this point of view perhaps It would be a better idea to (instead of compiling the whole ~2300 lines) just create a minimal version with which I can reproduce the problem…


Hi Bertrand,

okay, I created only the minimal possible version of the Gui class (attached), removed everything which doesn’t have anything to do with the Gui itself. Now I don’t get that message, so the conclusion is that then the Gui part should be (up to the constructor) OK and it was probably the additional part (that I’ve just removed) which caused that message.

I didn’t try to compile with aclic because I thought to compile my class I would have to create a dictionary via rootcint and LinkDef.h, etc - so if I will compile it I will want to make it in that way, and not the aclic way.

Anyway, thanks,
TestGui.C (30.6 KB)

Hi Balint,

  1. CINT is more flexible than compiler! To really check the validity of your code, the best way is to compile it with ACLiC. in your case, you will see plenty of C++ errors (i.e. variable redefinition, …). So first step is to check the validity of your macro…

  2. You create more than just a GUI, and even then, bad coding may lead to crashes (as you can see) :wink:

No, as said before, just use ACLiC (at least to check the validity of your code). Just type “.x TestGui.C+” or “.L TestGui.C+”. You don’t need anything else!



indeed I had a couple of variable redefinitions, but now it (at least the GUI part) compiles and runs as a standalone (attached, including Makefile). Sorry for not using ACLIC but somehow I am more familiar with this other way of dictionary generation and compilation.

Anyway I think the variable redefinition problems should have nothing to do with that huge message (including something like “invalid next size (fast)”) that I get at the end.

Interestingly I already saw this message elsewhere too. It was a standalone application which is also written in ROOT (it is called SFrame). What I experienced there (and here too) is that this message starts to appear after I am extending a class. After a certain amount of declaration of typically pointers to ROOT objects (e.g. TH1F *, TLorentzVector *, TCanvas * etc), if I just add one more declaration then this message shows up. And it only shows up at the end of the execution - so perhaps meaning that something went wrong at the end when the memory is being deallocating, so something must have been screwed up anyway but I just can’t find what I am doing systematically wrong so that it never shows up in smaller classes (like this GUI class attached) but only when I start to extend it…

Okay, I am not c++ expert (this attached class doesn’t have any virtual functions, and exception handling, etc…)

TGAppMainFrame.tar (40 KB)