Closed Bug 617721 Opened 9 years ago Closed 8 years ago

(startup) crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] and [@ nsPop3Protocol::LoadUrl] (Mac)

Categories

(MailNews Core :: Networking: POP, defect, critical)

1.9.2 Branch
x86
All
defect
Not set
critical

Tracking

(thunderbird6+ fixed, thunderbird7+ fixed)

VERIFIED FIXED
Thunderbird 8.0
Tracking Status
thunderbird6 + fixed
thunderbird7 + fixed

People

(Reporter: wsmwk, Assigned: Bienvenu)

References

()

Details

(Keywords: crash, topcrash, Whiteboard: [gs][gsolved])

Crash Data

Attachments

(1 file)

crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)]

two flavors
1. with biff
bp-8f16cee3-291a-486c-bae3-f9ff22101111
EXCEPTION_ACCESS_VIOLATION_READ
0x212e3cd0
0		@0x212e3cd0	
1	thunderbird.exe	nsPop3Protocol::LoadUrl	mailnews/local/src/nsPop3Protocol.cpp:1053
2	thunderbird.exe	nsPop3Service::RunPopUrl	mailnews/local/src/nsPop3Service.cpp:293
3	thunderbird.exe	nsPop3Service::GetMail	mailnews/local/src/nsPop3Service.cpp:165
4	thunderbird.exe	nsPop3Service::GetNewMail	mailnews/local/src/nsPop3Service.cpp:104
5	thunderbird.exe	nsPop3IncomingServer::PerformBiff	mailnews/local/src/nsPop3IncomingServer.cpp:436
6	thunderbird.exe	nsMsgBiffManager::PerformBiff	mailnews/base/src/nsMsgBiffManager.cpp:343 

2. without biff
bp-715d3d96-86f6-4f15-bbee-fa9e52101114
EXCEPTION_ACCESS_VIOLATION_READ
0x0
0	thunderbird.exe	nsPop3Protocol::LoadUrl	mailnews/local/src/nsPop3Protocol.cpp:1007
1	thunderbird.exe	nsPop3Service::RunPopUrl	mailnews/local/src/nsPop3Service.cpp:293
2	thunderbird.exe	nsPop3Service::GetMail	mailnews/local/src/nsPop3Service.cpp:165
3	thunderbird.exe	nsPop3Service::GetNewMail	mailnews/local/src/nsPop3Service.cpp:104
4	thunderbird.exe	nsPop3GetMailChainer::RunNextGetNewMail	mailnews/local/src/nsPop3IncomingServer.cpp:779
5	thunderbird.exe	nsPop3GetMailChainer::GetNewMailForServers	mailnews/local/src/nsPop3IncomingServer.cpp:735
6	thunderbird.exe	nsPop3IncomingServer::DownloadMailFromServers	mailnews/local/src/nsPop3IncomingServer.cpp:534
7	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
2 looks like m_pop3Server is null
Crash Signature: [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)]
bienvenu, do we need a protocol log?

topcrash in v5 using _raw_ crash count, but many are marked duplicate.
about 50% startup crash

Mac signature nsPop3Protocol::LoadUrl
Crash Signature: [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] → [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] [@ nsPop3Protocol::LoadUrl ]
Keywords: topcrash
OS: Windows Vista → All
Summary: crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] → crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] and [@ nsPop3Protocol::LoadUrl] (Mac)
bienvenu, for some reason, in TB5 this has increased to become #12 crash for TB5. ([1] there are lots of crashes marked duplicate, but even if you cut it by 1/3 it's still top 20, plus in TB3 it's not even top 300) 

perhaps a regression creeped in, or something in TB5 is now tickling it.

bp-eead3a41-a620-449a-8dfc-f3aed2110728 from http://getsatisfaction.com/mozilla_messaging/topics/cannot_open_thunderbird-1mxitd
0 	xul.dll 	nsPop3Protocol::LoadUrl 	mailnews/local/src/nsPop3Protocol.cpp:1074
1 	xul.dll 	nsPop3Service::RunPopUrl 	mailnews/local/src/nsPop3Service.cpp:286
2 	xul.dll 	nsPop3Service::GetMail 	mailnews/local/src/nsPop3Service.cpp:164
3 	xul.dll 	nsPop3Service::GetNewMail 	mailnews/local/src/nsPop3Service.cpp:103
4 	xul.dll 	nsPop3GetMailChainer::RunNextGetNewMail 	mailnews/local/src/nsPop3IncomingServer.cpp:778
5 	xul.dll 	nsPop3GetMailChainer::GetNewMailForServers 	mailnews/local/src/nsPop3IncomingServer.cpp:734
6 	xul.dll 	nsPop3IncomingServer::DownloadMailFromServers 	mailnews/local/src/nsPop3IncomingServer.cpp:533


[1] https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsPop3Protocol%3A%3ALoadUrl%28nsIURI%2A%2C%20nsISupports%2A%29&reason_type=contains&date=07%2F30%2F2011%2010%3A52%3A03&range_value=4&range_unit=weeks&hang_type=any&process_type=all&do_query=1&signature=nsPop3Protocol%3A%3ALoadUrl%28nsIURI%2A%2C%20nsISupports%2A%29
Summary: crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] and [@ nsPop3Protocol::LoadUrl] (Mac) → (startup) crash [@ nsPop3Protocol::LoadUrl(nsIURI*, nsISupports*)] and [@ nsPop3Protocol::LoadUrl] (Mac)
Whiteboard: [gs]
easy fix is the checking whether m_pop3Server is null.

Root cause is aURL isn't nsIMsgMailNewsUrl.  But, I don't investigate yet why nsIURL isn't nsIMsgMailNewsUrl
(In reply to comment #4)
> easy fix is the checking whether m_pop3Server is null.
> 
> Root cause is aURL isn't nsIMsgMailNewsUrl.  But, I don't investigate yet
> why nsIURL isn't nsIMsgMailNewsUrl
I think it's equally likely (or unlikely) that the server isn't a pop3 server.
Turned out that we were creating a url that we couldn't parse, but not checking for that error. I have a patch that adds the error checking, which will prevent the crash on startup. I think we'll want to fix this for TB 6. I'll try to figure out what regressed such that we now crash and see if I can't fix that as well.
nsAuthURLParser::ParseAuthority(const char *auth, PRInt32 authLen,

now fails on a port of 0, which is what the user I've been working with had set in his prefs.
Status: NEW → ASSIGNED
Attached patch proposed fixSplinter Review
The basic fix is to check for errors setting a url spec, and building a pop3 url. That fixes the crash. The rest of the fix is to use the default port when there's a port of 0 specified in the prefs. I'm assuming a port of 0 isn't meaningful; in any case, necko can't handle it, so our best bet is to use the default.
Assignee: nobody → dbienvenu
Attachment #550214 - Flags: review?(mbanner)
Comment on attachment 550214 [details] [diff] [review]
proposed fix

Looks good, iirc 0 has been used as a "default" value in the past. I could reproduce the crash without the patch and not reproduce it with the patch.
Attachment #550214 - Flags: review?(mbanner)
Attachment #550214 - Flags: review+
Attachment #550214 - Flags: approval-comm-beta+
Attachment #550214 - Flags: approval-comm-aurora+
fixed on trunk - http://hg.mozilla.org/comm-central/rev/5ba3c4ec6992

Standard8 says he'll roll the fix into alpha and beta channels.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 8.0
Thanks!

Tevor confirms this is fixed in earlybird.
http://getsatisfaction.com/mozilla_messaging/topics/cannot_open_thunderbird-1mxitd#reply_6297614
Whiteboard: [gs] → [gs][gsolved]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.