Closed Bug 519507 Opened 15 years ago Closed 15 years ago

Crashes in [@fastcopy_I]

Categories

(MailNews Core :: Networking: NNTP, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0rc1

People

(Reporter: rkent, Assigned: rkent)

References

Details

(Whiteboard: [no l10n impact])

Attachments

(1 file)

I've been crashing with this signature repeatedly for the last week or so. I captured a crash in Visual Studio, and I have the following stack which is more detailed than crashstats shows:

 	msvcr80.dll!7814500a() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for msvcr80.dll]	
>	xpcom_core.dll!NS_CopySegmentToBuffer(nsIInputStream * inStr=0x07594fb8, void * closure=0x00000000, const char * buffer=0x0d0f5058, unsigned int offset=0x00000000, unsigned int count=0x00000b24, unsigned int * countWritten=0x0012faa8)  Line 672	C++
 	xpcom_core.dll!nsPipeInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* writer=0x002eb80c, void * closure=0x00000000, unsigned int count=0x00000b24, unsigned int * readCount=0x00000b24)  Line 801	C++
 	xpcom_core.dll!nsPipeInputStream::Read(char * toBuf=0x00000000, unsigned int bufLen=0x00000b24, unsigned int * readCount=0x0012fb1c)  Line 828	C++
 	xpcom_core.dll!nsInputStreamTee::Read(char * buf=0x00000000, unsigned int count=0x00000b24, unsigned int * bytesRead=0x0012fb1c)  Line 139	C++
 	thunderbird.exe!TokenStreamListener::OnDataAvailable(nsIRequest * aRequest=0x0a807998, nsISupports * aContext=0x0aa8bf50, nsIInputStream * aInputStream=0x04a29438, unsigned int aOffset=0x00000000, unsigned int aCount=0x00000b24)  Line 1137	C++
 	thunderbird.exe!nsStreamListenerTee::OnDataAvailable(nsIRequest * request=0x0a807998, nsISupports * context=0x0aa8bf50, nsIInputStream * input=0x07594fb8, unsigned int offset=0x00000000, unsigned int count=0x00000b24)  Line 97 + 0x18 bytes	C++
 	thunderbird.exe!nsNNTPProtocol::DisplayArticle(nsIInputStream * inputStream=0x00000b24, unsigned int length=0x00000b68)  Line 2480	C++
 	thunderbird.exe!nsNNTPProtocol::ReadArticle(nsIInputStream * inputStream=0x170dec70, unsigned int length=0x00000b68)  Line 2530 + 0xb bytes	C++
 	thunderbird.exe!nsNNTPProtocol::ProcessProtocolState(nsIURI * url=0x07d61918, nsIInputStream * inputStream=0x170dec70, unsigned int sourceOffset=0x000003cb, unsigned int length=0x00000b68)  Line 4876	C++
 	thunderbird.exe!nsMsgProtocol::OnDataAvailable(nsIRequest * request=0x0b75f180, nsISupports * ctxt=0x07d61918, nsIInputStream * inStr=0x170dec70, unsigned int sourceOffset=0x000003cb, unsigned int count=0x00000b68)  Line 359 + 0x14 bytes	C++
 	thunderbird.exe!nsInputStreamPump::OnStateTransfer()  Line 508 + 0x18 bytes	C++
 	thunderbird.exe!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x170dec70)  Line 399	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::Run()  Line 112	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x0012fc7c)  Line 522	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00000001, int mayWait=0x00000001)  Line 227 + 0xd bytes	C++
 	thunderbird.exe!nsBaseAppShell::Run()  Line 170 + 0x9 bytes	C++
 	thunderbird.exe!nsAppStartup::Run()  Line 194	C++
 	thunderbird.exe!XRE_main(int argc=0x00000001, char * * argv=0x018f9ee0, const nsXREAppData * aAppData=0x018f9fb0)  Line 3323	C++
 	thunderbird.exe!NS_internal_main(int argc=0x00000001, char * * argv=0x018f9ee0)  Line 104	C++
 	thunderbird.exe!wmain(int argc=0x018f9ee0, unsigned short * * argv=0x018f7bd0)  Line 112	C++
 	thunderbird.exe!__tmainCRTStartup()  Line 583 + 0x17 bytes	C
 	kernel32.dll!7c817077() 	
 	thunderbird.exe!NameSpaceDecl::~NameSpaceDecl()  + 0xf bytes	C++
 	thunderbird.exe!nsProfileLock::nsProfileLock(nsProfileLock & src={...})  Line 99	C++
 	thunderbird.exe!nsHTMLEditor::SetCSSBackgroundColor(const nsAString_internal & aColor=)  Line 5518	C++
 	thunderbird.exe!nsBaseDOMException::ToString(char * * aReturn=0x0069006e)  Line 366	C++
 	thunderbird.exe!nsHTMLEditor::SetCSSBackgroundColor(const nsAString_internal & aColor={...})  Line 5518	C++
 	xpsp2res.dll!02e08359()
