220959 - crash [@ nsTimerImpl::Fire / destroyTimerEvent] if I assign a label to a thread in newsgroup

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[daniel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

If I want to assign a label to a thread in a newsgroup thunderbird crash.
This can be reproduced,...
Okay, since I've tried to write down the steps it can't be reproduced...

Reproducible: Sometimes

Steps to Reproduce:
1. post a message in a newsgroup
2. wait until you see the posting in the ng
3. open the posting (a)
4. click on reply
5. send the reply
6. close window a
7. select the first message of the thread and
   try to set the label (important).

Comment 1

[Matthias Versen [:Matti]]

Can you reproduce this with Mozilla Mailnews ?

Comment 2

[WD]

I've had this happen to me too.   I replied to a thread, then went to set the
label for the thread.  Thunderbird 0.3 crashed. 

Comment 3

[David :Bienvenu]

taking, will try to reproduce - so far, this is just news?

Comment 4

[WD]

Only seen with news so far, but I don't use labels for mail.   :)

Comment 5

[WD]

No luck at all so far in getting a useful stack for this crash.  I think the
stack is being clobbered, as all Visual Studio gives me after a crash is
Disassembly.  Here is the error:
Unhandled exception at 0x004d002f in thunderbird.exe: 0xC0000005: Access
violation writing location 0x111c45a6.

Out of the many times I've reproduced this crash, I once got this stack.  I'm
not sure if it's any help.

 63697373()	
>xpcom.dll!destroyTimerEvent(TimerEventType * event=0x024a2060)  Line 456	C++
 xpcom.dll!PL_DestroyEvent(PLEvent * self=0x024a2060)  Line 710 + 0x4	C
 xpcom.dll!PL_HandleEvent(PLEvent * self=0x024a2060)  Line 682 + 0x6	C
 xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00fd9078)  Line 606 + 0x6	C
 xpcom.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 395	C++
 	429de900()	

Comment 6

[WD]

Attachment: Stack Trace from Debug 0.4 build

This one should be more useful...

Comment 7

[WD]

As for reproducing the crash, I've been able to do it most frequently when there
is network activity going on at the time of flagging a message.  I've set my
account settings in MailNews to check for new messages every 1 minute, and that
seems to help reproduce the crash, but I'm not certain.

mCallback.i is 0xdddddddd which seems to be causing the crash.  Here are the
"autos" window contents from Visual Studio at the point of the crash.
Unhandled exception at 0x00801288 (xpcom.dll) in mozilla.exe: 0xC0000005: Access
violation reading location 0xdddddde9.

	CALLBACK_TYPE_INTERFACE	1	int

-	mCallback	{...}	nsTimerImpl::__unnamed
	c	0x043970b8	void (nsITimer *, void *)*
+	i	0x043970b8	nsITimerCallback *
+	o	0x043970b8	nsIObserver *

-	mCallback.i	0x043970b8	nsITimerCallback *
-	nsISupports	{...}	nsISupports
-	__vfptr	0xdddddddd	*
	[0]	CXX0030: Error: expression cannot be evaluated	*
	[1]	CXX0030: Error: expression cannot be evaluated	*
	[2]	CXX0030: Error: expression cannot be evaluated	*

-	this	0x03d5bfe0	nsTimerImpl * const
+	nsITimer	{...}	nsITimer
+	nsITimerInternal	{...}	nsITimerInternal
+	mRefCnt	{...}	nsAutoRefCnt
+	_mOwningThread	{...}	nsAutoOwningThread
+	mCallingThread	{...}	nsCOMPtr<nsIThread>
	mClosure	0x00000000	void *
+	mCallback	{...}	nsTimerImpl::__unnamed
	mCallbackType	1 '&#9217;'	unsigned char
	mIdle	0	unsigned char
	mType	0	unsigned char
	mFiring	1 '&#9217;'	unsigned char
	mArmed	0	int
	mCanceled	0	int
	mGeneration	712	int
	mDelay	400	unsigned int
	mTimeout	798338760	unsigned int
	mStart	0	unsigned int
	mStart2	0	unsigned int
	sDeltaSum	0.00000000000000000	double
	sDeltaSumSquared	0.00000000000000000	double
	sDeltaNum	0.00000000000000000	double

Comment 8

[David :Bienvenu]

0xdddddddd means freed memory. The thing is, that labelling a news message is
orthogonal to anything involving network traffic. It's a simple, synchronous
event that happens on the ui thread, and it really shouldn't care about anything
else going on.

When you say, check for new messages, do you mean new mail messages, or new
newsgroup messages?

Comment 9

[WD]

I've got it set up to check newsgroup messages every minute.

I can usually trigger the crash by setting the labels for some messages in rapid
succession.   The fact that it's checking for new messages every 1 minute may be
totally unrelated.

Comment 10

[WD]

Here's a talkback from 1.7 crashing after assigning a label:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB59244M

The crash there is in HandleImageOnloadPLEvent

Comment 11

[WD]

Some more talkbacks:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB82205W
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB80447W
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB80442X
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB80428W

The similarities is that the crash always occurs after destroyTimerEvent

Comment 12

[WD]

I believe this issue is limited to Windows only.
I can reproduce it relatively easily on Win98, Win2k, and WinXP, but I have been
unable to reproduce the crash at all on Debian linux.

Comment 13

[WD]

*** Bug 253845 has been marked as a duplicate of this bug. ***

Comment 14

[Adam Hauner]

Jay, there are over 600 incidents with destroyTimerEvent signature, most on
Firefox Aviary, then Aviary Thunderbird, M17 and several on Mozilla Trunk. Some
incidents should have different reason - bug 256795.

Comment 15

[WD]

I still get this with the latest 1.5.0.5 build.
Labels just won't work reliably on the windows platform.

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB23024554E

Stack Trace  	
0x65636361
destroyTimerEvent  [mozilla/xpcom/threads/nsTimerImpl.cpp, line 468]
0x778b0c24
nsFindContentIterator::SetupInnerIterator  [mozilla/embedding/components/find/src/nsFind.cpp, line 409]
0x28f2e900

Comment 16

[Wayne Mery (:wsmwk)]

The remaining question, does this happen on trunk?

(note - reporter, daniel, is unreachable)

Comment 17

[Wayne Mery (:wsmwk)]

WD, have you tried TB 2.0?   WFM v2 beta 1 (20061130) ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8

WFM SM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061119 SeaMonkey/1.5a

WFM TB trunk, per WD  "It's pretty easily repeatable [in TB 1.5].  It sometimes takes some persistence, but it'll happen in time.  I've stopped using labels because of it.    I just tried now and it took 39 seconds - TB23299848M. Haven't been able to reproduce [on trunk] after a minute or two of trying."

Comment 18

[Wayne Mery (:wsmwk)]

closing WFM per WD's last sentence comment 17