Re: bug (?) in libbonobo that is breaking evolution
- From: Michael Meeks <michael ximian com>
- To: Jon Trowbridge <trow ximian com>
- Cc: <gnome-components-list gnome org>
- Subject: Re: bug (?) in libbonobo that is breaking evolution
- Date: Wed, 12 Sep 2001 00:41:33 -0400 (EDT)
Hi Jon,
On 11 Sep 2001, Jon Trowbridge wrote:
> There is definitely a little bit of confusion on gdb's part in that
> backtrace, but I'm 100% sure that this is the problem. The lock-up in
> evolution is easily reproducible.
Hmm - this sucks;
> I made a concerted effort to reproduce the lock-up, thinking that my
> change might have just thrown off the timing of the race condition.
> (This is ximian bug #8711, BTW.) On a particular piece of mail with
> lots of recipients, I get the lock-up 1 out of 5 times when I hit
> "Reply to All". With the event processing disabled in bonobo, I've
> successfully opened 100+ Reply windows.
Yes - the problem is that no-one understands the control code, nor
the shutdown issues - it has been horribly complicated by several people
and the lifecycle issues are totaly unclear. Simply removing the
process_events method may fix the immediate problem but generate a whole
slew of new ones in different places - particularly control destruction
races.
We have no regression tests to repeat any of the misc. horrible
issues that we came up against here - thus it is impossible to validate
any change here.
Worse - it's still a mess in Gnome 2.0, although if we slave the
control lifecycle to the connections we can probably kill it - this is
still pending however.
I really can't see a way of feasibly fixing it in a safe way in
Gnome 1.4, I can't remember the exact sequences of horrible failures it's
meant to guard against and it was a band aid in the first place.
> I can try rebuilding w/o any optimization and seeing what happens if
> you think that would be helpful.
If we can get a good stack trace, then possibly we can work around
the issue inside evolution for now - there must be a secondary cause;
multiple idle handlers, gtk action in idle handlers, or something to make
the gtk mainloop think it still has things to do when it doesn't.
Sigh; in an ideal world we wouldn't need the event processing
there. I'd be interested in anyone's perspective on removing that ( which
is also a source of evil re-enterancy ).
Sorry, that's the best I can do to try and help,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]