Re: getting most out of debugging sawfish (need debian packaging help)
- From: Janek Kozicki <janek_listy wp pl>
- To: General discussion about sawfish wm <sawfish-list gnome org>
- Subject: Re: getting most out of debugging sawfish (need debian packaging help)
- Date: Wed, 31 Dec 2008 09:49:27 +0100
Rodrigo Gallardo said: (by the date of Thu, 18 Dec 2008 18:11:58 +0100)
Hi,
> Add a definition of the package to debian/control, probably at the end:
>
> Package: librep-dbg
> Architecture: any
> Depends: librep (= ${binary:Version})
> Priority: extra
> Description: librep debugging symbols
> This package contains the debugging symbols for librep.
> .
> It is useful if you find a problem and want to help find the cause.
>
>
> Look for the dh_strip line in debian/rules and change it to:
>
> dh_strip -a --dbg-package=librep-dbg
>
> That's it! (or should :)
It works!
I created librep-dbg oraz rep-gtk-dbg packages. Started debugging
this way, and gdb and valgrind had all the debug symbols, awesome!
Then I managed to get a crash, but I wasn't prepared and was too
excited... and I lost valgrind output, because I pressed 'up
arrow;enter' in screen to start `valgrind sawfish` again. And before
I realized what I have done, the valgrind output scrolled out of the
screen lines buffer :) But I've read it once and I remember that the
crash was about trying to dereference a NULL pointer.
So next I started:
# ulimit -c unlimited
# valgrind sawfish > vg-all-mesgs 2>&1
And now, not a single line will be ever lost :)
And then I managed to get a second crash. I have coredump/backtrace
and valgrind output. Mysterious thing is that in the second crash the
cause of segfault was different. Not dereferencing NULL pointer, but
lisp stack overflow.
currently I'm editing backtrace and valgrind outputs to make them
more readable for analysis (deleting useless junk and repetition).
Also I think that I've found a way to reproduce this crash:
- use sawfish for a longer time (probably some garbage accumulates,
or some memory is not cleaned somewhere)
- rename files in rox, rename them a lot, crash occurs every
hundredth rename, or so.
--
Janek Kozicki |
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]