On 2010-05-27 20:22+0100 Andrew Ross wrote: > On Thu, May 27, 2010 at 12:00:32PM -0700, Alan Irwin wrote: >> On 2010-05-27 12:03-0400 Hazen Babcock wrote: >> >>> Following your suggestion I simplified the test to the following: >>> >>> #!/bin/sh >>> >>> LIMIT=2000 >>> >>> for((a=1; a<= LIMIT; a++)) >>> do >>> examples/c/x10c -dev pngqt -o test.png >>> # examples/c/x26c -dev pngqt -o test.png -fam >>> echo -n "$a" >>> done >> >> For what it is worth, I just ran the above test. It took roughly 3 minutes >> to finish 2000 iterations without issues. I looked at top during the >> latter part of the test and could see nothing unusual. >> >>> >>> >>> This pretty consistently locks up before a reachs 1000. >>> >>> By sprinkling printf statements through the code I've determined that >>> the lock up occurs here: >>> new QApplication( argc, argv, isGUI ); >>> in the file qt.cpp. >> >> I have looked up the documentation for that function in >> http://doc.qt.nokia.com/4.6/qapplication.html#QApplication-2. It appears it >> does not have any checks for error conditions that we should be trying. >> >> Also, it appears that isGUI Boolean sets up a whole bunch of stuff related >> to X which should only be necessary for qtwidgets. It appears from the >> in-source question marks, that Alban Rochel (the original developer) was >> unsure about this point so he always set isGUI to true even for >> the noninteractive devices. I have just (revision 11027) >> changed that so isGUI is false for the noninteractive qt devices. That >> change works fine for me (using the test_all_qt target). I also repeated >> the above test with LIMIT=2000, with the same good results. Note, it >> finished roughly twice as fast as the original test which indicates >> that the overhead from QApplication is much less after revision 11027. >> >> Now, the key question. Hazen, does revision 11027 work around >> the issue that you are seeing? > > It will be interesting to see if this works, but this is not a long term > solution. Alban did this for a reason after some discussion on list. > You must have exactly one QApplication object for a qt program. Some of > the locking and counter code in the qt driver is to check for this. The > first stream to use a qt device creates the object and all others make > use of it. Once the last stream has finished the object is deleted. The > problem is that even if the first stream is using a non-interactive device > subsequent streams might want to use qtwidget. The only way to guarantee > that this is possible is to always set isGUI to true. If your "fix" turns > out to fix things then we need to rethink how to implement it. We might > have to ban qtwidget for subsequent streams if the first stream is > non-interactive.
Thanks for reminding me of that issue and summarizing it so well. If the current speculative fix solves Hazen's issue, then perhaps banning qtwidget for subsequent streams if isGUI is false is exactly what we should do since the fix does eliminate X overhead in the general case of thousands of tests consisting of many different examples with many different qt noninteractive devices. > >>> I also tried with DYN_DRIVERS=OFF, but the same thing happens. >>> >>> Note that when it locks up I can see (using top) that x-session-manager >>> is running at 75% and gdm at 25%. Once this happens I cannot start any >>> other programs and I have to restart my computer. >> >> Hmm. That is one difference between us. I am running KDE4 while it appears >> (from your use of gdm) that you are using GNOME. I wonder if there is some >> incompatibility between QT4 and GNOME that does not exist for the KDE4 case. >> For example, QT4 could be contending for some desktop resource with GNOME so >> that eliminating that contention (as above for noninteractive qt devices) >> would work around the issue. Of course, all this speculation crashes in >> flames if revision 11027 does nothing for you. :-) > > That's a possibility, but it still seems quite unlikely. Qt is very widely > used, even with GNOME and I've not seen any reports of this. By the way > I'm also using KDE though. I agree. However, a much more likely possibility (considering how iffy X is these days because of the on-going X code reorganization) is that Hazen's particular X driver has an issue so that setting up an X environment for -dev pngqt literally thousands of times eventually runs X out of some resource. So I have my fingers crossed that the speculative fix will work for Hazen. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
