Closed Bug 454061 Opened 14 years ago Closed 14 years ago

Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ][@ nsImapService::CreateStartOfImapUrl]

Categories

(Thunderbird :: General, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0a3

People

(Reporter: Paenglab, Assigned: Bienvenu)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

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
I get this for non-gmail IMAP servers, as well (on both Windows and Mac)
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, this occurs with only -some- of the messages I have which have attachments, not all, fwiw.
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
Blocks: 441437
Keywords: crash, regression
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
Seen as well.  I suspect it's something to do w/ attachments displayed inline (maybe just images?)
I just saw this as well - I suspect on the same e-mail :-)
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.
Summary: Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ] → Crash [@ nsImapService::MessageURIToMsgHdr(char const*, nsIMsgDBHdr**) ][@ nsImapService::CreateStartOfImapUrl]
(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).
Assignee: nobody → bienvenu
Attached patch bulletproof...Splinter Review
this will fix the crashes for now. And images display again in e-mails.
Attachment #337699 - Flags: superreview?(neil)
Attachment #337699 - Flags: review?(bugzilla)
Attachment #337699 - Flags: review?(bugzilla) → review+
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 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+
right...

fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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
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.