274981 - Thunderbird crashes when deleting mail form IMAP inbox - [@ nsImapProtocol::SetupWithUrl]

Status: RESOLVED DUPLICATE of bug 261083

(Thunderbird :: General, defect)

Description

[Bill Gianopoulos [:WG9s]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041215 Firefox/1.0+
Build Identifier: version 1.0 (20041206)

Thunderbird 1.0 release seemss to often crash when trying to delete a message in
an IMAP inbox.  Stack signature nsImapProtocol::SetupWithUrl 52b882d2.  Talkback
ID's TB2592174K, TB2585387E, TB2540587Z.

Reproducible: Sometimes

Comment 1

[timeless]

Incident ID: 2592174
Stack Signature	nsImapProtocol::SetupWithUrl 52b882d2
Product ID	Thunderbird10
Build ID	2004120606
Trigger Time	2004-12-16 16:41:29.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (004a09d5)
URL visited	
User Comments	yet agian deleting e-mail from an IMAP inbox
Since Last Crash	12255 sec
Total Uptime	274990 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp,
line 810
Stack Trace 	
nsImapProtocol::SetupWithUrl 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp,
line 810]
nsImapProtocol::LoadImapUrl 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp,
line 1617]
nsImapIncomingServer::GetImapConnectionAndLoadUrl 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapIncomingServer.cpp,
line 448]
nsImapMockChannel::ReadFromImapConnection 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp,
line 8159]
nsImapMockChannel::OnCacheEntryAvailable 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp,
line 7988]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
EventHandler 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/xpcom/proxy/src/nsProxyEvent.cpp,
line 545]
0x778b0c24
nsBaseCommandController::QueryInterface 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/embedding/components/commandhandler/src/nsBaseCommandController.cpp,
line 53]
0x8b510447

Comment 2

[timeless]

*** This bug has been marked as a duplicate of 261083 ***

Comment 3

[Bill Gianopoulos [:WG9s]]

Well, I suppose you should be able to tell from the stacktrace if this is a
duplicate, however this does not make a good deal of sense.  The problem in bug
261083 was reported on the trunk back in the September timeframe.  This problem
did not exibit itself in any branch builds leading up to the release of
Thunderbird 1.0.  Unless there was trunk code ported to the branch very late
leading up to the release which somehow triggers this I don't quite see why this
happens so much with the release build if I never ran into it in any of the
earlier branch builds.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> The problem in bug 261083 was reported on the trunk back in the September timeframe.

But the problem that bug covers has existed in the mail code for years....

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to comment #4)
> > The problem in bug 261083 was reported on the trunk back in the September
timeframe.
> 
> But the problem that bug covers has existed in the mail code for years....

Well that was kind of my point.  How can a bug which has existed for years cause
the Thunderbird 1.0 build to crash multiple times per day for me if the 1.0RC1
build runs just fine without this crash?

Comment 6

[timeless]

there are lots of ways. as it happens here ...
(a) the code in question was fixed by the changes for that bug
(b) there was probably some other change which made it more likely for the code
path to be reached between rc1 and final. that's not my problem, if you want to
help, you're welcome to.

Comment 7

[Bill Gianopoulos [:WG9s]]

(In reply to comment #6)
> (b) there was probably some other change which made it more likely for the code
> path to be reached between rc1 and final.

OK looks like we are actulaly in agreement then.  My only issue was that a
serious regression was somehow introduced between RC1 and release.  Besides
identifying how to fix it I think The Thunderbird team might be interested in
figuring out what was changed that made this codepath more likely to be taken
and why it would appear that not enough testing was done on that code.

That said I have done a mess of looking through all the code added between RC1
and release, and the only suspicious checkin I found is that for bug 269573
which looks pretty inoccuous on its own, so I suppose this is understandable.

Comment 8

[timeless]

our agreement does not include randomly spamming other crash bugs. if you want
to learn how to do crash analysis, visit irc.mozilla.org and ask for me.
wandering off into the weeds and poking random bugs is not the way to do things.