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