%% Regarding FVWM: [2.0.41] fvwm core on bad Event.type; I wrote:
pds> OK, it turns out that resizing absolutely _any_ X application,
pds> then moving the mouse outside the window will cause FVWM to
pds> core with the same problem: Event.type is 64 and you get a core
pds> dump. I tried it with Netscape, xterm, etc. and all did the
pds> same thing.
Ugh. Sorry for the glut of email :(
Anyway, I added some code to check for bogus Event.type values in both
events.c:DispatchEvent() _and_ in events.c:My_XNextEvent(), right after
the XNextEvent() function returns.
It turns out that the Event.type==64 is happening fairly regularly,
every 30 seconds or so, and it's being returned that way from
XNextEvent(). It happens even if I don't resize the window... even if I
just let my mouse sit idle.
And I found the culprit: xfaces! Every time xfaces polls for mail it
does something with its window that generates that event.
I recompiled FVWM to catch that event type and ignore it; then xfaces
didn't quite work: when I had no mail I got the proper shaped mailbox
pixmap. When I received some mail, it tried to put up a square bitmap,
but the shape of the bitmap was still the mailbox shape (i.e., it still
looked like a mailbox but it was "filled in" with the mail sender's
icon).
I don't understand why it works sometimes and core dumps other times;
very odd. Even more strange is that if I add a test so it doesn't core,
xfaces doesn't reshape correctly as I mentioned above! It's almost like
there's _normally_ some valid function pointer at location
EventHandlerJumpTable[64] that makes things work, but it gets
overwritten by 1 every now and then.
My xfaces app _was_ compiled a long time ago, with older X and Xpm
libraries; ldd says:
-lXpm.4 => /usr/X11R5/lib/libXpm.so.4.2
-lXaw.5 => /usr/X11R5/lib/libXaw.so.5.0
-lXmu.4 => /usr/X11R5/lib/libXmu.so.4.10
-lXt.4 => /usr/X11R5/lib/libXt.so.4.10
-lXext.4 => /usr/X11R5/lib/libXext.so.4.10
-lX11.4 => /usr/X11R5/lib/libX11.so.4.10
-lc.1 => /usr/lib/libc.so.1.9
-ldl.1 => /usr/lib/libdl.so.1.0
I suppose that might be part of the problem. I'll recompile and see if
there's any difference.
-------------------------------------------------------------------------------
Paul D. Smith <psmith_at_baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<
http://www.baynetworks.com/>-
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Mar 13 1996 - 13:14:17 GMT