Bug 131166 - Konqueror crashed when opening *.zip archive in embedded view
Summary: Konqueror crashed when opening *.zip archive in embedded view
Status: RESOLVED DUPLICATE of bug 94976
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR crash
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-21 15:47 UTC by Andrzej Doyle
Modified: 2006-08-08 20:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrzej Doyle 2006-07-21 15:47:16 UTC
Version:            (using KDE KDE 3.5.3)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
 This shouldn't be relevant as I haven't custom-compiled any KDE components
OS:                Linux

When downloading a ZIP archive (specifically the QuantumDB Eclipse plugin from http://kent.dl.sourceforge.net/sourceforge/quantum/com.quantum.feature_3.0.1.bin.dist.zip) I got the usual dialog asking if I wanted to "Save As", "Open" or "Cancel".  I selected "Open" to open it in the embedded view.  Very shortly after clicking "Open" (about quarter of a second) another, identical dialog box popped up offering me the same choices again.  I clicked "Open" once more, and Konqueror crashed out presenting me with the KDE Crash Handler.

This was rather strange as I'd opened archives in Konqueror before without incident, and I'm fairly sure some of them were zip format.  Choosing "Save As" and opening the file in Ark (version 2.6.3 in case that's important) works fine.  After I've submitted this bug, I'll try and reproduce it in Konqueror, and try other archives of various formats to see how often it occurs.

Backtrace follows:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(no debugging symbols found) x 40
[Thread debugging using libthread_db enabled]
[New Thread -1232434976 (LWP 12437)]
(no debugging symbols found) x 57
[KCrash handler]
#5  0xb71775da in QShared::ref () from /usr/lib/libqt-mt.so.3
#6  0xb756df95 in QString::operator= () from /usr/lib/libqt-mt.so.3
#7  0xb7f2d42d in KParts::URLArgs::operator= () from /usr/lib/libkparts.so.2
#8  0xb7f2d537 in KParts::BrowserExtension::setURLArgs ()
   from /usr/lib/libkparts.so.2
#9  0xb67dbc10 in KonqMainWindow::openView ()
   from /usr/lib/libkdeinit_konqueror.so
#10 0xb67e0844 in KonqRun::foundMimeType ()
   from /usr/lib/libkdeinit_konqueror.so
#11 0xb7f32945 in KParts::BrowserRun::slotBrowserMimetype ()
   from /usr/lib/libkparts.so.2
#12 0xb7f329f9 in KParts::BrowserRun::qt_invoke ()
   from /usr/lib/libkparts.so.2
#13 0xb67ae078 in KonqRun::qt_invoke () from /usr/lib/libkdeinit_konqueror.so
#14 0xb725154b in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#15 0xb7a9196f in KIO::TransferJob::mimetype () from /usr/lib/libkio.so.4
#16 0xb7a919e2 in KIO::TransferJob::slotMimetype () from /usr/lib/libkio.so.4
#17 0xb7ae576d in KIO::TransferJob::qt_invoke () from /usr/lib/libkio.so.4
#18 0xb725154b in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#19 0xb7251a78 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#20 0xb7aa92a3 in KIO::SlaveInterface::mimeType () from /usr/lib/libkio.so.4
#21 0xb7afad43 in KIO::SlaveInterface::dispatch () from /usr/lib/libkio.so.4
#22 0xb7aa2c87 in KIO::SlaveInterface::dispatch () from /usr/lib/libkio.so.4
#23 0xb7aa7b9b in KIO::Slave::gotInput () from /usr/lib/libkio.so.4
#24 0xb7aa7d4b in KIO::Slave::qt_invoke () from /usr/lib/libkio.so.4
#25 0xb725154b in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#26 0xb7251e52 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#27 0xb75e3f7f in QSocketNotifier::activated () from /usr/lib/libqt-mt.so.3
#28 0xb727180a in QSocketNotifier::event () from /usr/lib/libqt-mt.so.3
#29 0xb71e787a in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#30 0xb71e7a76 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#31 0xb78be24e in KApplication::notify () from /usr/lib/libkdecore.so.4
#32 0xb7179001 in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
#33 0xb71d9435 in QEventLoop::activateSocketNotifiers ()
   from /usr/lib/libqt-mt.so.3
#34 0xb718cd06 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#35 0xb7200255 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#36 0xb720017a in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#37 0xb71e638d in QApplication::exec () from /usr/lib/libqt-mt.so.3
#38 0xb67f9895 in kdemain () from /usr/lib/libkdeinit_konqueror.so
#39 0xb7f50524 in kdeinitmain () from /usr/lib/kde3/konqueror.so
#40 0x0804e216 in ?? ()
#41 0x00000002 in ?? ()
#42 0x08090f58 in ?? ()
#43 0x00000001 in ?? ()
#44 0x00000000 in ?? ()
Comment 1 Andrzej Doyle 2006-07-21 15:54:40 UTC
I can pin down the situation when this occurs - it seems that it was caused by the 'auto-download' function of Sourceforge (and presumably other websites).  Essentially, the website had a "this file will download in <i>n</i> seconds, or click here if this doesn't work" feature.  Now for better or worse, I'm impatient enough to click the direct link immediately (when I ask it to download, I don't see why it should wait for a few seconds).

What was happening was that clicking the direct link didn't count as navigating away from the page, so the 5 second timer was still running.  It so happened that *after* I clicked on open, but *before* this link was 'processed' enough to navigate away from the download page, the 5 second timer kicked in and launched another download file dialog.  When I clicked "Open" in this second dialog, it presumably crashed trying to connect to the same resource or somesuch (discovering the cause of this crash I leave to you).

This should be easily reproducible - you don't have to actually click the "Open" button before the second dialog pops up.  Instead, you can click the direct link, then leave the corresponding file download dialog up until the second one auto-launches.  At this point, clicking "Open" on both dialogs causes Konqueror to crash.
Comment 2 Andrzej Doyle 2006-07-21 16:01:18 UTC
As an additional note, this behaviour is independant of the embedded view (or even Ark itself) and seems to be more of a connection-level error.  Regardless of whether you choose "Open" or "Save as" in either of the dialogs (i.e. any of the four possible combinations), Konqueror crashes out when the second connection is attempted.  (FYI, any file download windows stay open, but the download itself no longer progresses.)

Of course, now I know about this behaviour I can work around it easily, but it does seem to suggest a more serious underlying bug (as well as being frustrating for those who don't know the cause).  As I don't know enough C to delve into the source code, I leave it in the capable hands of the community to come up with a patch.
Comment 3 Tommi Tervo 2006-08-08 20:28:55 UTC

*** This bug has been marked as a duplicate of 94976 ***