Thiago Macieira wrote: > QLibrary actually unloads them specifically as part of the QtCore global > destruction, except if you're using glibc on Linux:
That could explain the difference I was seeing, but it's more likely that Darwin is either more proactive in unloading plugins with their dependencies included, or less intelligent in doing so. BTW, with the simple unload protection workaround I added, the plugin dtor is now called from the location you cited, I think. Not from QFactoryLoaderPrivate anymore in any case. > The thinking was that the danger of using pointers to static date of libraries > and plugins already unloaded. That probably sounded different in your head? :) > After all, if QtCore is destroying itself, it's only QtCore code itself that is being run. If that code only executes itself of course. I actually noticed a couple of kernel messages during the crashes I had, about how execution of code at invalid addresses had been prevented. >> What's the difference between unload() and release(), btw? > > QLibrary doesn't have release(). Did you mean QLibraryPrivate? Why, yes. QFactoryLoaderPrivate::~QFactoryLoaderPrivate() does first the one, then the other. I had a look at the release() code, I'm guessing that it's goal is to allow the system to unload the library from memory? > But what is it doing during destruction that it needs to access the patterns? > > Oh, I know: it's trying to deref the QString.... I suppose it must be that, yes; that corresponds to what Sérgio posted earlier. It would probably be impossible to know what QString that is, at the time of the crash? Making deep copies of the QStrings before storing them should also solve this issue, but maybe that would be too expensive? > I'm ok with emptying the cache on aboutToQuit. I've made an initial simple implementation, subclassing QCache and adding the few required methods so I can call clear() on aboutToQuit and toggle the availability switch. This indeed solves the crash for me. A few questions: - do I need to check for QT_NO_OBJECT here, or is it enough to check for QT_BOOTSTRAPPED? - is it correct that I don't need a Q_OBJECT macro (and moc file) here for reliable signal/slot functionality? - (ahem) do I need to call the parent default constructor explicitly if I override (extend) the default constructor? I'll be testing this more before submitting it for review. For one, I'd like to have some idea how often code tries to add new entries (right now I print a warning for all attempts to access the cache, so that includes removing items). R. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
