Comment 31 for bug 386326

Multiple users have reported this issue at Oracle.

I've been able to reproduce this issue multiple times on Windows XP SP2 with Thunderbird/2.0.0.14 setup with an IMAP account configured to use SSL and Lightning/0.8 setup with a CalDAV calendar configured to use HTTPS. The IMAP server and CalDAV server were on the same host (i.e., same host name).

The problem would occur when Thunderbird is accessing the IMAP server at the same time that Lightning is accessing the CalDAV server. A timing issue!

We've been able to reproduce the issue consistently by monitoring the CalDAV exchange in HTTPAnalyzer and clicking on the IMAP Inbox at just the right time (!) for the IMAP connection to be established in between the CALDAV:calendar-query REPORTs and the CALDAV:calendar-multiget REPORTs.

Most of the users that have reported this issue had Thunderbird configured to check for new messages at startup which would increase the likelihood that the IMAP connection is established at pretty much the same time as the CalDAV connection. That being said, on my machine (Dell Latitude D630, Intel Core2 Duo CPU, Windows XP SP2) the issue was easier to reproduce without checking for new messages at startup automatically, but rather by clicking on the IMAP Inbox at just the right time.

From what we've seen the size of the IMAP Inbox, or the number of calendar components in the CalDAV calendar collection didn't matter so much. That being said, their respective size would surely influence the time it takes the server to return its responses (and thus impact the timing between the IMAP and CalDAV access).

Using Process Explorer we were able to identify the thread that was taking all the CPU (50% on a Core2 Duo) in thunderbird.exe and look at the thread stack. From what we've seen the thread was looping in nsPrintSettings::GetStartPageRange. I don't know if that makes any sense or not.