Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20111227 Firefox/12.0a1 SeaMonkey/2.9a1 ID:20111227003005 After installing this new nightly, I tried to start it the way I normally do (ChatZilla, MailNews, and about:blank in the browser), and got three startup crashes in succession. Then I started only the browser and got no crash. The first two crashes are at the same signature, the third one I don't know yet, it gave me a Soccorro error (bug 713679). Here are he report IDs in ascending chronological order: bp-21077f10-a46d-49c4-9aee-c22ed2111227 bp-6ff9c7ed-9b14-4d93-b65c-b5fa92111227 bp-5d7985e1-a45d-44b6-8501-a6bff2111227 This problem didn't exist in yesterday's nightly.

Here's a copy of the report for the first of these crashes: Signature nsParseNewMailState::MoveIncorporatedMessage More Reports Search UUID 21077f10-a46d-49c4-9aee-c22ed2111227 Date Processed 2011-12-27 07:51:57.427065 Uptime 1801 Last Crash 4.2 weeks before submission Install Age 30.0 minutes since version was first installed. Install Time 2011-12-27 15:19:04 Product SeaMonkey Version 2.9a1 Build ID 20111227003005 Release Channel nightly OS Linux OS Version 0.0.0 Linux 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 Build Architecture amd64 Build Architecture Info family 15 model 4 stepping 1 Crash Reason SIGSEGV Crash Address 0x0 User Comments shortly after startup, while the brower was loading its multitab homepage or soon afterwards; I had temporarily turned away fromthe computer App Notes GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=9, request_code=55, minor_code=0 WebGL? WebGL- Processor Notes EMCheckCompatibility False Winsock LSP Adapter Vendor ID Adapter Device ID Bugzilla - Report this Crash Crashing Thread Frame Module Signature [Expand] Source 0 libxul.so nsParseNewMailState::MoveIncorporatedMessage mailnews/local/src/nsParseMailbox.cpp:2535 1 libxul.so nsParseNewMailState::ApplyFilterHit mailnews/local/src/nsParseMailbox.cpp:2094 2 libxul.so nsMsgFilterList::ApplyFiltersToHdr mailnews/base/search/src/nsMsgFilterList.cpp:358 3 libxul.so nsParseNewMailState::ApplyFilters mailnews/local/src/nsParseMailbox.cpp:1984 4 libxul.so nsParseNewMailState::PublishMsgHeader mailnews/local/src/nsParseMailbox.cpp:1900 5 libxul.so nsPop3Sink::IncorporateComplete mailnews/local/src/nsPop3Sink.cpp:899 6 libxul.so nsPop3Protocol::HandleLine mailnews/local/src/nsPop3Protocol.cpp:3607 7 libxul.so nsPop3Protocol::RetrResponse mailnews/local/src/nsPop3Protocol.cpp:3393 8 libxul.so nsPop3Protocol::ProcessProtocolState mailnews/local/src/nsPop3Protocol.cpp:4014 9 libxul.so nsMsgProtocol::OnDataAvailable mailnews/base/util/nsMsgProtocol.cpp:389 10 libxul.so nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:512 11 libxul.so nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:402 12 libxul.so nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:114 13 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:660 14 libxul.so NS_ProcessNextEvent_P objdir/mozilla/xpcom/build/nsThreadUtils.cpp:245 15 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110 16 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:201 17 libxul.so nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:189 18 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:220 19 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:3523 20 seamonkey-bin main suite/app/nsSuiteApp.cpp:103 21 libc-2.14.1.so libc-2.14.1.so@0x2123c 22 seamonkey-bin Output suite/app/nsSuiteApp.cpp:72

Just in case, I'm attaching the stdout/stderr log for the crashed sessions and the current (still running) session. I had rotated the logs just before that so no earlier log is included.

It didn't happen in the 12/26 nightly? That makes it less likely it's the pluggable store work, which landed 12/24 so was in the 12/25 and 12/26 nightlies. I'll see if I can reproduce here.

Mark, any idea if you have been seeing crash-sigs similar to this on your end, its likely this is shared code, but I know so little about that side I don't want to move or try to dupe the bug. (crash-stats is down for me atm)

the bug happens filtering messages to a local folder with a missing or out of date .msf file - this fixes it.

This *is* a regression from the plugabble store work.

fixed http://hg.mozilla.org/comm-central/rev/acd227a49aad

(In reply to David :Bienvenu from comment #7) > fixed http://hg.mozilla.org/comm-central/rev/acd227a49aad Just woke up and it's already FIXED? Ah, nice: let's run and grab a tinderbox-build so I can see if I can get mail again and VERIFY this fix.

Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20111226 Firefox/12.0a1 SeaMonkey/2.9a1 ID:20111227142829 After starting up normally, getting mail (including from Movemail, which used to be b0rken, see bug 713491, and is now fixed) and clicking "Run filters on folder" in Inbox to quickly sort messages which were left there, still no crash. => VERIFIED.

(In reply to David :Bienvenu from comment #3) > It didn't happen in the 12/26 nightly? That makes it less likely it's the > pluggable store work, which landed 12/24 so was in the 12/25 and 12/26 > nightlies. I'll see if I can reproduce here. (In reply to David :Bienvenu from comment #5) [...] > the bug happens filtering messages to a local folder with a missing or out > of date .msf file - this fixes it. (In reply to David :Bienvenu from comment #6) > This *is* a regression from the plugabble store work. Aha! Sounds like bug 713491, which appeared on 12/25 and has disappeared together with this bug, contributed to this crash. See in particular bug 713491 comment #2 about .msf files, and bug 713491 comment #0 about how "Properties → Repair folder" was a temporary workaround.

full signature (for is nsParseNewMailState::MoveIncorporatedMessage(nsIMsgDBHdr*, nsIMsgDatabase*, nsIMsgFolder*, nsIMsgFilter*, nsIMsgWindow*) crashes of daily are indeed gone as of 20111228 build, per crash-stats

(In reply to Wayne Mery (:wsmwk) from comment #11) > > crashes of daily are indeed gone as of 20111228 build, per crash-stats except for one FREAK bp-9a0aadd2-cdaf-4bbd-ab37-dc6c52120118