User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:220.127.116.11) Gecko/20080129 Iceweasel/18.104.22.168 (Debian-22.214.171.124-1) Build Identifier: 126.96.36.199-3 (sorry, no build identifier...) The problem appears with Icedove, the Debian branded version of Thunderbird (but i think the error is more general, likely afflicting the whole Mozilla suite) When i single-click on some mails to display them, Thunderbird crashes with Sigsegv. I've attached gdb and traced the error down to line nr. 864 in mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp (version 188.8.131.52). The variable gMonitor is NULL, because the call on line 841 fails and so gMonitor is never initialized. I don't know yet why the init() call fails, but probably, gMonitor should be chechked for NULL in the destructor anyway. Reproducible: Sometimes Steps to Reproduce: 1. Open Thunderbird 2. Click on an email in the main window 3. -> Crash I can fix this problem for some minutes/hours by reinstalling Thunderbird with my package manager, but then it happens again (and for all mails until i reinstall it). The bug is the same as https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/131557 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425564
The bug disappears when i disable the Lightning extension (Version 0.7). However, this is not really a solution, as i want to have Lightning enabled.
I wonder if PR_DestroyMonitor should null-check... http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/threads/prmon.c#84
timeless tells me nspr requires that you not pass null. The code is very different on trunk, I don't think the crash is an issue there.
Created attachment 306349 [details] [diff] [review] proposed fix How does this look? it would be null at least if Init() failed early.
Comment on attachment 306349 [details] [diff] [review] proposed fix I think that's fine, but it would be nice to know why this is happening. Once we know why, we could add a comment explaining why we need this check.
I'll try to do some more debugging tomorrow and maybe i can tell you, why it happens.
Comment on attachment 306349 [details] [diff] [review] proposed fix approved for 184.108.40.206, a=dveditz,dmose for release-drivers
Checked in on the 1.8 branch: Checking in toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp; /cvsroot/mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp,v <-- nsUrlClassifierDBService.cpp new revision: 220.127.116.11; previous revision: 18.104.22.168 done
Is there a repro case that I or someone else in QA can run for this? It is otherwise difficult to verify the fix for the release.