[ROOT] ROOT/QtROOT within a multithreaded Qt application

From: Colley, Tony (Tony.Colley@itt.com)
Date: Fri Jan 04 2002 - 18:26:20 MET


Help!

It would be most efficient if you would read (and hopefully comprehend) this
entire email before sending a reply.

I am getting "***BREAK*** segmentation violation" errors (and then a core
dump) in my application. Sometimes when it crashes, I also get error reports
from <RootX11ErrorHandler> about BadWindow and BadDrawable (invalid
parameter XID:0).

I am attempting to use ROOT to provide advanced graphing capabilities to an
existing Qt application (a program to perform simulations of imaging and
sounding sensors for meteorological satellites), and I am using QtROOT to
coordinate the two (Qt and ROOT) event loops; but I also have a different
implementation that doesn't use QtROOT (it uses a QTimer to call
gSystem->DispatchOneEvent(kTrue) several times a second) and it exhibits
identical behaviour, so the problem isn't within or unique to QtROOT.

I am developing this software on Linux (RedHat 7.1 with gcc 3.0.1). I am
using ROOT 3.02/06.

The existing Qt application (it's name is CSF) is multithreaded and I am not
permitted to make it single threaded. Nor am I allowed to have it use
TThread instead of QThread (not that doing so would help according to what
I've read online).

When I instantiate my "DrawGraph" class (which essentially creates some
overlaid TGraphs and puts them on a TCanvas or TQRootCanvas) from the main
thread, it works fine. When I do the identical instantiation from another
thread, I get the error message(s) and core dump.

The obvious solution would be to do all the "DrawGraph"s in the main thread.
However, each "DrawGraph" is done to display data during a simulation run,
and the "simulation run" is implemented in CSF as its own thread. Perhaps if
there were a way to have the simulation thread tell the main thread to
create the "DrawGraph" (with the data from the simulation thread), this
problem could be avoided. Is such a thing possible to do?

Within CSF, the user may (once this is all working) select a variable number
of graphs to be created during the course of the simulation, and in fact the
results of the simulation may alter the number of graphs to be created, so
it would not be practical to pre-create a set of TCanvases in the main
thread prior to starting the simulation thread (the approach used by GO4).
Also, the whole purpose of CSF is to allow the user to interactively piece
together a full simulation using dynamically loaded set of components, so
the main thread really has no clue what the simulation thread entails.

Anyway, the canvas instantiates itself (that is, a window appears with the
TGraph displayed properly) very briefly before the program crashes. The
program appears to be dying in TGFrame::HandleEvent (tracked using copious
cout statements). It may be worth noting (or it may be common knowledge to
you) that the event handling ALWAYS happens in the main thread (according to
getpid()). It appears to be dying on the first kConfigureNotify event. When
I bypass that event (comment out that section of code in
TGFrame::HandleEvent), several events (mostly kExpose events) are processed
before the program crashes (on a kExpose event). When I let that first
kConfigureNotify event be processed, the program seems to crash after the
return from TGFrame::HandleConfigureNotify but before the next statement can
be processed in TGFrame::HandleEvent.

I **am** able to create a popup window using only Qt widgets from the
simulation thread, so it appears that my Linux, X11R6 and Qt are properly
setup to support threads. I would rather not have to rewrite ROOT to use
only Qt widgets.

I have looked at the Qt document "Thread Support in Qt", and at the Threads
chapter in the ROOT Users Guide, and I have looked at the roottalk messages
that were found by searching the ROOT website. I have also read through
http://go4.gsi.de/Threads/tthread.htm (where item 1.2.4 seems to indicate
that there is no hope). I may have missed something, of course, so feel free
to call me whatever names you prefer as long as you also clearly point me
wherever the "blatantly obvious solution" is documented.

Any other helpful hints, suggestions, or fixes would also be appreciated.

Tony Colley

ITT Industries A/CD
Fort Wayne, IN  USA
Tony.Colley@itt.com

************************************ 
If this email is not intended for you, or you are not responsible for the
delivery of this message to the addressee, please note that this message may
contain ITT Privileged/Proprietary Information.  In such a case, you may not
copy or deliver this message to anyone.  You should destroy this message and
kindly notify the sender by reply email.  Information contained in this
message that does not relate to the business of ITT is neither endorsed by
nor attributable to ITT. 
************************************ 



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:37 MET