[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:       RJVB <bugzilla_noreply () kde ! org>
Date:       2017-04-27 19:01:05
Message-ID: bug-363753-17878-Q1qnDV4kqp () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #53 from RJVB <rjvbertin@gmail.com> ---
(In reply to Yichao Yu from comment #52)
> Yes the latest version looks fine though I'd like to test it for some time.

By all means :)

> 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).

It would be useful to know which signal(s) is/are concerned?


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

I think plugins were unloaded in 5.4 and earlier, and then in 5.5 they dropped
unloading of at least certain plugins which started to cause trouble. That may
even have been related to DBus, I can't remember and am not too keen on digging
out the exchange with Thiago to see if my memory is correct :)

> > 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*

Erm, yes, I forgot about that. This however should be just before the
application exits, you've had a lot of chance that you have been able to get
DBus signals to arrive in that interval :)

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

I notice that that Qt's Fusion style uses an undocumented QCommonStyle ctor,
accepting an argument.
I should have a look if QStylePlugin::Create() couldn't do `new Style(this)`
and benefit from automatic Style instance deletion when the plugin is unloaded.

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

What can also be the case is that enough other things have changed that
whatever access is made to deallocated memory no longer causes a SEGV. You
know, like a proper Heisenbug.
Or you simply had some other kind of stability going on at the time. How
reproducible was that bug over time, after a reboot etc?

> 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.

Yes, of course. The library destructor idea is only for debugging to know
exactly when unloading is going to take place (possible set a breakpoint) etc.
I never planned to use it for deallocating memory; that seems like a bad idea.

> > 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.

Sure, but the other backtrace is interesting too. :)

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


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