| Summary: | Konqueror crash | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, darrella, kb9vqf, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2014 | ||
| Attachments: |
kcrash backtrace of konqueror crash
Another kcrash backtrace Crash backtrace |
||
Created attachment 1860 [details]
Another kcrash backtrace
Looks much the same as the first backtrace
The backtraces produced by this crash are not helpful, but the crashes occur frequently enough to be more than nuisance. File managers should not crash. :) I am not sure, but the crash might have to do with either the amount of time konqueror is open or the number of tabs opened. That is when I notice the crashes. There does not seem to be any damage from the crash, although I lose all open tabs, which sometimes is many. As far as I can remember, I always have been performing a move operation, moving files from one directory to another. Typically within the same tab, such as moving the files down a directory. Darrell, is this still happening? Can you reproduce it systematically? If so, could you post a sequence of steps? Still valid. Very annoying and causes loss of productivity. I cannot force the bug and the crash moment is not predictable. As noted, the bug is related to either the length of time konqueror is open or the number of tabs, but probably both. My wild guess is some kind of runaway process or memory leak based upon the combination of the number of tabs and the length of time open. By length of time I am talking about several hours --- as in all day. As most people don't work that way, debugging is a challenge. I only work that way when I am deep in building and testing patches. Then I'll have many tabs open because I use different folder locations. I'll have open my package folder, the Trinity git tree, my build folder, temporary scratch folders, etc. In this condition I have seen konq crash on its own without me doing anything. Hi Darrell, the crash reports do not provide much info, so fixing this bug may prove a challenge, unless you can somehow find a way to reproduce it systematically, so that I can also reproduce it on my system. I understand from your previous comments that this may be quite difficult. Anyhow I made some small changes to qt3/tqt3 which may (hopefully) help with this problem (especially one where an object was self-deleting). Could you try the new code and report back? If the crashes still happen, please attach an updated crash report or even better send it in with DrKonqi and then let me know the crash ID. Thanks. Hi Darrell, any luck with the latest code (see my previous comment) ? Still crashing? As mentioned in comment 4, I cannot force this bug and the bug occurs only under a specific use case. Currently I am spending little time with computers, let alone Trinity. Thus I am not available right now to create the conditions for that use case. Ok, thanks for the update. If in future you have a chance to experience the problem again, please let me know. Created attachment 2256 [details]
Crash backtrace
I don't know whether this crash is related. I had three tabs open. Konqueror was idling in the background as I had been reading online in Firefox for some time. Suddenly I received the crash dialog despite not doing anything with konqueror for at least a half-hour. My GIT build set is from Aug. 25. I am attaching the backtrace.
Thanks Darrell, I will take a look when time permits that :-) Comment on attachment 2256 [details]
Crash backtrace
Crashes of this form should be fixed in GIT hash dc94a41.
Regarding the remaining crash, I can reasonably surmise that the rest of the backtrace is: In KonqDirPart::slotClipboardDataChanged() konq_dirpart.cc:428 This seems strongly related to the clipboard contents, as the crash occurs after the dataChanged() signal of TQApplication::clipboard() is emitted. Darrell, when you are copying the files and Konqueror crashes, are you doing anything at all with the clipboard right before the crash occurs? Thanks! >Crashes of this form should be fixed in GIT hash dc94a41. Okay. Thanks. I do not know whether the crash seen in the second backtrace is the same as the original bug report. Hence we need to keep this bug report open. As I mentioned in the discussion, I can't force the crash seen in the original bug report. I have to wait and see and hopefully next time, if ever, I get a useful backtrace. >are you doing anything at all with the clipboard right before the crash occurs? Not that I am aware. I use Klipper a lot to fetch previous copies, but I never paid attention to whether I had accessed Klipper just before attempting to copy and paste files in Konqueror. That said, there are three open bug reports that might be related: bug 903, bug 1716, bug 2096. (In reply to Darrell from comment #13) > >Crashes of this form should be fixed in GIT hash dc94a41. > Okay. Thanks. I do not know whether the crash seen in the second backtrace > is the same as the original bug report. Hence we need to keep this bug > report open. As I mentioned in the discussion, I can't force the crash seen > in the original bug report. I have to wait and see and hopefully next time, > if ever, I get a useful backtrace. I repaired crashes of the last type reported, not of the original type reported. Hence my question on whether you were using the clipboard. :-) I am working on the original; there is probably enough information for me to take a stab at fixing it at least. (In reply to Darrell from comment #0) > Created attachment 1859 [details] > kcrash backtrace of konqueror crash > > I've had this happen a few times. All I was doing was moving files from one > folder to another (copying and pasting). > > The attached backtrace is not much but is all I have. This is an old KDE bug (surprise surprise): https://bugs.kde.org/show_bug.cgi?id=148279 All I can tell at the moment is that something (I have no idea what) is corrupting the TQClipboardWatcher formatList object. Still digging... This should be fixed in GIT hashes dc8f537 (qt3) and 6e8d2d2 (tqt3). The root flaw has been dormant in Qt3 for a long time; as far as I can tell undefined behaviour was invoked in a very specific set of circumstances when new data was placed on the system clipboard. The original Qt3 authors overrode a const class method in the clipboard data watcher by casting pointers; as far as I can tell this action, coupled with a class member reallocating an internal pointer when specific circumstances were present, caused a sporadic crash. I'm going to go ahead and close this report. If the crash should recur with TQClipboardWatcher::format in the backtrace please reopen it. Thanks for reporting, and for the critical backtraces! |
Created attachment 1859 [details] kcrash backtrace of konqueror crash I've had this happen a few times. All I was doing was moving files from one folder to another (copying and pasting). The attached backtrace is not much but is all I have.