Re: Squeeze Konqueror Crashes - Need Debug Symbols
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
Reply to: