Bug 391786

Summary: kmymoney git 5.0 crashes on exit, even if no file loaded
Product: [Applications] kmymoney Reporter: Jack <ostroffjh>
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED NOT A BUG    
Severity: normal CC: lukasz.wojnilowicz
Priority: NOR    
Version: 5.0.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jack 2018-03-12 22:32:18 UTC
I just compiled a new version (clean build dir) from git 5.0 branch.  Ran it as "kmymoney -n" and got a repeatable crash on exit.

Initial load:

WebConnect: Try to connect to WebConnect server
WebConnect: Connect to server failed
WebConnect: Running in server mode
Plugins: checkprinting loaded
Plugins: csvexporter loaded
Plugins: csvimporter loaded
Plugins: gncimporter loaded
Plugins: icalendarexporter loaded
Plugins: ofximporter loaded
Plugins: qifexporter loaded
Plugins: qifimporter loaded
Plugins: reconciliation report loaded
Online plugins found 1

After exiting:

Plugins: checkprinting unloaded
Plugins: csvexporter unloaded
Plugins: csvimporter unloaded
Plugins: gncimporter unloaded
Plugins: icalendarexporter unloaded
Plugins: ofximporter unloaded
Plugins: qifexporter unloaded
Plugins: qifimporter unloaded
Plugins: reconciliation report unloaded
*** Error in `/home/jack/KDE/KMM/install50/bin/kmymoney': munmap_chunk(): invalid pointer: 0x00005650fb122f40 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x77cdc)[0x7f7f7d243cdc]
/lib64/libc.so.6(+0x7f91b)[0x7f7f7d24b91b]
/usr/lib64/libQt5Core.so.5(_ZN9QHashData11free_helperEPFvPNS_4NodeEE+0x54)[0x7f7f7df9f414]
/home/jack/KDE/KMM/install50/lib64/libkmm_csvimportercore.so.5(+0x33b77)[0x7f7f83427b77]
/home/jack/KDE/KMM/install50/lib64/libkmm_csvimportercore.so.5(+0x34454)[0x7f7f83428454]
/lib64/libc.so.6(__cxa_finalize+0xa2)[0x7f7f7d204602]
/home/jack/KDE/KMM/install50/lib64/libkmm_csvimportercore.so.5(+0xb603)[0x7f7f833ff603]
======= Memory map: ========
(I'll post the actual memory map if it would be helpful.

Oddly, if I load a file and then exit, I get a segmentation fault, but no backtrace.  If I load a file, unload it, then exit, I get the crash.  Exit either by File/Quit or click the "X" to close the window - same behavior.  If I load a file, it seems to work and save fine.

If I run under gdb, doing bt after the crash gives:

(gdb) bt
#0  0x00007ffff0864ea0 in raise () from /lib64/libc.so.6
#1  0x00007ffff0866ac0 in abort () from /lib64/libc.so.6
#2  0x00007ffff08a7ce1 in ?? () from /lib64/libc.so.6
#3  0x00007ffff08af91b in ?? () from /lib64/libc.so.6
#4  0x00007ffff08b0e31 in ?? () from /lib64/libc.so.6
#5  0x00007ffff1603414 in QHashData::free_helper(void (*)(QHashData::Node*)) () from /usr/lib64/libQt5Core.so.5
#6  0x00007ffff6a8bb77 in QHash<eMyMoney::Transaction::Action, QString>::freeData (this=0x7ffff6ca1b28 <CSVImporterCore::m_transactionConfName>, x=0x5555564b49e0)
    at /usr/include/qt5/QtCore/qhash.h:573
#7  0x00007ffff6a8c454 in QHash<eMyMoney::Transaction::Action, QString>::~QHash (this=0x7ffff6ca1b28 <CSVImporterCore::m_transactionConfName>, 
    __in_chrg=<optimized out>) at /usr/include/qt5/QtCore/qhash.h:252
#8  0x00007ffff0868602 in __cxa_finalize () from /lib64/libc.so.6
#9  0x00007ffff6a63603 in ?? () from /home/jack/KDE/KMM/install50/lib64/libkmm_csvimportercore.so.5
#10 0x00007fffffffd5b0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


I can't tell if there is enough data here to help, but I'll be glad to assist with troubleshooting if possible.
Comment 1 Jack 2018-03-14 00:30:52 UTC
I just checked git master, and it does the same thing, so it's nothing specific to 5.0.
Comment 2 Thomas Baumgart 2018-03-14 10:50:42 UTC
I am unable to reproduce this here on master or 5.0 and I think I have all those plugins enabled as well (and some more). Some more messages show up because I compiled with new features enabled, but I also tried w/o them and get the same result (unable to duplicate).

WebConnect: Try to connect to WebConnect server
WebConnect: Connect to server failed
WebConnect: Running in server mode
Plugins: checkprinting loaded
Plugins: csvexporter loaded
Plugins: csvimporter loaded
Plugins: gncimporter loaded
Plugins: icalendarexporter loaded
Plugins: kbanking loaded
Plugins: kbanking pluged
Plugins: qifexporter loaded
Plugins: qifimporter loaded
Plugins: reconciliation report loaded
Plugins: weboob loaded
Online plugins found 2
Cost center model created with items 0
Payees model created with items 0
reading file
start parsing file
startDocument
reading securities
endDocument
Start loading splits
Loaded 3422 elements
Loaded 26 elements
Loaded 3449 elements

<<< Selected File/Quit here >>>

Plugins: checkprinting unloaded
Plugins: csvexporter unloaded
Plugins: csvimporter unloaded
Plugins: gncimporter unloaded
Plugins: icalendarexporter unloaded
Plugins: kbanking unpluged
Plugins: kbanking unloaded
Plugins: qifexporter unloaded
Plugins: qifimporter unloaded
Plugins: reconciliation report unloaded
Plugins: weboob unloaded
Comment 3 Jack 2018-03-14 16:32:15 UTC
I'll see if I can build on a different PC or in a VM.  I wonder if it might relate to versions of utilities?  I'm using gcc 7.3.0 and cmake 3.9.6.  I can also try building with gcc 7.2.0 or 6.4.0
Comment 4 wojnilowicz 2018-03-15 08:23:29 UTC
(In reply to Jack from comment #3)
> I'll see if I can build on a different PC or in a VM.  I wonder if it might
> relate to versions of utilities?  I'm using gcc 7.3.0 and cmake 3.9.6.  I
> can also try building with gcc 7.2.0 or 6.4.0

Maybe it's about compiler optimizations. Please read my comment in bug #391251.
Comment 5 Jack 2018-03-15 17:35:47 UTC
I compiled on a different PC, and did not get the crash.  I compiled using a modified Gentoo ebuild for git 5.0 head and did not get the crash.  Compiling myself from git 5.0 I DO get the crash (either DEBUG or RELEASE build). 

from CMakeCache.txt:
CMakeCache.txt:CMAKE_CXX_FLAGS:STRING=
CMakeCache.txt:CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMakeCache.txt:CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMakeCache.txt:CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMakeCache.txt:CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

from the emerge information:
Compiler flags:
C++             -O2 -pipe -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Wove
rloaded-virtual -Werror=return-type -Wvla -Wdate-time -fexceptions -fno-common -Wextra -Wlogical-op

I'm going to try a RelWithDebInfo build to see if the -O2 avoids the crash, othewise I don't see the issue, although it does seem it is an environment or configuration issue.  (In the other but, I notice mention of Wayland, but I don't know if that is likely to be relevant or not.)
Comment 6 Jack 2018-03-16 20:40:03 UTC
I have now recompiled for Debug, Release, and RelWithDebInfo with both gcc 6.4.0 and 7.3.0, and can no longer reproduce the crash, so I'm just going to close this as invalid.  (would WORKSFORME be better?)  I'll reopen only if I can consistently reproduce the crash.  

I am assuming it was either something that got updated recently, or maybe just a build or install dir that was not as clean as I thought.
Comment 7 wojnilowicz 2018-03-17 05:37:35 UTC
(In reply to Jack from comment #6)
> I have now recompiled for Debug, Release, and RelWithDebInfo with both gcc
> 6.4.0 and 7.3.0, and can no longer reproduce the crash, so I'm just going to
> close this as invalid.  (would WORKSFORME be better?)  I'll reopen only if I
> can consistently reproduce the crash.  
> 
> I am assuming it was either something that got updated recently, or maybe
> just a build or install dir that was not as clean as I thought.

I think it's not completely invalid. We see that it depends on a compilation step.
If my assumption is right, KMyMoney crashes if compiled with some optimizations. It would be good to know with which ones.

I hope to get optimization issues solved by fixing defects reported by https://scan.coverity.com/projects/kmymoney?tab=overview
and enabling more checks during the compilation.
Comment 8 Jack 2018-03-17 14:36:15 UTC
See comment 5 - I think these are the optimizations applied based on build type.  Do you know if there is any other way to force an optimization level?

I built all three build types with two versions of gcc with no crash, so if optimization level matters, there is some other parameter or library that is also related.  If we can't find a way to consistently cause the problem, even if only for one or two people, we wont know whether any fixes are really relevant.