| Summary: | in dolphin i tried to compress a few files in zip...zip was created but ark then crashed | ||
|---|---|---|---|
| Product: | [Applications] ark | Reporter: | Simon Andric <simonandric5> |
| Component: | general | Assignee: | Raphael Kubo da Costa <rakuco> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | simonandric5 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/ark/e21c15b3e048178a8fa7e13e2734d8988221031f | Version Fixed/Implemented In: | 4.9.1 |
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Simon Andric
2012-07-26 01:33:27 UTC
Does it happen at the end of any compression attempt? Could you perhaps attach a set of files that causes this problem for you? hello! sorry for late reply but i was busy at work a lot and didnt get the chance to answer you kind request. i found out it doesnt matter which files i compress this way, one two, more, one file + 1 directory, all kind of files and directoies, with all kind of permissions also,...etc..all variants result in the same action... dolphin - select one or multiple files/directories - right mouse click - compress - as zip archive - = first the ark succesfully builds an archive... then 2 seconds later dr. konqi appears... would you like me to add screenshots also? if so, how can i upload them here*? nice day! symon :) Thanks for the answers. Screenshots don't seem to be useful according to your description of the problem. Does it only happen to ZIP files or does Ark crash if you try to create a rar or a tar.gz archive as well? What if you open Ark and create the archive from there instead of using the context menu in Dolphin? Created attachment 73151 [details]
New crash information added by DrKonqi
ark (2.19) on KDE Platform 4.9.00 using Qt 4.8.3
- What I was doing when the application crashed:
i tried RAR here. as you can see - same result.
nice day
symon
-- Backtrace (Reduced):
#8 0xb58c01cf in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#9 0xb58c3815 in __GI_abort () at abort.c:91
[...]
#13 0xb5bc1ae6 in qt_assert (assertion=0xb77a50f2 "!m_process", file=0xb77a4ff0 "/build/buildd/project-neon-ark-2+git20120722+r2449/kerfuffle/cliinterface.cpp", line=78) at global/qglobal.cpp:2013
#14 0xb779b82e in Kerfuffle::CliInterface::~CliInterface (this=0x90ba1c8, __in_chrg=<optimized out>) at /build/buildd/project-neon-ark-2+git20120722+r2449/kerfuffle/cliinterface.cpp:78
#15 0xb363d5e2 in CliPlugin::~CliPlugin (this=0x90ba1c8, __in_chrg=<optimized out>) at /build/buildd/project-neon-ark-2+git20120722+r2449/plugins/clirarplugin/cliplugin.cpp:45
hello! first - this is strange - i thought when someone replies on at least the bug i reported, not just the bug im subscribed to (i understand this is kde and not launchpad, so prob its a lil' different), i dont get any email notification on my gmail. so by chance if i come here and somehow surf through my reported bugs i by chance see someone replied --- so again i appologize for late reply... i tried to do the same action for compressing both RAR and TAR.GZ files. RAR file - like ZIP file produced the same error _ BUT surprise surprise...TAR/ZIP didnt produce the error (bug report window). i hope this helps... again im sorry for late replies... nice day simon :) (In reply to comment #5) > first - this is strange - i thought when someone replies on at least the bug > i reported, not just the bug im subscribed to (i understand this is kde and > not launchpad, so prob its a lil' different), i dont get any email > notification on my gmail. so by chance if i come here and somehow surf > through my reported bugs i by chance see someone replied --- so again i > appologize for late reply... By default, you should receive an email whenever someone comments on a bug you are CCed to. You can check your email preferences by going to the "Preferences" page and then checking the "Email Preferences" tab. > i tried to do the same action for compressing both RAR and TAR.GZ files. RAR > file - like ZIP file produced the same error _ BUT surprise > surprise...TAR/ZIP didnt produce the error (bug report window). That actually makes sense; can you now just try to create a zip or rar archive by opening Ark directly instead of using Dolphin? hello! #1 thank you for your help in preferences i managed to do it and now i get it on my email.. thank you #2 i tried to do it from within ark and both ZIP and RAR worked... ..first new - save as ..either with zip or rar exnension and then add files, folders ... it loaded them without problems... if i may help more please do say... ... nice day Symon :) Thank you for all the information. I have been occasionally able to reproduce the crash here, and will try to fix it as time allows. hello! if anytime you need any help, im here :) nice day simon ps. you said for yo only sometimes the crash happens. for me its every time if i use dolphin and right click... just said, maybe this informaion also can be helpful for you. Note for future me or anyone else wishing to fix this bug: this is similar to bug 304764/bug 304634 in that we delete the AddToArchive or BatchExtract instance too early; in this case, AddToArchive calls emitResult() when the archive creation finishes, however CliInterface::processFinished() calls list(). This causes a race condition: main.cpp deletes AddToArchive, which later deletes CliInterface, whose destructor may fail at that assertion above since m_process may be not-NULL if the listing is still in progress. Actually, scratch that explanation, a better one is coming with my commit :-) Git commit e21c15b3e048178a8fa7e13e2734d8988221031f by Raphael Kubo da Costa. Committed on 17/08/2012 at 10:04. Pushed by rkcosta into branch 'KDE/4.9'. Delete m_process earlier. Deleting and setting m_process to 0 at the end of runProcess() is sometimes too late. If one connects to KJob::result() to delete an archive interface, that is all going to happen when finished() is emitted in processFinished() and before `delete m_process' is called in runProcess(). This ends up leaving us with a non-NULL m_process, causing the assert in CliInterface's destructor to fail. Delete m_process and set it to 0 in processFinished() itself, since it is not supposed to be used afterwards anyway. Related: bug 301278 FIXED-IN: 4.9.1 M +4 -2 kerfuffle/cliinterface.cpp http://commits.kde.org/ark/e21c15b3e048178a8fa7e13e2734d8988221031f |