[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
From:       Yichao Yu <bugzilla_noreply () kde ! org>
Date:       2017-04-27 17:34:27
Message-ID: bug-363753-17878-bTrnEREjHg () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=363753

--- Comment #52 from Yichao Yu <yyc1992@gmail.com> ---
Yes the latest version looks fine though I'd like to test it for some time.

> but if I understand the DBus protocol well enough they'd have to send exactly the \
> "right" signals (one of those QtCurve subscribes to) and exactly at the "right" \
> moment. That seems a bit far-fetched.

It's more complicated than that. IIRC the segfault happens when the qdbus
connection walks some internal data structures for dispatch, which touches some
unmapped memory (vtables and alike).

> the overall complexity of KDE and Qt is becoming so big that it's not always \
> possible to do certain things like proper clean up because of race conditions.

I hope that's not the case but maybe it is....

> That's probably why Qt no longer unloads (all) plugins explicitly. Except \
> apparently the style plugin, or that too is handled by some automagic mechanism.

Hmmm. That's interesting because I've never seen anything being unloaded before
5.8 (or 5.7?).

> Presuming that each dlopen adds to a counter that prevents unmapping and each \
> dlcose decreases that counter you could do it in the Style ctor and dtor.

Yes. If I can find the right function...

> But are you sure the unmapping was performed by Qt? I've never looked into this \
> aspect of the code but I would expect them at most to dlclose libraries and \
> plugins. That should of course also invalidate the image of the library to some \
> degree but not necessarily unload everything.

What Qt does is of course `dlclose`, the unmmap I've seen happens in the
dlclose call.

> Maybe your kernel is configured to do very strict cleanup, or RAM is so tight that \
> it tends to unload resources that are no longer needed immediately?

I was hopping this to be a glibc thing but those low level detail is beyong me.

> But: it'd be a severe bug if Qt somehow unloaded or even dlclosed a plugin before \
> having destroyed all class instances created through it.

It's clearly doing the dlclose before they destructed the Style*

> I've never seen an example showing that code must delete Style instances itself, so \
> I think the application instance takes ownership.

It almost feels like that Qt should delete all QObjects before deleting the
style plugin but that also seems like a terrible idea....

> If that also means that the file is completely removed from memory will probably \
> depend on circumstances, but should be a moot question.

Right, my confusing is just that why it sometimes (well, previously) unmmap and
sometimes not....

> > __attribute__((destructor))  function  attributes.   See the gcc info pages for \
> > information on these.  Con-

This I'm acutally not worrying too much. I still have a faith that the plugin
destructor will be closed before dlclose (confirmed in the debugger) so using
it as the last resort should still be ok.

> You could add some trace output to stderr (better not via Qt code ;)) in the \
> library destructor and see if that confirms your hypothesis (let it print the \
> number of plugin and style instances that are still open, for instance).

I have confirmed in the debugger that the single dlopen on qtcurve have been
dlclosed. I might get a glibc with debug simple and check internal logic
later...

> Other things to do (as soon as you can reproduce the crash) would be to

Let's hope I don't and the patch just work.........................

> I have never seen a backtrace of the kind of crash you are seeing, but I think that \
> with my current implementation you should no longer be seeing it.

I actually mean the stack trace in this bug report, not mine. For that I agree
that adding a safe guard that's called earlier (i.e. abouttoquit) should work.

-- 
You are receiving this mail because:
You are watching all bug changes.=


[prev in list] [next in list] [prev in thread] [next in thread]