Summary: | Crash on exit | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | Marko Käning <mk-lists> |
Component: | onlinebanking | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | bugs.m1, cfeck, christian-david, lukasz.wojnilowicz, ralf.habacker, rjvbertin |
Priority: | NOR | Keywords: | drkonqi, triaged |
Version: | 4.8.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | New crash information added by DrKonqi |
Description
Marko Käning
2016-10-07 00:38:04 UTC
Here KMyMoney is used with Qt 4 and gwenhyfar with Qt 5 – if libkdeui.5.dylib is KF 5 based. This is probably the reason for the crash. Can you check if my assumption is correct? No, this is a purely non-KF5'ish installation (still)! :-) Don't know why libkdeui has version number 5 though. I guess this needs to be figured out. René, do you have an idea why there is a libkdeui.5.dylib in a qt4-mac-build of kmymoney4-devel? Is the 5 really an indication for KF5, I am really not sure about that now! The kdelibs libraries have always had a 5 version, confusingly. If that gaelicish library is built against Qt5 then I'd indeed expect crashes, but not just on exit. There should be an abort much earlier in that case. No, it's definitely built without KF5, as this is from a standard MacPorts install of port kmymoney4-devel which doesn't know anything about the KF5 world up to now. :) AqBanking/Gwenhywfar still had a dialog open somewhere. That is causing the crash. I wonder, if you can reproduce it by leaving an AqBanking dialog open and then exit from KMyMoney. Then my assumption is wrong – seems to be too simple to be true :( Do those supposed still-open dialogs have a QObject-based proxy/wrapper class? One source of UI-related crashes on OS X is deleting object instances representing UI elements that still have events pending, which can include events due to closing the UI element. In a nutshell, that's at least partly due to a mismatch between ObjC's memory management model (which uses refcounting; [foo release] isn't usually immediate) and C++'s model where `delete foo` has immediate effect. Qt provides the QObject::deleteLater() method for that. Note that deleteLater() only works on pointers, but the side-effects of immediate free can also arise when a non-pointer instance goes out of scope; in that case code has to be rewritten to use a pointer... (In reply to RJVB from comment #8) > Qt provides the QObject::deleteLater() method for that. I remember this from some patches you submitted a long time ago. Wasn't it in KDevelop? Yeah, I guess this needs some investigation. Will do what Thomas asked me to, i.e. close KMM with an AqBanking-window still open. (In reply to Thomas Baumgart from comment #6) > AqBanking/Gwenhywfar still had a dialog open somewhere. That is causing the > crash. I wonder, if you can reproduce it by leaving an AqBanking dialog open > and then exit from KMyMoney. Yes, I could provoke it by letting the online-update dialog open when exiting the application. That triggered the exact same backtrace as posted here. kdelibs.so version 5 is KDE Platform 4, because there was an ABI break in the early 1.x versions due to a new Qt 2 version. This means kdelibs.so.4 was actually KDE 3, etc. So, what are we going to do about this crash now? Which delete()'s exactly should I replace by deleteLater()? Looking at the backtrace again I'm not sure that this is a likely result of using delete instead of deleteLater, but you could begin by checking that AqBanking dialog. If it's a KDE dialog it could be a prime candidate for using deleteLater. In fact, I suspect the bug is in gwenhywfar, possible AqBanking, not in KMM. Though it may be possible to avoid the crash by deferring a KMM exit request until the ongoing operation is finished or aborted properly. *** Bug 364725 has been marked as a duplicate of this bug. *** Created attachment 106738 [details]
New crash information added by DrKonqi
kmymoney (4.8.0) on KDE Platform 4.14.22 using Qt 4.8.7
- What I was doing when the application crashed:
Called aqbanking to download statements. Closed kmymoney while aqbanking was working still.
-- Backtrace (Reduced):
#6 0x00007f070b17cad9 in GWEN_List1_GetFirst () from /usr/local/lib/libgwenhywfar.so.60
#7 0x00007f070b17ab6e in GWEN_Inherit_FindData () from /usr/local/lib/libgwenhywfar.so.60
#8 0x00007f0709a1ec80 in GWEN_ConfigMgrDir_LockGroup () from /usr/local/lib/gwenhywfar/plugins/60/configmgr/dir.so
#9 0x00007f070aaa2b66 in AB_Banking_LockSharedConfig () from /usr/local/lib/libaqbanking.so.35
[...]
#11 0x00007f070b1fa605 in GWEN_Dialog_free () from /usr/local/lib/libgwenhywfar.so.60
Can some retry this with current master? We have made some fixes that should avoid this crash on exit behavior. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |