heads-up on ORBit2 behavior under load

[Bill Haneman <bill haneman sun com>]

Hi Michael/All:

I am running into some significant SEGV-type problems in
at-spi-registryd, and it's starting to look as though the root issues
might lie in the ORB's (ORBit2) behavior under stress.

There is a buglet or something in gtk+ or maybe gail at the moment that
causes lots of text events to be generated when switching between apps
in gtk-demo.  As a result, leaning on the arrow keys in gtk-demo
generates a storm of at-spi notify calls; in fact if you have keyrepeat
on you can trigger a catastrophic failure in under a second.

Now, I think there are many pointless text events being generated in
this case, due to some bug (at least I hope it's not a "feature").  But
it exposes a nasty loading problem; since the notify calls are oneways,
but before each notify one must call ref() which is not a oneway, we
have this interesting interleaving of calls that block and calls that
don't and ORBit2's stack gets very very tall indeed.  SEGV occurs in
various places, sometimes somewhere in malloc, sometimes in g_type,
sometimes elsewhere... in other words it looks like the cause has to do
with resource depletion rather than being a coding error on the part of
at-spi or the atk-bridge.  The error never happens if you have any idle
times inserted at all, to let the ORB unwind the stack.  GDB reported in
one case I checked a stack frame depth of over 30,000.  Not sure how to
prevent this, but it seems as though at some point the ORB should block
rather than continuing to push stuff onto the stack...

Help tackling/diagnosing very much appreciated, this is prolly a stopper
since we can't keep people from using keyrepeat ;-)

I have not logged a bug yet, awaiting suggestions from you as to
where/how to classify it.

-Bill