Application: ark (16.08.2) Qt Version: 5.7.0 Frameworks Version: 5.27.0 Operating System: Linux 4.8.6-300.fc25.x86_64 x86_64 Distribution (Platform): Fedora RPMs -- Information about the crash: - What I was doing when the application crashed: 1. open with dolphin a directory with the rar archive 2. select rar archive 3. right mous button 4. Extract -> Extract archive here, autodetect subfolder 5. crash -- Backtrace: Application: Ark (ark), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f208b3e6480 (LWP 9283))] Thread 3 (Thread 0x7f2077fff700 (LWP 9285)): #0 0x00007f209614c00d in poll () at /lib64/libc.so.6 #1 0x00007f2090214156 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #2 0x00007f209021426c in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007f2096f51d8b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #4 0x00007f2096f030ba in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #5 0x00007f2096d60643 in QThread::exec() () at /lib64/libQt5Core.so.5 #6 0x00007f20981287a9 in QDBusConnectionManager::run() () at /lib64/libQt5DBus.so.5 #7 0x00007f2096d64a1a in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #8 0x00007f2094b296ca in start_thread () at /lib64/libpthread.so.0 #9 0x00007f2096157f6f in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7f20800ab700 (LWP 9284)): #0 0x00007f209614c00d in poll () at /lib64/libc.so.6 #1 0x00007f208f908d10 in _xcb_conn_wait () at /lib64/libxcb.so.1 #2 0x00007f208f90aaa9 in xcb_wait_for_event () at /lib64/libxcb.so.1 #3 0x00007f2084751a19 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5 #4 0x00007f2096d64a1a in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #5 0x00007f2094b296ca in start_thread () at /lib64/libpthread.so.0 #6 0x00007f2096157f6f in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f208b3e6480 (LWP 9283)): [KCrash Handler] #6 0x00007f209608592f in raise () at /lib64/libc.so.6 #7 0x00007f209608752a in abort () at /lib64/libc.so.6 #8 0x00007f20969c74fd in __gnu_cxx::__verbose_terminate_handler() () at /lib64/libstdc++.so.6 #9 0x00007f20969c52a6 in () at /lib64/libstdc++.so.6 #10 0x00007f20969c52f1 in () at /lib64/libstdc++.so.6 #11 0x00007f20969c5509 in () at /lib64/libstdc++.so.6 #12 0x00007f2096d4af42 in () at /lib64/libQt5Core.so.5 #13 0x00007f2096dde47d in QString::reallocData(unsigned int, bool) () at /lib64/libQt5Core.so.5 #14 0x00007f2096ddea84 in QString::append(QString const&) () at /lib64/libQt5Core.so.5 #15 0x00007f207c361862 in CliPlugin::handleLine(QString const&) () at /usr/lib64/qt5/plugins/kerfuffle/kerfuffle_cliunarchiver.so #16 0x00007f209bac2c64 in Kerfuffle::CliInterface::readStdout(bool) () at /lib64/libkerfuffle.so.16 #17 0x00007f2096f2aff1 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5 #18 0x00007f2096e5d008 in QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) () at /lib64/libQt5Core.so.5 #19 0x00007f2096e5d370 in QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () at /lib64/libQt5Core.so.5 #20 0x00007f2096f2aff1 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5 #21 0x00007f2096f9ad7e in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /lib64/libQt5Core.so.5 #22 0x00007f2096f37102 in QSocketNotifier::event(QEvent*) () at /lib64/libQt5Core.so.5 #23 0x00007f209774c96c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #24 0x00007f2097754111 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #25 0x00007f2096f0412a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5 #26 0x00007f2096f5269f in socketNotifierSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5 #27 0x00007f2090213e42 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #28 0x00007f20902141c0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #29 0x00007f209021426c in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #30 0x00007f2096f51d6f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #31 0x00007f2096f030ba in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #32 0x00007f209ba9d8a2 in Kerfuffle::Archive::listIfNotListed() () at /lib64/libkerfuffle.so.16 #33 0x00007f209ba9d8d8 in Kerfuffle::Archive::isSingleFolderArchive() () at /lib64/libkerfuffle.so.16 #34 0x000055ea5689ec67 in BatchExtract::addExtraction(Kerfuffle::Archive*) () #35 0x000055ea5689fc0b in BatchExtract::slotStartJob() () #36 0x00007f2096f37266 in QSingleShotTimer::timerEvent(QTimerEvent*) () at /lib64/libQt5Core.so.5 #37 0x00007f2096f2c08b in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5 #38 0x00007f209774c96c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #39 0x00007f2097754111 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #40 0x00007f2096f0412a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5 #41 0x00007f2096f5138b in QTimerInfoList::activateTimers() () at /lib64/libQt5Core.so.5 #42 0x00007f2096f518e1 in timerSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5 #43 0x00007f2090213e42 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #44 0x00007f20902141c0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #45 0x00007f209021426c in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #46 0x00007f2096f51d6f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #47 0x00007f2096f030ba in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #48 0x00007f2096f0abac in QCoreApplication::exec() () at /lib64/libQt5Core.so.5 #49 0x000055ea5689b4c4 in main () Reported using DrKonqi
Does it crash every time? Can you attach the archive here?
Yes it chrashes every time. (Have just tried again) I am using [unar.x86_64 1.10.1-1.fc25 @fedora] as the rar extractor. I can not attach archive here direct (227,7 MB > 4 MB), but I have uploaded it at my cloud instance, and here is the link: https://datacloud.nextnetworks.eu/index.php/s/6xszdJX48JKT8oX (this link will be valid till 15-11-2016)
Confirmed, thanks for the archive. Ark cannot even open it, it just goes out of memory while trying to allocate the JSON object with the data provided by lsar.
Thanks for your fast reaction! If I can help you to fix this bug, just say. I am not a super hacker but have some C++/Qt knowledge.
(In reply to Nikolay Brookstein from comment #4) > Thanks for your fast reaction! > If I can help you to fix this bug, just say. > I am not a super hacker but have some C++/Qt knowledge. That would be very appreciated. The problem is clear: the crash happens in plugins/cliunarchiverplugin/plugin.cpp at this line: m_jsonOutput += line + QLatin1Char('\n'); which is a QString that tries to allocate too much data. That QString is then supposed to be converted to QJsonDocument. We could try to save the json output of lsar to a temporary file and get rid of this QString, but I'm not sure Qt can handle json files that large. In the meantime, honestly I suggest you try to install unrar as the unrar plugin can open this archive just fine...
(In reply to Elvis Angelaccio from comment #5) > (In reply to Nikolay Brookstein from comment #4) > I'm not sure Qt can handle json files that large. We are talking about a json file bigger than 3 GB, in fact. No way a parser can handle that much data :/ Even if we skip the "XADSolidObject" json vector (which is what makes the file so big), lsar would still take too much time to finish the execution (compared to unrar). So I'm tempted to just catch the bad_alloc exception and abort the operation...
What is the difference between unrar and unar approaches? It is really strange, to get over 3 GB memory allocation fo a ~240MB file. It looks like coner case or a totally inefficient implementation from unar side. Probably Ark just need a better backend error detection, and a bug is in unar. Or I am wrong here? (That are just my thoughts, I am not an expert in rar/unar/unrar) P.S. I will look in a source file tomorrow.
(In reply to Nikolay Brookstein from comment #7) > What is the difference between unrar and unar approaches? > It is really strange, to get over 3 GB memory allocation fo a ~240MB file. > It looks like coner case or a totally inefficient implementation from unar > side. > Probably Ark just need a better backend error detection, and a bug is in > unar. Or I am wrong here? > (That are just my thoughts, I am not an expert in rar/unar/unrar) > > P.S. I will look in a source file tomorrow. Yes, ideally a bug should also be filed against unar.
Created attachment 102135 [details] Catch bad_alloc patch With this patch Ark doesn't crash, at least.
I have just created a bug report at the unarchiver bug tracker: https://bitbucket.org/WAHa_06x36/theunarchiver/issues/919/unarchiver-crash-while- trying-to-open-or Elvis, "Archive too big" is probably some how confusing. Possibly "Archive can not be extracted due to insufficient free memory"?
oops, the same URl without line break: https://bitbucket.org/WAHa_06x36/theunarchiver/issues/919/unarchiver-crash-while-trying-to-open-or
(In reply to Nikolay Brookstein from comment #10) > I have just created a bug report at the unarchiver bug tracker: > https://bitbucket.org/WAHa_06x36/theunarchiver/issues/919/unarchiver-crash- > while- > trying-to-open-or Thanks for reporting it upstream! > > Elvis, "Archive too big" is probably some how confusing. > Possibly "Archive can not be extracted due to insufficient free memory"? Yeah, this is just a temporary patch so that I won't forget it :p
No problem, without bug reports bugs will never be fixed ^_^ As far as I have understood, KDE/Plasma/KF are all Qt based, so why you are using 'i18n("Blabla")' instead of 'tr("Blabla")' Btw, you are the main maintainer of Ark right now? If yes, some offtopic question from my side, is it possible to make a progress indication in Ark, or the current architecture is not sutable for the such kind of functionality?
Our translation infrastructure is based on GNU 'gettext'; we do not use the Qt translation system.
(In reply to Christoph Feck from comment #14) > Our translation infrastructure is based on GNU 'gettext'; we do not use the > Qt translation system. Thank you for the clarification. Is gettext technically better than the Qt translation system? What is the reason of using it?
https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems does not list any technical differences, so it might be because of historical reasons. Switching the complete infrastructure was never considered.
(In reply to Nikolay Brookstein from comment #13) > No problem, without bug reports bugs will never be fixed ^_^ > > As far as I have understood, KDE/Plasma/KF are all Qt based, > so why you are using 'i18n("Blabla")' instead of 'tr("Blabla")' > > Btw, you are the main maintainer of Ark right now? > If yes, some offtopic question from my side, is it possible to make a > progress indication in Ark, or the current architecture is not sutable for > the such kind of functionality? Feel free to join the #kde-utils IRC channel and we can discuss everything you want :)
@Nikolay: patch up for review: https://phabricator.kde.org/D3350
Git commit 0b981c544e994175403504124a1e44ecfa144e33 by Elvis Angelaccio. Committed on 15/11/2016 at 18:23. Pushed by elvisangelaccio into branch 'master'. Stop crashing when lsar's output is too big lsar can generate huge json output when listing big solid rar archives. This will be fixed in lsar, but meanwhile we can catch a bad_alloc if we're using an affected version of lsar. FIXED-IN: 16.12.0 Differential Revision: D3350 M +3 -0 autotests/plugins/cliunarchiverplugin/CMakeLists.txt M +3 -0 plugins/cliunarchiverplugin/CMakeLists.txt M +9 -1 plugins/cliunarchiverplugin/cliplugin.cpp http://commits.kde.org/ark/0b981c544e994175403504124a1e44ecfa144e33