Closed Bug 454061 Opened 17 years ago Closed 17 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: 17 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.

Attachment

General

Created:
Updated:
Size: