Hi:
Here is an update. To play with things I have been using the 2.6 branch
from the cvs.
First, let me note that even with the same maple worksheet, from time to
maple loads correctly (this is without any obvious changes to anything). In
that case, I can see all the cores of my CPU spike up for a few seconds,
but then they all settle. When I see the problem, all the cores spike up,
then all except one die down.. that one stays at 100% as described earlier
and it's the fvwm process that is using the cpu. Also, not sure if this is
anecdotal, but it would seem like the more i force fvwm to print debug
info, the more likely maple loads correctly.
Could you place printfs in events.c in the My_XNextEvent() function
> and print out the event type? That should identify the mass of
> events that are coming in, probably just the PropertyNotify from
> the stack trace, but maybe more.
>
> Then put printfs all over the responsible Handle<Event>()
> functions to print out the exact contents of the events and how
> fvwm reacts to them. You can find descriptions of the various
> event types in the event union by searching for "X11 event
> structure" on the net.
>
I've added some printfs, in My_XNextEvent(), dispatch_event() and
HandlePropertyNotify(). So the event when the problem occurs, seems to
always be PropertyNotify. The rough output should be self explanatory... So
as I start maple in a case where things break, I see:
....
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: switch XA_WM_ICON_NAME
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: switch XA_WM_NAME
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: switch default
HandlePropertyNotify: ruturn natural
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: switch default
Here the output the ~/.xsession-errors stops (not always on the same
statement)... I then switch to a different terminal, and kill maple, java,
mserver. Then switch back. Get:
(gnome-settings-daemon:18525): color-plugin-WARNING **: Done switch to new
account, reload devices
Then after a little while, 10s of thousands of events are quickly dumped
like so:
HandlePropertyNotify: ruturn natural
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: return if (XGetGeometry(...
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: return if (XGetGeometry(...
My_XNextEvent: event type 28
dispatch_event: event type 28
HandlePropertyNotify: beginning
HandlePropertyNotify: return if (XGetGeometry(...
My_XNextEvent: event type 28
This goes on for a while... what it tells me is that in
HandlePropertyNotify() every event ends up returning in this bit of code:
if (XGetGeometry(
dpy, FW_W(fw), &JunkRoot, &JunkX, &JunkY,
(unsigned int*)&JunkWidth, (unsigned int*)&JunkHeight,
(unsigned int*)&JunkBW, (unsigned int*)&JunkDepth) == 0)
{
return;
}
When things load correctly I don't see this return path from
HandlePropertyNotify().
Any ideas how to get around this?
> More evidence that the application probably generates too many
> events. Have you tried sitting the situation out? Do things go
> back to normal after, say, five minutes?
>
>
Yes, if I leave things alone (and not kill maple), fvwm comes back to life
after 10+ minutes (this is without no debugging turned on). So I suppose
that would be consistent with your theory... at some stage fvwm finishes
"processing" all the events.
thanks
