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 |
