Yesterday I decided to try eclipse (CDT + QT integration) for one of my project.
After some time, fvwm segfault killing xorg, eclipse and every others programs.
I’m not really sure but I found this in my log:
cat messages.log.1 | grep fvwm
Jan 9 21:08:26 darkarch fvwm[7463]: segfault at 000001f8 eip 080b1b4f esp bfcde710 error 4
Jan 10 11:43:18 darkarch fvwm[7481]: segfault at 000001f8 eip 080b1b4f esp bfe31f50 error 4
Jan 10 12:29:29 darkarch fvwm[10079]: segfault at 000001f8 eip 080b1b4f esp bfeb5ef0 error 4
Jan 10 19:35:02 darkarch fvwm[11600]: segfault at 000001f8 eip 080b1b4f esp bfd5dda0 error 4
Jan 10 21:00:00 darkarch fvwm[20680]: segfault at 000001f8 eip 080b1b4f esp bf9889c0 error 4
Do you think this is a bug?
Where can I find more information? Maybe fvwm write a more detail log somewhere when it crash…
I don’t know what “patched” means in terms of your FVWM version, or indeed what with, but if you can reliably reproduce this crash with FVWM, then get the latest CVS version of FVWM and:
For now, I can’t use cvs version but I try what you ask me and here what I got:
$ gdb fvwm ./core
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
Reading symbols from /usr/lib/libXft.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXft.so.2
Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libX11.so.6
Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libfontconfig.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfontconfig.so.1
Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXrender.so.1
Reading symbols from /usr/lib/libXpm.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXpm.so.4
Reading symbols from /usr/lib/libstroke.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libstroke.so.0
Reading symbols from /usr/lib/libSM.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libSM.so.6
Reading symbols from /usr/lib/libICE.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libICE.so.6
Reading symbols from /usr/lib/libXinerama.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXinerama.so.1
Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXext.so.6
Reading symbols from /lib/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libXcursor.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXcursor.so.1
Reading symbols from /usr/lib/libfribidi.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfribidi.so.0
Reading symbols from /usr/lib/libpng12.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpng12.so.0
Reading symbols from /usr/lib/librsvg-2.so.2...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/librsvg-2.so.2
Reading symbols from /usr/lib/libgdk_pixbuf-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgdk_pixbuf-2.0.so.0
Reading symbols from /usr/lib/libgobject-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgobject-2.0.so.0
Reading symbols from /usr/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgmodule-2.0.so.0
Reading symbols from /lib/libdl.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libglib-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libglib-2.0.so.0
Reading symbols from /usr/lib/libcairo.so.2...done.
Loaded symbols for /usr/lib/libcairo.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libxcb-xlib.so.0...done.
Loaded symbols for /usr/lib/libxcb-xlib.so.0
Reading symbols from /usr/lib/libxcb.so.1...done.
Loaded symbols for /usr/lib/libxcb.so.1
Reading symbols from /usr/lib/libexpat.so.1...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/lib/libXau.so.6...done.
Loaded symbols for /usr/lib/libXau.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libXfixes.so.3...done.
Loaded symbols for /usr/lib/libXfixes.so.3
Reading symbols from /usr/lib/libgsf-1.so.114...done.
Loaded symbols for /usr/lib/libgsf-1.so.114
Reading symbols from /usr/lib/libcroco-0.6.so.3...done.
Loaded symbols for /usr/lib/libcroco-0.6.so.3
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/lib/libpangoft2-1.0.so.0...done.
Loaded symbols for /usr/lib/libpangoft2-1.0.so.0
Reading symbols from /usr/lib/libpangocairo-1.0.so.0...done.
Loaded symbols for /usr/lib/libpangocairo-1.0.so.0
Reading symbols from /usr/lib/libpango-1.0.so.0...done.
Loaded symbols for /usr/lib/libpango-1.0.so.0
Reading symbols from /lib/libpcre.so.0...done.
Loaded symbols for /lib/libpcre.so.0
Reading symbols from /usr/lib/libXdmcp.so.6...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Reading symbols from /lib/libbz2.so.1.0...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /usr/lib/gconv/ISO8859-15.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-15.so
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
Core was generated by `fvwm'.
Program terminated with signal 11, Segmentation fault.
#0 0x080b1b4f in ?? ()
and:
(gdb) bt
#0 0x080b1b4f in ?? ()
#1 0x08111868 in ?? ()
#2 0x080f2d8e in ?? ()
#3 0xbf97a1d8 in ?? ()
#4 0xb7ee4d11 in _XCBUnlockDisplay () from /usr/lib/libX11.so.6
#5 0x080b082a in ?? ()
#6 0x00000000 in ?? ()
XCB? As in the X C Bindings? No wonder it crashes – applications currently have to be ““ported”” to use it, and it’s not even anywhere near usable yet to replace Xlib. Can you remove it, and then see if it stops crashing?
Please compile fvwm with the flag -g cflag to enable debugging symbols. (And don’t strip the binary.) Then redo the process of getting the backtrace, and it will be more useful.
Stripping is the process of removing debug symbols. It’s commonly used by package handling systems and binary distributions since it reduces the size of the binaries. If you compile locally and take no extra steps you should be fine. (See the manpage of strip(1) for details.)
$ gdb fvwm ./core
.... ( Load lib ) ...
Program terminated with signal 11, Segmentation fault.
#0 0x080cbedf in ewmh_MoveResizeWindow (fw=0x0, ev=0x812e3a0, style=0x0, any=0) at ewmh_events.c:194
194 if (
(gdb) bt
#0 0x080cbedf in ewmh_MoveResizeWindow (fw=0x0, ev=0x812e3a0, style=0x0, any=0) at ewmh_events.c:194
#1 0x080ce01f in EWMH_ProcessClientMessage (exc=0x81a1f50) at ewmh_events.c:1485
#2 0x0807ed99 in HandleClientMessage (ea=0xbfc7359c) at events.c:1796
#3 0x08082474 in dispatch_event (e=0xbfc735b8) at events.c:3949
#4 0x0808256a in HandleEvents () at events.c:3990
#5 0x080a78be in main (argc=2, argv=0xbfc73924) at fvwm.c:2612
Strange. It seems as if the event reaching the ewmh handler isn’t a XClientMessageEvent. I don’t think anything should be able to change that in the code… But the code should probably be different anyway.
Try to change
XEvent *ev = exc->x.elast;
to
XEvent *ev = exc->x.etrigger;
in fvwm/ewmh_events.c line 1456 and 1513 (EWMH_ProcessClientMessage and EWMH_ProcessPropertyNotify) and see if it still crashes. I don’t think it will, but I’m not sure what happens when it crashes. Maybe if any function called in GNOME_ProcessClientMessage calls some function from the fvwm event library one could get the type of crash that you are experiencing.
Or you are experiencing this bug: fvwm.org/cgi-bin/fvwm-bug/incoming?id=4429 which is more likely since I don’t know how the last event can change from the trigging of it.