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. >> 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. Andrew ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
