Am Montag, 6. August 2012 schrieb Nick Boyce: > On Friday 27 Jul 2012 17:46:38 Martin Steigerwald wrote: > > Am Donnerstag, 26. Juli 2012 schrieb Nick Boyce: > [...] > > > > So I have a 3-star backtrace now - thanks everyone, and off to > > > bugs.kde.org I go. > > > > Please have a look whether your backtrace is similar to what I > > reported: Bug 303914 - Crashes on accessing certain URLs > > https://bugs.kde.org/show_bug.cgi?id=303914 > > Hmm ... I don't know enough about analysing these backtraces, but - > assuming I understand how to determine the call stack that lead to the > crash (a big area of doubt [1]) - then no, I don't think we have > similar crashes. > > The one in your bug report looks like this (just the first 12 entries) > : > > Thread 1 (Thread 0x7f97bd3d5760 (LWP 8092)): > [KCrash Handler] > #6 hash (key=...) at rendering/RenderTextControl.cpp:663 > #7 hash (key=...) at ../JavaScriptCore/wtf/HashTable.h:281 […] > whereas the crash I experienced looks like this : > > Thread 1 (Thread 0x7f895214e760 (LWP 2221)): > [KCrash Handler] > #5 DOM::DocumentImpl::paintDevice (value=0x6c67110, style=0x7105f10, > part=0x724b7c0, op=MinPrefix) at ../../khtml/xml/dom_docimpl.h:378 > #6 widthMediaFeatureEval (value=0x6c67110, style=0x7105f10, […]
Looks different to me but sometimes just the thread order is different, so its beneficial to see the whole backtrace. > In both cases we're rendering some content (duh), but it looks like > yours involves Javascript while mine involves CSS. ;) > I don't imagine there's much benefit in comparing our crash symptoms > anyway, given you're using Wheezy/4.8.4 and I'm using Squeeze/4.4.5 - > unless it highlighted common code areas, that .. [cough] .. hadn't > improved in two years > > :) Yeah, especially as I got these crashes only since KDE SC 4.8.x upgrades. So I don´t know why I suggested comparing the backtrace anyway at the moment. > > I have several URLs where it crashes 100% reproducably. Two of them > > in above bug report. I didn´t note all of them. > > I haven't found a URL which causes the crash reproducibly yet ... I > always have several tabs open at the time, and the only pattern I've > noticed is that clicking 'Back' on one of them is very often the last > thing I did. Once the crash happens, it almost always gets stuck in > that state - i.e. I can't resume the session on Konqueror restart cos > the crash just keeps repeating - I have to start a fresh session to > continue surfing. Hmmm. I don´t remember having that with Squeeze back then. But then I often also use Iceweasel, cause Konqueror doesn´t display quite some webpages correctly. Neither with KHTML nor with Webkit. > > Whats strange here is that Konqueror reports: > > > > martin@merkaba:~> konqueror --version > > Qt: 4.8.2 > > KDE: 4.8.4 (4.8.4) > > Konqueror: 4.8.3 (4.8.3) > > > > while 4.8.4 packages are installed. > > That is bizarre, and seems likely a packaging fault. > > It's different here of course : > > nick@mybox:~$ konqueror --version > Qt: 4.6.3 > KDE Development Platform: 4.4.5 (KDE 4.4.5) > Konqueror: 4.4.5 (KDE 4.4.5) > > > Good luck :) To you too ;) > [1] I assume that when a backtrace begins with the words "Current > thread is 1" then that is the thread which *caused* the crash ... and > not the thread which *handled* the crash, or something silly. I've > looked at http://techbase.kde.org/Development/Tutorials but it doesn't > help with this. I usually just look at the whole backtraces and seek for similarities. I found that the order can be slightly different in different backtraces. I bet due to different timings. > BTW: I rather like the sound of the Kubuntu utility 'apport-retrace' > described at https://wiki.kubuntu.org/DebuggingProgramCrash (linked > from Techbase) : > > "it figures out the set of necessary packages and their > accompanying debug symbol packages, so that the > regenerated stack trace will be fully symbolic" I think apport is available in Debian as well and it seems thats right: martin@merkaba:~> apt-cache search apport apport - automatically generate crash reports for debugging apport-gtk - GTK+ frontend for the apport crash report system apport-kde - KDE frontend for the apport crash report system apport-retrace - tools for reprocessing Apport crash reports dh-apport - debhelper extension for the apport crash report system python-apport - apport crash report handling library I don´t know where it reports bugs then but I would bet it has been changed to some Debian-ish place. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201208062016.59266.mar...@lichtvoll.de
