This bug was filed from the Socorro interface and is
report bp-407e5914-e576-4934-a618-0aa152120504 .
all crashes are version 12.0.1
0 libxul.so NS_ReadLine<char, nsIInputStream, nsCAutoString> nsReadLine.h:150
1 libxul.so MsgStreamMsgHeaders nsMsgUtils.cpp:2220
2 libxul.so nsMailboxService::StreamHeaders nsMailboxService.cpp:355
3 libxul.so libxul.so@0x100292b
4 libxul.so XPCWrappedNative::CallMethod XPCWrappedNative.cpp:2901
5 libxul.so XPC_WN_CallMethod XPCWrappedNativeJSOps.cpp:1542
6 libxul.so js::InvokeKernel jscntxtinlines.h:311
7 libxul.so js::Interpret jsinterp.cpp:2791
8 libxul.so js::InvokeKernel jsinterp.cpp:537
9 libxul.so js::Invoke jsinterp.h:157
10 libxul.so JS_CallFunctionValue jsapi.cpp:5449
11 libxul.so nsXPCWrappedJSClass::CallMethod XPCWrappedJSClass.cpp:1510
12 libxul.so nsXPCWrappedJS::CallMethod XPCWrappedJS.cpp:617
13 libxul.so PrepareAndDispatch xptcstubs_gcc_x86_unix.cpp:92
14 libxul.so nsMsgMailSession::OnItemAdded nsMsgMailSession.cpp:193
15 libxul.so nsMsgDBFolder::NotifyItemAdded nsMsgDBFolder.cpp:5004
I've just renamed a local folder
I went offline, started compact all folders and have restarted afterwards.
I went offline, compacted all folders and have restarted afterwards - problem seems not to occure if i stay offline!?
I got to read an e-mail this time (last crash about 3 minutes ago). What's up with TB today?
#4 crasher for thunderbird 12.0.1, and #1 crash for linux
(see if socorro picks up signature @ NS_ReadLine. doubtful)
A friend of mine (not computer expert) is seeing this on this Ubuntu 12.04 machine, too.
> I've just renamed a local folder
We did the same.
Using the official Thunderbird 13 x64 works
Could somebody please report this back to Ubuntu with high priority?
also reported here: http://forum.ubuntu-fr.org/viewtopic.php?pid=9720811
(In reply to Ben Bucksch (:BenB) from comment #5)
> Could somebody please report this back to Ubuntu with high priority?
That launchpad bug was for @ nsResProtocolHandler::nsResProtocolHandler
Another user report the problem here (on Geckozone): http://www.geckozone.org/forum/viewtopic.php?f=4&t=106780&p=698304&e=698304
Is there anything that can be done to help you understand the issue?
A nother one in Ubuntu french forum.
It's only for french user ??
My friend from comment 3 also is located in France, but he's English and I think using the English locale in Ubuntu (OS and user account). He's using a French keyboard, Paris time, and Orange as ISP.
The crash is in nsMsgDBFolder::NotifyItemAdded(), so my guess would be that the trigger are French emails (of which he also gets a lot, e.g. from LeMonde) with French accents and these chars in the emails are triggering the crash.
hmm. I haven't found the windows equivalent signature. No crash sigs contain nsMsgMailSession::OnItemAdded.
(There are crashes for the frame below, nsMsgDBFolder::NotifyItemAdded. but they are not startup - for example nsMsgDBFolder::NotifyItemAdded(nsISupports*) 2febe726-4c20-4adc-84ae-b113d2120829 )
first crash is a single TB12 beta build 20120315033921 bp-5f9865eb-73a8-42d7-9524-e8a9b2120322
Not strictly match to bug 124287's title, but WTH
gee, no solid progress on this topcrash regression?
Looking at the extension list on the crash reports, I see at least one that claims no extensions loaded, which confuses me. But still, there is no error checking in the call to NS_ReadLine, and the likely failure is a null aStream here:
116 nsresult rv = aStream->Read(aBuffer->buf, kLineBufferSize, &bytesRead);
Looking at where that comes from, in nsMailboxService.cpp we have
321 rv = folder->GetOfflineFileStream(msgKey, &messageOffset, &messageSize, getter_AddRefs(inputStream));
322 NS_ENSURE_SUCCESS(rv, rv);
323 return MsgStreamMsgHeaders(inputStream, aConsumer);
Is the rv test enough? No, because in GetOfflineFileStream we have:
nsresult rv = GetDatabase();
That is, any failure to get the database returns OK but a null filestream.
This is exactly why I dislike using NS_ENSURE_SUCCESS(rv, rv) when what I really care about is a non-null pointer. In my own code, I would have used instead:
NS_ENSURE_STATE(inputStream) and this would have been prevented.
I'll take this and do a fix.
Created attachment 660626 [details] [diff] [review]
Test that crashes with correct stack
This xpcshell test generates the crash. Fix to follow.
Jonathan, in your Conversations addon you disable the call to streamHeaders. Is it because of the crash that occurs here?
Created attachment 660636 [details] [diff] [review]
Rev2: with crash fix
I disable the call to streamHeaders because that function just doesn't work: it sometimes returns part of the header, and the first few bytes of the headers are missing. I once tried to debug this with Bienvenu but we didn't get far. If you were to find out what's happening, that would be fantastic :)
Oh, my, I was scratching my head whilst looking at this yesterday because I thought the crash was happening here:
... based on the line numbers in https://crash-stats.mozilla.com/report/index/407e5914-e576-4934-a618-0aa152120504. Now I've just realized that report is from an old version before the license header change ;)
Anyway, thanks for spotting that. Incidentally, I have an addon which calls streamHeaders too...
> GetOfflineFileStream we have:
> nsresult rv = GetDatabase();
> NS_ENSURE_SUCCESS(rv, NS_OK);
> That is, any failure to get the database returns OK but a null filestream.
That's either just wrong, a bug in GetDatabase(), or - if it's clearly documented -, a mean API that the caller here misunderstood. If the latter, please fix GetDatabase(), not the caller.
> AFAICT streamHeaders is not used in the core code
FYI, I personally saw the bug on a machine with a fresh installation of Ubuntu and Ubuntu's Thunderbird package. The only extensions were those added automatically by Ubuntu. So, these would be a place to look at.
Chris, I've had consistently wrong results with streamHeaders, I've tried debugging these for a while, and I couldn't get anywhere. Looks like the backend gets the offset of the message wrong and starts streaming at a wrong offset...
protz, is there a bug report on streamHeaders?
(In reply to Jonathan Protzenko [:protz] from comment #21)
> I've had consistently wrong results with streamHeaders ...
> starts streaming at a wrong offset...
Oh, that's interesting! This might be the cause of bug 790912.
(In reply to Ben Bucksch (:BenB) from comment #20)
> > GetOfflineFileStream we have:
> > nsresult rv = GetDatabase();
> > NS_ENSURE_SUCCESS(rv, NS_OK);
> > That is, any failure to get the database returns OK but a null filestream.
> That's either just wrong, a bug in GetDatabase(), or - if it's clearly
> documented -, a mean API that the caller here misunderstood. If the latter,
> please fix GetDatabase(), not the caller.
For a crash fix like this that I hope to get landed in a .0.* version, I tend to be extremely cautious in what I change. Because GetOfflineFileStream is used in places other than streamHeader, I am reluctant to change its behavior in a .0.* version. I agree though that the NS_ENSURE_SUCCESS(rv, NS_OK) violates expectations and should be changed, just not in this patch.
> > AFAICT streamHeaders is not used in the core code
> FYI, I personally saw the bug on a machine with a fresh installation of
> Ubuntu and Ubuntu's Thunderbird package.
As I mentioned, I also noted crash reports with no extensions installed, so I am also concerned here. But the issue I have identified in the patch is real, the unit test crashes with the correct signature without the fix, so this patch should be landed IMHO.
Comment on attachment 660636 [details] [diff] [review]
Rev2: with crash fix
Review of attachment 660636 [details] [diff] [review]:
The patch looks fine. We should land this, but I'd like to keep either this or a related bug open to understand why we're failing to open the offline stream in these cases and make GetOfflineFileStream behave better.
Created attachment 661854 [details] [diff] [review]
Patch as landed (added MPL header to test), r=irving
Checked in https://hg.mozilla.org/comm-central/rev/c05d43695bef
> I'd like to keep either this or a related bug open
> to ... make GetOfflineFileStream behave better.
Thanks for catching that I forgot that, Ben! But let's do it in a new Bug 791893.
Not significant enough for tracking...
Comment on attachment 661854 [details] [diff] [review]
Patch as landed (added MPL header to test), r=irving
...I will take it onto aurora and beta though, as I think this is a low risk enough simple null-check addition.
no tb16 crashes in https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=NS_ReadLine%26lt%3Bchar%2C%20nsIInputStream%2C%20nsCAutoString%26gt%3B&reason_type=contains&date=10%2F18%2F2012%2012%3A15%3A22&range_value=4&range_unit=weeks&hang_type=any&process_type=all&do_query=1&admin=1&signature=NS_ReadLine%3Cchar%2C%20nsIInputStream%2C%20nsCAutoString%3E
and none on trunk