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

RESOLVED WORKSFORME

Status

SeaMonkey
MailNews: Message Display
--
critical
RESOLVED WORKSFORME
15 years ago
11 years ago

People

(Reporter: daniel, Unassigned)

Tracking

({crash})

Trunk
x86
Windows 2000
crash

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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).
Can you reproduce this with Mozilla Mailnews ?

Updated

15 years ago
Severity: normal → critical
Keywords: crash
Summary: crash if I assign a label to a thread - see details & steps → crash if I assign a label to a thread

Comment 2

14 years ago
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

14 years ago
taking, will try to reproduce - so far, this is just news?
Assignee: sspitzer → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

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

Comment 5

14 years ago
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

14 years ago
Created attachment 140999 [details]
Stack Trace from Debug 0.4 build

This one should be more useful...

Comment 7

14 years ago
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
Summary: crash if I assign a label to a thread → crash [@ nsTimerImpl::Fire] if I assign a label to a thread

Comment 8

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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
Summary: crash [@ nsTimerImpl::Fire] if I assign a label to a thread → crash [@ nsTimerImpl::Fire / destroyTimerEvent] if I assign a label to a thread

Comment 12

14 years ago
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

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

Comment 14

14 years ago
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.
Product: Browser → Seamonkey

Comment 15

12 years ago
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

12 years ago
The remaining question, does this happen on trunk?

(note - reporter, daniel, is unreachable)
Assignee: bienvenu → mail
Component: MailNews: Subscribe → MailNews: Main Mail Window
QA Contact: stephend
Summary: crash [@ nsTimerImpl::Fire / destroyTimerEvent] if I assign a label to a thread → crash [@ nsTimerImpl::Fire / destroyTimerEvent] if I assign a label to a thread in newsgroup

Comment 17

11 years ago
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

11 years ago
closing WFM per WD's last sentence comment 17
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsTimerImpl::Fire / destroyTimerEvent]
You need to log in before you can comment on or make changes to this bug.