On Tue, Jun 23, 2009 at 10:17 PM, Alan W. Irwin
<ir...@beluga.phys.uvic.ca> wrote:
> There is now more urgency to extensive testing of the thread safety for the
> qt driver as well as the associated plplotqt library. In the latter case,
> qt_example shows some memory management issues concerning the mutex. (There
> were some build issues for that installed C++ example, but those have now
> [revision 10067] been completely fixed for the new CMake-based build system
> for the installed examples.) The run-time issue for qt_example is you cannot
> exit the associated GUI anymore using the usual methods (e.g., alt+F4).
> Instead, you have to hit control-c. I investigated some more with valgrind
> and exposed some severe memory management issues with the mutex when all I
> did in the resulting GUI was hit alt+F4 to exit. (I get a similar result if
> Dmitri's patch is reverted so the issue is probably Alban's mutex to make qt
> thread safe is not completely correct and that error propagated to Dmitri's
> implementation of that mutex logic.)
Hello Alan,
That's exactly the problem I was writing to you about:
> 2. Code uses two static global objects derived from QObject
> (QtPLDriver::mutex and an instance of MasterHandler). This should be
> avoided because construction order is not defined. Also, on my system
> this leads to destructors of those objects being called two times.
> Anyway, Qt and KDE developers say this is a bad thing [2] [3].
> Although KDE developers offer some sort of a macro that could mitigate
> those problems, I think we could come up with a solution that creates
> the object during plplot init and de-init.
The destructor of the QMutex is called twice. On the second
destruction it tries to free some pthread object and hangs there. If
I comment-out all mutex uses altogether then it crashes in
MasterHandler::~MasterHandler(). Try adding a debug print in it and
you will see that it is called twice and a segmentation fault after
that. (But I have actually verified it with gdb and Qt library
compiled with debugging information).
I don't really understand what it MasterHandler used for (but I
suspect that someone is supposed to connect() to its signals, but
nobody can because its instance is not declared in the header). But
anyway, instances of MasterHandler, QMutex etc are some "global data"
Qt driver needs to operate and share between all drawing contexts.
Let's put all that in some QtPLGlobalData class. Essentially it will
be a singleton with a reference counter.
In QtPLDriver we define a static variable of type QtPLGlobalData
*globalData = NULL; and a counter that holds the number of currently
alive QtPLDriver objects. In QtPLDriver constructor we create an
instance of QtPLGlobalData if this is the first driver instance, in
destructor we delete QtPLGlobalData if that was the last one. The
cons of this approach:
* no global static non-POD objects;
* more global data can be added in future and it should not create
problems with construction/destruction order because it is managed by
the Qt driver code explicitly;
* construction/destruction of that data is driven by driver init/de-init calls.
Is that a realistic idea?
[Sorry for double-posting, I accidentally hit "reply" the first time]
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
