Error when closing dialogbox

Dear Rooters

Currently, I am testing my GUI Application and got the following irreproducible error:
When closing a dialogbox I got a “bus error” but could continue working
with my program w/o any problems. I could even open/close the dlogbox again w/o the error.
The crash reporter on my Mac gives the following crashlog:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x0d028004

Thread 0 Crashed:
0   <<00000000>> 	0x0d028004 0 + 218267652
1   libGui.dylib  	0x038aadb0 TGClient::HandleMaskEvent(Event_t*, unsigned long) + 144 (icplusplus.c:28)
2   libGui.dylib  	0x038ab210 TGClient::ProcessOneEvent() + 152 (icplusplus.c:28)
3   libGui.dylib  	0x038ab2b4 TGClient::HandleInput() + 32 (icplusplus.c:28)
4   libCore.dylib 	0x02129fc8 TUnixSystem::DispatchOneEvent(bool) + 104 (icplusplus.c:28)
5   libCore.dylib 	0x02084bd0 TSystem::InnerLoop() + 52 (icplusplus.c:28)
6   libGui.dylib  	0x038ab610 TGClient::WaitFor(TGWindow*) + 92 (icplusplus.c:28)
7   XPSApp        	0x000261dc XOptionDialog::XOptionDialog[in-charge](XFrameSamples*, TGWindow const*, TGWindow const*, unsigned, unsigned, int, bool, unsigned) + 2204 (crt.c:355)
8   XPSApp        	0x0002633c XFrameSamples::DoExportOptions() + 236 (crt.c:355)

Could it be that this is a problem of TGClient?
(I am using the cvs root version from Friday evening.)

Best regards


Please send the shortest possible setup reproducing this problem
together with the output from gdb as requested at


Dear Rene

As with my other problem, this problem is completely irreproducible, in this case
I have experienced it only once.

I know that the crash reporter of the Mac displays in the first line the last executed
function, i.e. the function where the crash occurs. Usually this is one of my functions,
but this time it was a ROOT function (called from other ROOT functions) so I
thought I let you know.

Best regards

Problems difficult to reproduce could be the sign of some uninitialized variable in your code. On Linux, valgrind is an unvaluable tool to spot these
Use the debugger (gdb) to report a traceback. The default traceback
obtained with bare root is not always precise.


Thank you, I will try to install valgrind on FC4.

Best regards

Dear Rene

Now I could catch the error when closing my dialogbox by pressing the Cancel button.
gdb gives the following error message:

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0xbfffeb28 in ?? ()
(gdb) bt
#0  0xbfffeb28 in ?? ()
#1  0x03018578 in G__G__Gui1_274_6_0 ()
#2  0x02ef0f00 in TGFrame::HandleEvent ()
Previous frame inner to this frame (corrupt stack?)

When pressing “Cancel” the following methods are executed before the crash appears:

This is a short excerpt of the corresponding code:

Sorrowly I have to attach the code since "code" does delete most of my code!!

My program seems to crash in the destructor when calling “delete fMain”.
Does “fMain->SendCloseMessage()” already delete fMain?

Best regards
code.txt (1.37 KB)

Dear Rooters

Maybe, the reason for the irreproducible bus errors could be that I am using the
statement "fMain->SendCloseMessage();"
in my code, which has worked fine in earlier versions of root!

Looking at the tutorial “guitest.C” shows that apparently this statement should no
longer be used but replaced by “TTimer::SingleShot()”:

1, It would be great if changes in code which force people to change their code
would be clearly reported somewhere, maybe in the ""
section (which currently displays: Object not found!)
Simply changing the code in the tutorials is in my opinion not sufficient.

2, Having to use TTimer::SingleShot() causes a visible delay when closing the
dialogbox which is a strange experience for users since no other gui program
shows a similar delay when closing a dialogbox.

Best regards

Dear Ilka

Thank you for your mail explaining that the longer deletion time of 150 is
required by Windows, otherwise ROOT will crash on Windows.

This is really sad but it seems that we have to live with it, or maybe could it help to do:
#idef Win delay = 150
#else delay = 50

Best regards

Hi Christian,

I was told by Bertrand that this problem is included in his list of tasks. We will keep you informed when a solution is found.

Cheers, Ilka