Review Request: Fix a VLC crash by delaying object deletion to avoid invalid access by QtDBus

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100577/#review10296
-----------------------------------------------------------


A very general rule to software development is: don't commit code or fixes that you don't understand.

So I don't like this, because it's a workaround for an un-identified issue. If it crashes, where's the valgrind log that explains exactly why it crashes?
If it's a Qt bug, then it should be investigated and fixed in Qt. Then we can talk about short-term workarounds to make kde users happier, but not before (which would just hide and postpone the issue until later).

What's the harm in committing this anyway, you might ask? Well 1) this could happen again anywhere else since this looks like a fix at the wrong level, 2) I don't know if deleteLater are processed at app quitting time, so this might lead to false positives in future memory-leak debugging. 3) in general, any of these non-running destructors could be doing things that we actually need to happen.

- David Faure


On Jan. 30, 2012, 6:35 a.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100577/
> -----------------------------------------------------------
> 
> (Updated Jan. 30, 2012, 6:35 a.m.)
> 
> 
> Review request for kdelibs and Thiago Macieira.
> 
> 
> Description
> -------
> 
> As described in the bug report when opening the file dialog, canceling it and exiting VLC causes the application to seg fault. The backtraces posted in the bug report shows that the crash happens somewhere in QtDBus and I get a similar backtrace when using v1.1.7 of this application. 
> 
> When I looked into this issue what I discovered was that only KIO classes that register themselves with QtDBus cause the crash. I only found that out because fixing the crash in KIO::Scheduler by defering its deletion using deleteLater() did not prevent the application from still crashing on exit. However, the crash had moved to another location, KBookmarkManager. The only common thing between the crash at KBookmarkmanager and KIO::Scheduler was that in both cases the backtrace shows QtDBus attempting to invoke or access some method or slot in the object that was just destroyed. At this point I decided to check how many other classes in KIO register themselves with QtDBus and found only one more. I then applied the same changes to all three,  defering the deletion of any object registered with QtDBus using QObject::deleteLater, and the crashing went away.
> 
> Anyhow, I have no idea why the crashes are only seen with this application. I was not able to duplicate the crash using the same sequences in another Qt only app, Arora or any of the other KDE applications I tried.
> 
> 
> This addresses bug 234484.
>     http://bugs.kde.org/show_bug.cgi?id=234484
> 
> 
> Diffs
> -----
> 
>   kio/bookmarks/kbookmarkmanager.cc d8a9cb7 
>   kio/kio/fileundomanager.cpp f580c29 
>   kio/kio/scheduler.cpp 6b36d9d 
> 
> Diff: http://git.reviewboard.kde.org/r/100577/diff/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120202/6d6aa7f0/attachment.htm>