Comment 59 for bug 151536

Added a note upstream.

@all: we have never been able to zero in the cause. I cannot reproduce it, so I am sort of limited. If you are hit by this:

(1) please install the debug packages for E-D-S, libc6, glib, bonobo and orbit. As of right now these are the packages for Hardy (adjust as needed between i386, AMD64, etc):

libbonobo2-0-dbgsym_2.22.0-0ubuntu1_amd64.ddeb
libc6-dbgsym_2.7-10ubuntu3_amd64.ddeb
libglib2.0-0-dbgsym_2.16.3-1_amd64.ddeb
liborbit2-dbgsym_1%3a2.14.12-0.1_amd64.ddeb
evolution-data-server-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libegroupwise1.2-13-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libedata-cal1.2-6-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libecal1.2-7-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libedata-book1.2-2-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libebook1.2-9-dbgsym_2.22.1-0ubuntu1_amd64.ddeb
libedataserver1.2-9-dbgsym_2.22.1-0ubuntu1_amd64.ddeb

Of course, the equivalent .dbg can also be used.

(2) please do not post GDB backtraces if the above debug packages are not installed. Without debug symbols there is *nothing* usable in a backtrace.

(3) this is a loop condition, I guess everybody agrees with that. A GDB backtrace provides a *static* view of where the code was at the moment GDB interrupted it. Unfortunately, this is helpful, but not enough: I still do not know if a single thread is looping, or threads are being created and destroyed. Some backtraces show actual E-D-S code in (for example, pete's comment above, thread #3), others do *not* show Evo code. It would be helpful if one of you went through GDB in a series of (interrupt, bt full, thread apply all bt) -- this might give us more details on what code paths are being used.

(4) What we need is a commonality, something similar to all. By some comments, this seems to affect people using calendars. I set myself with a google calendar, and still I cannot reproduce it. It would also be interesting to know what architecture you are running under.

(5) finally, you should consider commenting on the upstream bug.