getting most out of debugging sawfish (need debian packaging help)

[Janek Kozicki <janek_listy wp pl>]

Hi,

Once per several months sawfish crashes for me, but I couldn't find
what's the cause of it. That was happening even 2 years ago, so it's
not a regression due to our work for sure.

I decided that it's time to do something about it, but I need to
track this down and I still have no idea how to reproduce this crash.
I suspect that this happens under heavy load, when a window appears
'faster' than it could be handled. But still I cannot reproduce this.

The only thing that I could do (AFAIK) is to run sawfish under
valgrind inside screen. Which I just started doing today. After a
crash (few months later) I'll be able to get into screen and see last
valgrind messages before the crash.

I'm not a debian packages expert, so I need to ask how can I ensure
that my sawfish debian build has all possible debugging symbols
(which are used by valgrid). And I prefer to use a debian package
(I'm simply downloading trunk into it and 'debian/rules binary').

For instance I have sawfish-dbg package installed also, but still the
executable is stripped:

  $ file `which sawfish`

  /usr/bin/sawfish: ELF 32-bit LSB executable, Intel 80386, version 1
  (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
  stripped

anyone got any ideas?


Here's some interesting output I got currently:


==1511== Conditional jump or move depends on uninitialised value(s)
==1511==    at 0x8058A1A: map_notify (events.c:826)
==1511==    by 0x80597B9: inner_handle_input (events.c:1416)
==1511==    by 0x405B7F8: rep_call_with_barrier (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x805A71B: handle_input_mask (events.c:1481)
==1511==    by 0x4088E41: (within /usr/lib/librep.so.9.4.0)
==1511==    by 0x4089932: rep_event_loop (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x4072338: Frecursive_edit (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x4072461: rep_top_level_recursive_edit (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x405B7F8: rep_call_with_barrier (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x806B219: main (main.c:425)
==1511== 
==1511== Conditional jump or move depends on uninitialised value(s)
==1511==    at 0x806ECEC: Fwindow_shaped_p (windows.c:1112)
==1511==    by 0x4071680: (within /usr/lib/librep.so.9.4.0)
==1511==    by 0x40718A8: (within /usr/lib/librep.so.9.4.0)
==1511==    by 0x4071E0E: (within /usr/lib/librep.so.9.4.0)
==1511==    by 0x40660DB: (within /usr/lib/librep.so.9.4.0)
==1511==    by 0x406B9B2: Fcall_hook (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x806F91D: Fcall_window_hook (windows.c:1359)
==1511==    by 0x80707AE: add_window (windows.c:516)
==1511==    by 0x805AD9F: map_request (events.c:752)
==1511==    by 0x80597B9: inner_handle_input (events.c:1416)
==1511==    by 0x405B7F8: rep_call_with_barrier (in /usr/lib/librep.so.9.4.0)
==1511==    by 0x805A71B: handle_input_mask (events.c:1481)

We can see from that:

- it would be useful if librep had debug symbols included in executable also.

- even though sawfish executable is stripped, there are still some
  references to source code, like windows.c:1359, does it mean that
  sawfish-dbg package works somehow?

- there is some undefined behaviour in the code ;-)


Besides, as I used valgrind on several programs for debugging I can
tell that sawfish is exceptionally clean-behaving :)

-- 
Janek Kozicki                                                         |