Setting the column for date or payee causes a crash. This bug may be a duplicate of or related to bug 314940. However, this still fails in 4.6.6 and 4.6.90-e625006875 The crash can be reproduced every time. Reproducible: Always -- Backtrace: Application: KMyMoney (kmymoney), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f89bcb5c940 (LWP 32135))] Thread 2 (Thread 0x7f89b096b700 (LWP 32139)): #0 0x0000003d3b0ea7cd in poll () from /lib64/libc.so.6 #1 0x0000003d3d8495b4 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #2 0x0000003d3d8496dc in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x0000003d469b543e in QEventDispatcherGlib::processEvents (this=0x7f89ac0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452 #4 0x0000003d4698538f in QEventLoop::processEvents (this=this@entry=0x7f89b096ac40, flags=...) at kernel/qeventloop.cpp:149 #5 0x0000003d469856dd in QEventLoop::exec (this=this@entry=0x7f89b096ac40, flags=...) at kernel/qeventloop.cpp:204 #6 0x0000003d46879e5f in QThread::exec (this=this@entry=0x419bc30) at thread/qthread.cpp:538 #7 0x0000003d46965de3 in QInotifyFileSystemWatcherEngine::run (this=0x419bc30) at io/qfilesystemwatcher_inotify.cpp:265 #8 0x0000003d4687c69f in QThreadPrivate::start (arg=0x419bc30) at thread/qthread_unix.cpp:349 #9 0x0000003d3bc07f35 in start_thread () from /lib64/libpthread.so.0 #10 0x0000003d3b0f4c3d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f89bcb5c940 (LWP 32135)): [KCrash Handler] #5 QString::operator== (this=0x4604a50, other=...) at tools/qstring.cpp:2192 #6 0x00007f89b2c9cee8 in CsvImporterDlg::validateColumn(int const&, QString const&) () from /usr/lib64/kde4/kmm_csvimport.so #7 0x00007f89b2c9d860 in CsvImporterDlg::dateColumnSelected(int) () from /usr/lib64/kde4/kmm_csvimport.so #8 0x00007f89b2c937bb in CsvImporterDlg::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.3] () from /usr/lib64/kde4/kmm_csvimport.so #9 0x0000003d4699b37a in QMetaObject::activate (sender=sender@entry=0x42b9e80, m=m@entry=0x3d498acb80 <QComboBox::staticMetaObject>, local_signal_index=local_signal_index@entry=5, argv=argv@entry=0x7fff36324a40) at kernel/qobject.cpp:3567 #10 0x0000003d491aa571 in QComboBox::currentIndexChanged (this=this@entry=0x42b9e80, _t1=0) at .moc/release-shared/moc_qcombobox.cpp:315 #11 0x0000003d491aa621 in QComboBoxPrivate::_q_emitCurrentIndexChanged (this=this@entry=0x42b9ed0, index=...) at widgets/qcombobox.cpp:1278 #12 0x0000003d491aa924 in QComboBoxPrivate::setCurrentIndex (this=this@entry=0x42b9ed0, mi=...) at widgets/qcombobox.cpp:2049 #13 0x0000003d491aaa96 in QComboBoxPrivate::_q_itemSelected (this=0x42b9ed0, item=...) at widgets/qcombobox.cpp:1247 #14 0x0000003d4699b37a in QMetaObject::activate (sender=sender@entry=0x4388880, m=m@entry=0x3d498cbbc0 <QComboBoxPrivateContainer::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fff36324ca0) at kernel/qobject.cpp:3567 #15 0x0000003d4944e792 in QComboBoxPrivateContainer::itemSelected (this=this@entry=0x4388880, _t1=...) at .moc/release-shared/moc_qcombobox_p.cpp:252 #16 0x0000003d491a5d34 in QComboBoxPrivateContainer::eventFilter (this=0x4388880, o=0x40ee920, e=0x7fff363251e0) at widgets/qcombobox.cpp:655 #17 0x0000003d46986a66 in QCoreApplicationPrivate::sendThroughObjectEventFilters (this=<optimized out>, receiver=0x40ee920, event=0x7fff363251e0) at kernel/qcoreapplication.cpp:1063 #18 0x0000003d48dcae3c in QApplicationPrivate::notify_helper (this=0xde9a20, receiver=0x40ee920, e=0x7fff363251e0) at kernel/qapplication.cpp:4561 #19 0x0000003d48dd18f1 in QApplication::notify (this=<optimized out>, receiver=0x40ee920, e=0x7fff363251e0) at kernel/qapplication.cpp:4108 #20 0x0000003d4b84a59a in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5 #21 0x0000003d469868fd in QCoreApplication::notifyInternal (this=0xdd50e0, receiver=0x40ee920, event=0x7fff363251e0) at kernel/qcoreapplication.cpp:953 #22 0x0000003d48dd1067 in QApplicationPrivate::sendMouseEvent (receiver=0x40ee920, event=0x7fff363251e0, alienWidget=0x40ee920, nativeWidget=0x4388880, buttonDown=<optimized out>, lastMouseReceiver=..., spontaneous=true) at ../../src/corelib/kernel/qcoreapplication.h:231 #23 0x0000003d48e4696c in QETWidget::translateMouseEvent (this=0x4388880, event=<optimized out>) at kernel/qapplication_x11.cpp:4474 #24 0x0000003d48e450ac in QApplication::x11ProcessEvent (this=0xdd50e0, event=event@entry=0x7fff36325520) at kernel/qapplication_x11.cpp:3663 #25 0x0000003d48e6cac4 in x11EventSourceDispatch (s=0xde4de0, callback=0x0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:148 #26 0x0000003d3d8492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #27 0x0000003d3d849628 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #28 0x0000003d3d8496dc in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #29 0x0000003d469b541e in QEventDispatcherGlib::processEvents (this=0xde4d10, flags=...) at kernel/qeventdispatcher_glib.cpp:450 #30 0x0000003d48e6cc46 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207 #31 0x0000003d4698538f in QEventLoop::processEvents (this=this@entry=0x7fff36325910, flags=...) at kernel/qeventloop.cpp:149 #32 0x0000003d469856dd in QEventLoop::exec (this=this@entry=0x7fff36325910, flags=...) at kernel/qeventloop.cpp:204 #33 0x0000003d4698ada9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225 #34 0x000000000045e370 in runKMyMoney (a=0xdd50e0, splash=0xf94ba0) at /usr/src/incoming/Kmymoney/kmymoney/kmymoney/main.cpp:283 #35 0x000000000045ccf2 in main (argc=1, argv=0x7fff363265e8) at /usr/src/incoming/Kmymoney/kmymoney/kmymoney/main.cpp:182
As there is no longer such a class as CsvImporterDlg - "#6 0x00007f89b2c9cee8 in CsvImporterDlg::validateColumn", I assume that although the bug is entered against git master, the backtrace is from an earlier release. (Or, might the plugin be from an earlier release? If so, be sure to remove that version completely.) The earlier bug backtrace to which you refer looks almost identical. Also, the symbols here appear incomplete. As there has been a previous issue in this area, which was fixed, I really need a backtrace from master to get close enough to see how this relates to the earlier problem. How many hundred columns does your CSV file contain? <BG> I've just successfully imported a 47 column paypal file, with no problem. Could you also provide a sample CSV file which demonstrates the problem. Further, as a get-around if there is still a problem, perhaps you could try removing some unneeded columns?
(In reply to allan from comment #1) > As there is no longer such a class as CsvImporterDlg - > "#6 0x00007f89b2c9cee8 in CsvImporterDlg::validateColumn", > I assume that although the bug is entered against git master, the backtrace > is from an earlier release. (Or, might the plugin be from an earlier > release? If so, be sure to remove that version completely.) The earlier > bug backtrace to which you refer looks almost identical. > Also, the symbols here appear incomplete. > > As there has been a previous issue in this area, which was fixed, I really > need a backtrace from master to get close enough to see how this relates to > the earlier problem. > > How many hundred columns does your CSV file contain? <BG> I've just > successfully imported a 47 column paypal file, with no problem. > > Could you also provide a sample CSV file which demonstrates the problem. > > Further, as a get-around if there is still a problem, perhaps you could try > removing some unneeded columns? Ok, I just don't understand... I removed the 4.6.6 rpms from Fedora and the CSV option is no longer in the File menu. Clearly there was shared code. Could you tell me how to buid with CSV included?
The issue is less the building than the installing. All KDE applications (unless you are extremely careful in the build configuration) install in the same place (or set of places for user and system) so KDE always knows where to look for things like icons, help files, config files, ..... If you run KMM from the build directory, KDE still looks in the system location, so without doing "make install" it will find the system installed plugins and not the ones you just built. If you do "make install" without first uninstalling the distro installed version, you will end up with some mix of files. The CSVimport plugin is built by default when you build from source. However, unless you do "make install" after the "make" KDE will not find it.
On 10/01/14 13:38, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ostroffjh@users.sourceforge > | |.net > > --- Comment #3 from Jack <ostroffjh@users.sourceforge.net> --- > The issue is less the building than the installing. All KDE applications > (unless you are extremely careful in the build configuration) install in the > same place (or set of places for user and system) so KDE always knows where to > look for things like icons, help files, config files, ..... If you run KMM > from the build directory, KDE still looks in the system location, so without > doing "make install" it will find the system installed plugins and not the ones > you just built. If you do "make install" without first uninstalling the distro > installed version, you will end up with some mix of files. > > The CSVimport plugin is built by default when you build from source. However, > unless you do "make install" after the "make" KDE will not find it. The CVS files are in /opt/KMM/lib64, kmymoney in /opt/KMM/bin, still do not have the CVS import option in the File menu, only QIF and GNU Cash seems OFX has also gone missing. I have been doing the make install all along... Oh, by the way, tried kmymoney from the build directory, they are not there either.
Your install dir has to match where KDE expects to find stuff. When you do the initial cmake, what install directory do you specify? It sounds like /opt/KMM. If your distro installed KDE is looking in /usr or /usr/local, then it will never find your plugins under /opt/KMM. You can still use /opt/KMM, but you will then need to alter KDEDIRS and run kbuildsyscoca4 so KDE knows about the new stuff. It's probably easier to just install into /usr/local and remember to "make uninstall" before trying a new version. Again, so you understand, when you run kmymoney from the build directory, the only thing you are getting from there is the single executable file. KDE will still look for all the other stuff: icons, plugins, ... in /usr/local (or wherever it is using.) I really wish it was otherwise, but I've been fighting this issue for a long time, and not very successfully.
(In reply to Jack from comment #5) > Your install dir has to match where KDE expects to find stuff. When you do > the initial cmake, what install directory do you specify? It sounds like > /opt/KMM. If your distro installed KDE is looking in /usr or /usr/local, > then it will never find your plugins under /opt/KMM. You can still use > /opt/KMM, but you will then need to alter KDEDIRS and run kbuildsyscoca4 so > KDE knows about the new stuff. It's probably easier to just install into > /usr/local and remember to "make uninstall" before trying a new version. > > Again, so you understand, when you run kmymoney from the build directory, > the only thing you are getting from there is the single executable file. > KDE will still look for all the other stuff: icons, plugins, ... in > /usr/local (or wherever it is using.) I really wish it was otherwise, but > I've been fighting this issue for a long time, and not very successfully. I completely wiped the git and the rpm installs and then pulled a new git. CVS import now seems to "almost" work. The remaining problem is that when I "Finish" KMM acts as if nothing happened. The manual says it should ask which account, but it does not. Given all the above history of this issue, this could well be another cockpit error.... Any help would be welcome.
As far as I know you need to press 'import' instead of 'finish'.
Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename it 'Exit'. 'Import ' first, though. You should then be there. Do I take it you didn't have the 'Paypal' problem?
Yes - please change Finish to either Close or Exit, and maybe even add an "Are you sure" popup if there has been no import actually done. I've been caught by that myself a few times.
(In reply to allan from comment #8) > Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename > it 'Exit'. 'Import ' first, though. You should then be there. Do I take > it you didn't have the 'Paypal' problem? No problem with paypal. I will try the import later, no time now.
On 02/10/14 19:01, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > --- Comment #9 from Jack <ostroffjh@users.sourceforge.net> --- > Yes - please change Finish to either Close or Exit, and maybe even add an "Are > you sure" popup if there has been no import actually done. I've been caught by > that myself a few times. > Yes, I'll do that. But not now, as it's not as straight forward as I expected, and I don't want to sidetrack just now. The Finish button does actually do that. I can intercept and put up a message, but what happens then is not straight forward. Allan
(In reply to george from comment #10) > (In reply to allan from comment #8) > > Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename > > it 'Exit'. 'Import ' first, though. You should then be there. Do I take > > it you didn't have the 'Paypal' problem? > > No problem with paypal. I will try the import later, no time now. Except for a lot of column missmatch errors it seems to have worked. What are these errors about? Oh, and could you add a way to specify the transaction id? This would avoid dup issues and since PayPal provides them.... -- George
On 03/10/14 23:14, george@wildturkeyranch.net wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > --- Comment #12 from george@wildturkeyranch.net --- > (In reply to george from comment #10) >> (In reply to allan from comment #8) >>> Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename >>> it 'Exit'. 'Import ' first, though. You should then be there. Do I take >>> it you didn't have the 'Paypal' problem? >> >> No problem with paypal. I will try the import later, no time now. > > Except for a lot of column missmatch errors > it seems to have worked. Good. > What are these errors about? Beats me, George. You'll need to be a bit more specific. > Oh, and could you add a way to specify the transaction id? This would avoid dup issues and since PayPal provides them.... > That looks like it needs to be a wish-list item, if you want to do that. The immediate snag I see is that the UI is already very busy. Allan
Since the subject of the report is a crash and it's reported as working in comment #10 using the latest version I'm closing this.