The TokenStreamListener class is part of the bayes classifier, so this crash is occurring as part of trying to do junk analysis of news. That explains why I am virtually the only one seeing it.
I think the fix is pretty easy. TokenStreamListener only allocates the write buffer in OnStartRequest, and elsewhere assumes it is available. The crash is occurring in OnDataAvailable called when the buffer mBuffer is null - or so I think. There is some other issue, as VS claims that "this" is zero when I try to examine TokenStreamListener directly.

But I can at least fix the allocation and checks of the buffer, and hopefully that will stop the crash.
Assignee: nobody → kent
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird 3.0rc1
Here' my first cut at this. I'm going to run a local build with this for a few days to see if the crash goes away. I also need to rethink some more the implications of doing this.
> There is some other issue, as VS claims that "this" is zero when I try
to examine TokenStreamListener directly.

I think that's Visual Studio's fault. I was able to get to the TokenStreamListener instance by going up to an earlier stack frame and getting to it from there. mBuffer is indeed null.

> Lee, I'm curious why you have bayes processing enabled for NNTP. Did you do
that intentionally?

I wasn't even aware that was possible! (I don't see any UI for it, either.) I did use TaQuilla at one point, though it's currently disabled. Could that have enabled this somehow...?
(In reply to comment #5)
> 
> > Lee, I'm curious why you have bayes processing enabled for NNTP. Did you do
> that intentionally?
> 
> I wasn't even aware that was possible! (I don't see any UI for it, either.) I
> did use TaQuilla at one point, though it's currently disabled. Could that have
> enabled this somehow...?

There is no UI for it, it's only possible now through extensions, though there is significant support for it in the base program. I was going to provide the options in JunQuilla to enable it, unless bugs like this make it unstable.

TaQuilla would have done it. You probably used it on a newsgroup. I need to figure out how to make sure it is disabled when the extension itself is disabled.
Comment on attachment 403701 [details] [diff] [review]
allocate mBuffer if its not allocated in onDataAvailable

I've run this now for a few days, and it solves my crash. This is a low-risk patch that is necessary for the junk support in news.
Attachment #403701 - Flags: superreview?(bienvenu)
Attachment #403701 - Flags: review?(bienvenu)
Attachment #403701 - Flags: approval-thunderbird3?
Attachment #403701 - Flags: approval-seamonkey2.0?
Comment on attachment 403701 [details] [diff] [review]
allocate mBuffer if its not allocated in onDataAvailable

looks good, thx
Attachment #403701 - Flags: superreview?(bienvenu)
Attachment #403701 - Flags: superreview+
Attachment #403701 - Flags: review?(bienvenu)
Attachment #403701 - Flags: review+
Attachment #403701 - Flags: approval-thunderbird3?
Attachment #403701 - Flags: approval-thunderbird3+
Comment on attachment 403701 [details] [diff] [review]
allocate mBuffer if its not allocated in onDataAvailable

Checked in as http://hg.mozilla.org/comm-central/rev/61983b31afc0
Attachment #403701 - Flags: approval-seamonkey2.0?
Whiteboard: [no l10n impact]
Severity: normal → critical
Summary: Crashes in fastcopy_I → Crashes in [@fastcopy_I]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: