[Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Thiago Macieira]

On segunda-feira, 29 de janeiro de 2018 12:53:21 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > The plugins aren't unloaded when you call unload(), but they are unloaded
> > when the application exits. There's no way to avoid that.
> 
> I guess not, no, though I'm not sure if Qt has do do the unloading and
> releasing itself (as opposed to just telling the plugins to prepare for
> being unloaded). I don't think there are still OSes out there that will
> leave dangling plugins in memory after unloading the app that loaded them.

QLibrary actually unloads them specifically as part of the QtCore global 
destruction, except if you're using glibc on Linux:

#ifdef __GLIBC__
                // glibc has a bug in unloading from global destructors
                // see https://bugzilla.novell.com/show_bug.cgi?id=622977
                // and http://sourceware.org/bugzilla/show_bug.cgi?id=11941
                lib->unload(QLibraryPrivate::NoUnloadSys);
#else
                lib->unload();
#endif

The thinking was that the danger of using pointers to static date of libraries 
and plugins already unloaded. After all, if QtCore is destroying itself, it's 
only QtCore code itself that is being run.

> What's the difference between unload() and release(), btw?

QLibrary doesn't have release(). Did you mean QLibraryPrivate?

> > Your crash happens after the QLibrary private global static has finished
> > running.
> 
> Which appears to be beyond my control. Or should I say, the only control I
> have over that is a brute-force means to keep that QLibrary private global
> static alive a bit longer (and as luck has it, until after the
> QRegExpEngine cache has been destroyed)?

This sounds like something a little patch in QtCore may solve.

> Apparently I'm not the first to run into this problem. Assuming that the
> QRegExpEngine cache is indeed an important optimisation, wouldn't it be
> possible to empty it much earlier during the global destruction phase, and
> lock it? That way at least there is no more risk that the order changes
> again and my workaround no longer works.
> 
> Rewriting the QRegExpEngine cache implementation so it can connect to
> QCoreApplication::aboutToQuit and drain+lock itself shouldn't be very hard
> and should be completely invisible from the outside, no?

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'm ok with emptying the cache on aboutToQuit.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center