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:
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
Date Processed 2011-12-27 07:51:57.427065
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
Build ID 20111227003005
Release Channel nightly
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
GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=9, request_code=55, minor_code=0
Adapter Vendor ID
Adapter Device ID
Bugzilla - Report this Crash
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
Created attachment 584457 [details]
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)
Created attachment 584465 [details] [diff] [review]
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.
(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.
(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