Closed
Bug 454061
Opened 17 years ago
Closed 17 years ago
Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ][@ nsImapService::CreateStartOfImapUrl]
Categories
(Thunderbird :: General, defect, P1)
Thunderbird
General
Tracking
(Not tracked)
VERIFIED
FIXED
Thunderbird 3.0a3
People
(Reporter: Paenglab, Assigned: Bienvenu)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
878 bytes,
patch
|
standard8
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080907032646 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1b1pre) Gecko/20080907031916 Shredder/3.0b1pr
Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ]
8b35aba8-7c88-11dd-98f6-001a4bd43e5c?p=1
0 thunderbird.exe nsImapService::MessageURIToMsgHdr
1 thunderbird.exe GetMsgDBHdrFromURI
2 thunderbird.exe nsImapUrl::GetMsgFolder
3 thunderbird.exe nsImapUrl::GetFolderCharset
4 thunderbird.exe bridge_new_new_uri
5 thunderbird.exe nsStreamConverter::SetStreamURI
6 thunderbird.exe nsStreamConverter::Init
7 thunderbird.exe nsStreamConverter::AsyncConvertData
8 thunderbird.exe nsStreamConverterService::AsyncConvertData
9 thunderbird.exe nsImapMockChannel::SetupPartExtractorListener
10 thunderbird.exe nsImapMockChannel::OnCacheEntryAvailable
11 thunderbird.exe nsCacheListenerEvent::Run
12 xpcom_core.dll nsThread::ProcessNextEvent
13 xpcom_core.dll NS_ProcessNextEvent_P
14 thunderbird.exe nsBaseAppShell::Run
15 thunderbird.exe nsAppStartup::Run
16 thunderbird.exe XRE_main
17 thunderbird.exe NS_internal_main
18 thunderbird.exe wmain
19 thunderbird.exe __tmainCRTStartup
20 kernel32.dll kernel32.dll@0x17066
also 885a5aab-7ce2-11dd-84e0-001a4bd43e5c
Reproducible: Always
Steps to Reproduce:
1. Use GMail as IMAP
2. Try to read a email with attachments
Actual Results:
Crash
Expected Results:
The email will be displayed
The crash only happens with emails with attachments. Without attachment the email will be displayed normal
Comment 1•17 years ago
|
||
I get this for non-gmail IMAP servers, as well (on both Windows and Mac)
Updated•17 years ago
|
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•17 years ago
|
||
Oh, this occurs with only -some- of the messages I have which have attachments, not all, fwiw.
Comment 4•17 years ago
|
||
The same here. Only pdf-attachments don't crash. I think it startet yesterday
(with 20080907).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
Gecko/20080908033053 Shredder/3.0b1pre ID:20080908033053
Updated•17 years ago
|
Blocks: 441437
Keywords: crash,
regression
Comment 5•17 years ago
|
||
Given this has been seen by various folks, and its #1 on a rather short crash-stats list, setting blocking b1.
I think this also is causing a crash at nsImapService::CreateStartOfImapUrl, see bp e6c08868-7ccd-11dd-8e3f-001a4bd43ef6 top two frames:
0 thunderbird.exe nsImapService::CreateStartOfImapUrl (line 1262)
1 thunderbird.exe nsImapService::GetUrlForUri (line 284)
GetUrlForUri also calls nsImapService::DecomposeImapURI
Flags: blocking-thunderbird3+
Priority: -- → P1
Target Milestone: --- → Thunderbird 3.0b1
Comment 6•17 years ago
|
||
Seen as well. I suspect it's something to do w/ attachments displayed inline (maybe just images?)
Assignee | ||
Comment 7•17 years ago
|
||
I just saw this as well - I suspect on the same e-mail :-)
Assignee | ||
Comment 8•17 years ago
|
||
I believe the issue is '.' in the user name part of uri's is being escaped by the code generating the image uri, but not with our normal folder uri's, so we don't find the folder.
Updated•17 years ago
|
Summary: Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ] → Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ][@ nsImapService::CreateStartOfImapUrl]
Comment 10•17 years ago
|
||
(In reply to comment #8)
> I believe the issue is '.' in the user name part of uri's is being escaped by
> the code generating the image uri, but not with our normal folder uri's, so we
> don't find the folder.
Though it also shows we're not handling the null folder case correctly (or the function is now doing what we don't expect).
Updated•17 years ago
|
Assignee: nobody → bienvenu
Assignee | ||
Comment 11•17 years ago
|
||
this will fix the crashes for now. And images display again in e-mails.
Attachment #337699 -
Flags: superreview?(neil)
Attachment #337699 -
Flags: review?(bugzilla)
Updated•17 years ago
|
Attachment #337699 -
Flags: review?(bugzilla) → review+
Comment 13•17 years ago
|
||
I had a crash with nsImapService::CreateStartOfImapUrl on top, but the steps were slightly different.
It crashed while trying to edit drafts on the gmail drafts folder (even drafts without attachments).
The difference to the other drafts folders is that this one uses a drafts
folder on another "namespace" - inside "[gmail]".
With the patch from this bug applied it doesn't crash anymore, but it fails to edit open the compose window and reports:
JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIMsgComposeService.OpenComposeWindow]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: chrome://messenger/content/mailCommands.js :: ComposeMessage :: line 256" data: no]
Comment 14•17 years ago
|
||
Comment on attachment 337699 [details] [diff] [review]
bulletproof...
> nsCOMPtr<nsIMsgFolder> msgFolder;
> rv = lookup->GetFolderById(folderURI, getter_AddRefs(msgFolder));
>+ // until/unless the folder lookup service returns errors...
At which point you'll write
return lookup->GetFolderById(folderURI, aFolder);
won't you?
Attachment #337699 -
Flags: superreview?(neil) → superreview+
Assignee | ||
Comment 15•17 years ago
|
||
right...
fix checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
![]() |
||
Comment 16•17 years ago
|
||
Verifying fixed. I had a email that crashed with that identical crash previously, and now it doesn't crash anymore with a latest checked-out debug build from a few minutes ago.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080912113316 Shredder/3.0b1pre
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Crash Signature: [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ]
[@ nsImapService::CreateStartOfImapUrl]
You need to log in
before you can comment on or make changes to this bug.
Description
•