Created attachment 636144 [details] sqldump_onlybrokenrows.sql User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5 Steps to reproduce: I edited the event that is attached as a SQlite dump to add an end date (before, it did not have one) (specifically, June 26th, 2012). Actual results: Thunderbird (12.0.1) with Lightning 1.4 on Windows XP SP3 (current updates) crashed. Upon restart, the main Thunderbird window did not appear again, however, "thunderbird.exe"'s CPU load was at 50% (dualcore machine) for about a minute, then dropped to almost zero. The main window did not appear. Disabling Lightning in safe mode let Thunderbird work fine. Updating from Thunderbird 12 to 13 and Lightning 1.4 to 1.5.2 (current version as of yesterday) did not help. After editing the "local.sqlite" file by hand and _removing_ the rows that are attached to this bug, Thunderbird was able to start again. However, the first start was incredibly slow (minutes to appear, then long delays when entering text in a new event dialog). Expected results: No crash, no corruption (if that's the bug) of local.sqlite, no slowness. :)
Jens, can you post crash ID? http://support.mozillamessaging.com/en-US/kb/Mozilla-Crash-Reporter#w_viewing-crash-reports
Unfortunately, no (crash reports were disabled). What I can do, however, is to restore the database (local.sqlite) to its broken state (I have a backup) and then perform any actions you describe, e.g. somehow analyze the 'thunderbird.exe' process that won't start. I am fairly confident with command line utilities, however I don't have much experience with debugging Windows apps.
Directions to get trace https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
I cannot reproduce the crash. My bug report was also not about the crash, but about the inability of Thunderbird / Lightning to start at all when the database contains the entries I attached. IMHO, Thunderbird / Lightning should be so robust that even a corrupted SQlite database (which wasn't the case here, as far as I can see) should not prevent it from starting up to delete the broken entries from the calendar.
anything you want Jens to do for us?
Jens, Is this a recurring event? Can you reduce the testcase to only the event that causes difficulty?
Severity: critical → normal
I seem to recall someone in the past warning against editing the database
While editing rows in the sql database is certainly not a supported action, it surely won't hurt to make Lightning more robust in case something goes wrong with the database. It would be nice if someone could test if this is still an issue with the latest Lightning, aside from that I am happy to mentor someone into figuring out exactly where Lightning is hanging. Without having looked at the database, one thing I found recently when fixing another bug, when we have events that span a long time (e.g. 50 years), they hang the calendar views.
Keywords: perf → hang
Whiteboard: [notacrash] → [notacrash][testcase needs analysis]
(In reply to Philipp Kewisch [:Fallen] from comment #8) > ... > Without having looked at the database, one thing I found recently when > fixing another bug, when we have events that span a long time (e.g. 50 > years), they hang the calendar views. this would be bug 680620
Status: UNCONFIRMED → RESOLVED
Last Resolved: 24 days ago
Resolution: --- → DUPLICATE
Summary: Thunderbird not starting (CPU 100%, no main window) after event entry & crash → Thunderbird not starting (CPU 100%, no main window) after event entry & hangs
Duplicate of bug: 680620
You need to log in before you can comment on or make changes to this bug.