| Summary: | Qupzilla causes Konqueror / Ark to crash | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kristopher <gamrat.kristopher> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEW --- | ||
| Severity: | minor | CC: | bugwatch, gamrat.kristopher, kb9vqf |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
Backtrace of Konqueror crash described
New backtrace with tdeutils-trinity-dbg Backtrace of this crash from a fairly new VM |
||
Can you try this again with the tdelibs-trinity-dbg package installed? Even better would be to use the Report Crash feature and post the crash ID to this report; using that feature makes the developers' lives a bit easier as it provides additional information and displays the trace in an easier-to-use format. Thanks! (In reply to Timothy Pearson from comment #1) > Can you try this again with the tdelibs-trinity-dbg package installed? Already installed since some months prior to this crash, and I always allow it to upgrade when it appears in "apt-get dist-upgrade". > Even better would be to use the Report Crash feature and post the crash ID > to this report; using that feature makes the developers' lives a bit easier > as it provides additional information and displays the trace in an > easier-to-use format. Where would I find this? (In reply to Kristopher from comment #2) > (In reply to Timothy Pearson from comment #1) > > Can you try this again with the tdelibs-trinity-dbg package installed? > > Already installed since some months prior to this crash, and I always allow > it to upgrade when it appears in "apt-get dist-upgrade". That's strange; gdb didn't print line number information in the crash dump. Maybe try installing tdeutils-trinity-dbg as well? > > Even better would be to use the Report Crash feature and post the crash ID > > to this report; using that feature makes the developers' lives a bit easier > > as it provides additional information and displays the trace in an > > easier-to-use format. > > Where would I find this? On the crash popup dialog there is a button on the bottom labelled "Report Crash" or similar. Click it and follow the instructions, then once the crash report has been submitted and you receive a popup with the "TDECRSH-<numbers here>" text just copy+paste that ID to this report. Thanks! Created attachment 2388 [details]
New backtrace with tdeutils-trinity-dbg
(In reply to Timothy Pearson from comment #3) > (In reply to Kristopher from comment #2) > > (In reply to Timothy Pearson from comment #1) > > > Can you try this again with the tdelibs-trinity-dbg package installed? > > > > Already installed since some months prior to this crash, and I always allow > > it to upgrade when it appears in "apt-get dist-upgrade". > > That's strange; gdb didn't print line number information in the crash dump. > Maybe try installing tdeutils-trinity-dbg as well? Attached. > > > Even better would be to use the Report Crash feature and post the crash ID > > > to this report; using that feature makes the developers' lives a bit easier > > > as it provides additional information and displays the trace in an > > > easier-to-use format. > > > > Where would I find this? > > On the crash popup dialog there is a button on the bottom labelled "Report > Crash" or similar. Click it and follow the instructions, then once the > crash report has been submitted and you receive a popup with the > "TDECRSH-<numbers here>" text just copy+paste that ID to this report. Clicking that button produce a dialog entitled "Backtrace Not Possible - The TDE Crash Handler" with the message "It was not possible to generate a backtrace.". (In reply to Kristopher from comment #5) > (In reply to Timothy Pearson from comment #3) > > (In reply to Kristopher from comment #2) > > > (In reply to Timothy Pearson from comment #1) > > > > Can you try this again with the tdelibs-trinity-dbg package installed? > > > > > > Already installed since some months prior to this crash, and I always allow > > > it to upgrade when it appears in "apt-get dist-upgrade". > > > > That's strange; gdb didn't print line number information in the crash dump. > > Maybe try installing tdeutils-trinity-dbg as well? > > Attached. > > > > > Even better would be to use the Report Crash feature and post the crash ID > > > > to this report; using that feature makes the developers' lives a bit easier > > > > as it provides additional information and displays the trace in an > > > > easier-to-use format. > > > > > > Where would I find this? > > > > On the crash popup dialog there is a button on the bottom labelled "Report > > Crash" or similar. Click it and follow the instructions, then once the > > crash report has been submitted and you receive a popup with the > > "TDECRSH-<numbers here>" text just copy+paste that ID to this report. > > Clicking that button produce a dialog entitled "Backtrace Not Possible - The > TDE Crash Handler" with the message "It was not possible to generate a > backtrace.". Oh that's right, I forgot you were the one suffering from Bug 2227. :-) (In reply to Kristopher from comment #4) > Created attachment 2388 [details] > New backtrace with tdeutils-trinity-dbg Something's still not right; output like this: #6 0x00007f4a9817dfea in ArkWidget::openArchive(TQString const&, TQString const&) () from /opt/trinity/lib/trinity/libarkpart.so won't help me debug this and in fact indicates that the debug symbols are mismatched from the libraries on your system. This is not good and may indicate this crash is related to mixed library versions rather than a defect in TDE itself. Can you post the output of: dpkg -S /opt/trinity/lib/trinity/libarkpart.so Thanks! (In reply to Timothy Pearson from comment #7) > (In reply to Kristopher from comment #4) > > Created attachment 2388 [details] > > New backtrace with tdeutils-trinity-dbg > > Something's still not right; output like this: > #6 0x00007f4a9817dfea in ArkWidget::openArchive(TQString const&, TQString > const&) () from /opt/trinity/lib/trinity/libarkpart.so > > won't help me debug this and in fact indicates that the debug symbols are > mismatched from the libraries on your system. This is not good and may > indicate this crash is related to mixed library versions rather than a > defect in TDE itself. If this is the case, I can confirm it isn't caused by my installation: all of my TDE packages are from R14, and I confirmed this morning that they were up-to-date. Also, I removed all traces of Debian Backports (save for the kernel and my IM client) after the backtrace issues from bug #2226 and now run an almost pure-stable version of Debian Wheezy. Also, I confirmed this morning that my system is fully up-to-date. > Can you post the output of: > dpkg -S /opt/trinity/lib/trinity/libarkpart.so root@Piki-PC:~# dpkg -S /opt/trinity/lib/trinity/libarkpart.so ark-trinity: /opt/trinity/lib/trinity/libarkpart.so Thank you for the information. Yes, your system looks good; I am not sure why gdb is failing but it looks like we will have to reproduce the bug instead of relying on your backtrace. Thanks for trying to generate a more useful backtrace! I looked at the backtrace more carefully and ran across this: Reading symbols from /opt/trinity/lib/trinity/libarkpart.so... warning: the debug information found in "/usr/lib/debug//opt/trinity/lib/trinity/libarkpart.so" does not match "/opt/trinity/lib/trinity/libarkpart.so" (CRC mismatch). Is there any chance you have an old libarkpart.so laying around that isn't under dpkg control? (In reply to Timothy Pearson from comment #10) > I looked at the backtrace more carefully and ran across this: > Reading symbols from /opt/trinity/lib/trinity/libarkpart.so... > warning: the debug information found in > "/usr/lib/debug//opt/trinity/lib/trinity/libarkpart.so" does not match > "/opt/trinity/lib/trinity/libarkpart.so" (CRC mismatch). > > Is there any chance you have an old libarkpart.so laying around that isn't > under dpkg control? Not that I'm aware of. Created attachment 2390 [details]
Backtrace of this crash from a fairly new VM
This backtrace comes from this same bug reproduced within a VM that I recently set up. It does not contain any "CRC mismatch" errors or the like.
Since I get the mismatches on my host installation but not in the VM, I am wandering of something got corrupted or misplaced during a dist-upgrade -- the host has been running the nightlies for quite some time, while the VM is barely a week old..
(In reply to Kristopher from comment #12) > Created attachment 2390 [details] > Backtrace of this crash from a fairly new VM > > This backtrace comes from this same bug reproduced within a VM that I > recently set up. It does not contain any "CRC mismatch" errors or the like. > > Since I get the mismatches on my host installation but not in the VM, I am > wandering of something got corrupted or misplaced during a dist-upgrade -- > the host has been running the nightlies for quite some time, while the VM is > barely a week old.. Thanks, that's much better! Is Bug 2227 an issue on the VM as well? Tim (In reply to Kristopher from comment #12) > Created attachment 2390 [details] > Backtrace of this crash from a fairly new VM > > This backtrace comes from this same bug reproduced within a VM that I > recently set up. It does not contain any "CRC mismatch" errors or the like. I've been having difficulty reproducing this, and hte backtrace is occurring in a rather strange location requiring the use of Valgrind. Can you post detailed replication instructions? I assume this crashes on opening any type of archive; does this URL crash ark for you? http://www.mirrorservice.org/sites/trinitydesktop.org/trinity/releases/3.5.13.2/kdeaddons-trinity-3.5.13.2.tar.xz Thanks! Tim (In reply to Timothy Pearson from comment #14) > (In reply to Kristopher from comment #12) > > Created attachment 2390 [details] > > Backtrace of this crash from a fairly new VM > > > > This backtrace comes from this same bug reproduced within a VM that I > > recently set up. It does not contain any "CRC mismatch" errors or the like. > > I've been having difficulty reproducing this, and hte backtrace is occurring > in a rather strange location requiring the use of Valgrind. > > Can you post detailed replication instructions? 1. Browse to a web page in Qupzilla (maybe other browsers will work?) with a link to an archive. 2. Click the link. 3. Choose the option to "Open" the file (instead of the "Save" option). 4. The file should download, auto-launch Ark, then bring up the TDE Crash Handler. I don't know if it's strictly required to open an archive from a web page for this bug, but it does *not* happen when opening an archive directly from within Konqueror or Ark. > I assume this crashes on > opening any type of archive; does this URL crash ark for you? > http://www.mirrorservice.org/sites/trinitydesktop.org/trinity/releases/3.5. > 13.2/kdeaddons-trinity-3.5.13.2.tar.xz That seems to open fine for me. I discovered this bug by accident attempting to open the VirtualBox Extension Pack from https://www.virtualbox.org/wiki/Downloads , which Ark can open directly as a GZip archive but which causes this crash when I ask Qupzilla to open it after clicking the link. (and no, I wasn't expecting Qupzilla to attempt to use Ark/Konqueror to open the file in question, I was expecting it to open in the rather obvious VirtualBOX application) (In reply to Timothy Pearson from comment #13) > (In reply to Kristopher from comment #12) > > Created attachment 2390 [details] > > Backtrace of this crash from a fairly new VM > > > > This backtrace comes from this same bug reproduced within a VM that I > > recently set up. It does not contain any "CRC mismatch" errors or the like. > > > > Since I get the mismatches on my host installation but not in the VM, I am > > wandering of something got corrupted or misplaced during a dist-upgrade -- > > the host has been running the nightlies for quite some time, while the VM is > > barely a week old.. > > Thanks, that's much better! > > Is Bug 2227 an issue on the VM as well? > > Tim Strangely, no, it doesn't. I'm able to generate backtraces using the TDE Crash Handler in the VM. (In reply to Kristopher from comment #16) > (In reply to Timothy Pearson from comment #13) > > (In reply to Kristopher from comment #12) > > > Created attachment 2390 [details] > > > Backtrace of this crash from a fairly new VM > > > > > > This backtrace comes from this same bug reproduced within a VM that I > > > recently set up. It does not contain any "CRC mismatch" errors or the like. > > > > > > Since I get the mismatches on my host installation but not in the VM, I am > > > wandering of something got corrupted or misplaced during a dist-upgrade -- > > > the host has been running the nightlies for quite some time, while the VM is > > > barely a week old.. > > > > Thanks, that's much better! > > > > Is Bug 2227 an issue on the VM as well? > > > > Tim > > Strangely, no, it doesn't. I'm able to generate backtraces using the TDE > Crash Handler in the VM. I'm starting to think TDE might be queuing on on that CRC mismatch and refusing (correctly) to generate backtraces. Not sure though, so I'm just going to leave the bug open for now. If you don't mind updating the other report with this information I'd appreciate it. Thanks! (In reply to Kristopher from comment #15) > (In reply to Timothy Pearson from comment #14) > > (In reply to Kristopher from comment #12) > > > Created attachment 2390 [details] > > > Backtrace of this crash from a fairly new VM > > > > > > This backtrace comes from this same bug reproduced within a VM that I > > > recently set up. It does not contain any "CRC mismatch" errors or the like. > > > > I've been having difficulty reproducing this, and hte backtrace is occurring > > in a rather strange location requiring the use of Valgrind. > > > > Can you post detailed replication instructions? > > 1. Browse to a web page in Qupzilla (maybe other browsers will work?) with a > link to an archive. > 2. Click the link. > 3. Choose the option to "Open" the file (instead of the "Save" option). > 4. The file should download, auto-launch Ark, then bring up the TDE Crash > Handler. > > I don't know if it's strictly required to open an archive from a web page > for this bug, but it does *not* happen when opening an archive directly from > within Konqueror or Ark. > > > I assume this crashes on > > opening any type of archive; does this URL crash ark for you? > > http://www.mirrorservice.org/sites/trinitydesktop.org/trinity/releases/3.5. > > 13.2/kdeaddons-trinity-3.5.13.2.tar.xz > > That seems to open fine for me. > > I discovered this bug by accident attempting to open the VirtualBox > Extension Pack from https://www.virtualbox.org/wiki/Downloads , which Ark > can open directly as a GZip archive but which causes this crash when I ask > Qupzilla to open it after clicking the link. > > (and no, I wasn't expecting Qupzilla to attempt to use Ark/Konqueror to open > the file in question, I was expecting it to open in the rather obvious > VirtualBOX application) Which file were you downloading? Did you open with ark or konqeror? (In reply to Timothy Pearson from comment #18) > (In reply to Kristopher from comment #15) > > (In reply to Timothy Pearson from comment #14) > > > (In reply to Kristopher from comment #12) > > > > Created attachment 2390 [details] > > > > Backtrace of this crash from a fairly new VM > > > > > > > > This backtrace comes from this same bug reproduced within a VM that I > > > > recently set up. It does not contain any "CRC mismatch" errors or the like. > > > > > > I've been having difficulty reproducing this, and hte backtrace is occurring > > > in a rather strange location requiring the use of Valgrind. > > > > > > Can you post detailed replication instructions? > > > > 1. Browse to a web page in Qupzilla (maybe other browsers will work?) with a > > link to an archive. > > 2. Click the link. > > 3. Choose the option to "Open" the file (instead of the "Save" option). > > 4. The file should download, auto-launch Ark, then bring up the TDE Crash > > Handler. > > > > I don't know if it's strictly required to open an archive from a web page > > for this bug, but it does *not* happen when opening an archive directly from > > within Konqueror or Ark. > > > > > I assume this crashes on > > > opening any type of archive; does this URL crash ark for you? > > > http://www.mirrorservice.org/sites/trinitydesktop.org/trinity/releases/3.5. > > > 13.2/kdeaddons-trinity-3.5.13.2.tar.xz > > > > That seems to open fine for me. > > > > I discovered this bug by accident attempting to open the VirtualBox > > Extension Pack from https://www.virtualbox.org/wiki/Downloads , which Ark > > can open directly as a GZip archive but which causes this crash when I ask > > Qupzilla to open it after clicking the link. > > > > (and no, I wasn't expecting Qupzilla to attempt to use Ark/Konqueror to open > > the file in question, I was expecting it to open in the rather obvious > > VirtualBOX application) > > Which file were you downloading? Did you open with ark or konqeror? I'm using the VirtualBox Extension Pack, it doesn't seem to matter which one is used since they all produce the same crash, but just for the sake of convenience here's a link to one of them: http://download.virtualbox.org/virtualbox/4.3.20/Oracle_VM_VirtualBox_Extension_Pack-4.3.20-96996.vbox-extpack I'm not deciding which program to open the file with when the crash occurs. Qupzilla decides automatically and does not offer an option to override it, nor does it tell me what it's going to use. My guess is that it decides based on MIME Type associations information provided by the DE it's running under, and if that's true it's *probably* trying to use Ark since that's what it opens in when I download it and open it from Konqueror's file manager mode. Thanks for the info. My qupzilla installation does not attempt to open the vbox extension file via ark, and opening the downloaded file directly (even via Konqueror embedding) does not cause ark to crash. At this point I'm just going to triage this bug for another devleoper to pick up in the future. |
Created attachment 2387 [details] Backtrace of Konqueror crash described Attempting to have a web browser other than Konqueror attempt to open an archive from the Internet causes Konqueror to crash when Ark attempts to open the archive. A gdb backtrace is attached. I doubt it matters, but just in case, the browser I used is Qupzilla, a Qt4 + WebKit browser, installed from Debian package provided by the Qupzilla website.