183497 - nsImapProtocol::~nsImapProtocol fatally asserted destroying a lock

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[timeless]

cvs build from two weeks ago
    PR_ASSERT(lock->owner == 0);

-	lock->owner	0x06e19b80
|	state	2
|	priority	1
|	arg	0x064ef988
|	startFunc	0x100773f0 nsThread::Main(void *)
|+	stack	0x13daeb58
|	environment	0x00000000
|	dump	0x00000000
|	dumpArg	0x00000000
|	tpdLength	128
|	privateData	0x07761f28
|	errorCode	0
|	osErrorCode	0
|	errorStringLength	0
|	errorStringSize	0
|+	errorString	0x00000000 ""
|+	threadLock	{...}
|	queueCount	0
|	waitCount	0
|+	active	{...}
|+	links	{...}
|+	waitQLinks	{...}
|+	lockList	{...}
|	sleep	0
|+	wait	{...}
|	id	4696
|	flags	128
|	no_sched	0
|+	term	0x00000000
|+	cpu	0x00000000
|	threadAllocatedOnStack	0
|	io_pending	0
|	io_fd	0
|	io_suspended	0
\+	md	{...}

PR_Assert(const char * 0x3002f5a8 `string', const char * 0x3002f554 `string',
int 213) line 518
PR_DestroyLock(PRLock * 0x19cb3430) line 213 + 31 bytes
PR_DestroyMonitor(PRMonitor * 0x19ec8238) line 82 + 14 bytes
nsImapProtocol::~nsImapProtocol() line 554 + 16 bytes
nsImapProtocol::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsImapProtocol::Release(nsImapProtocol * const 0x193eb5c0) line 296 + 147 bytes
nsCOMPtr<nsIRunnable>::assign_assuming_AddRef(nsIRunnable * 0x00000000) line 473
nsCOMPtr<nsIRunnable>::assign_with_AddRef(nsISupports * 0x00000000) line 915
nsCOMPtr<nsIRunnable>::operator=(nsIRunnable * 0x00000000) line 585
nsThread::Main(void * 0x064ef988) line 140
_PR_NativeRunThread(void * 0x06e19b80) line 433 + 13 bytes
MSVCRTD! 1020c323()
KERNEL32! 77e92ca8()

other threads:
NTDLL! 77f8a122()
KERNEL32! 77e88787()
_PR_WaitCondVar(PRThread * 0x11d00a48, PRCondVar * 0x1927df50, PRLock *
0x06d3b920, unsigned int 74573) line 201 + 23 bytes
PR_Wait(PRMonitor * 0x1970b370, unsigned int 74573) line 171 + 29 bytes
nsImapProtocol::ImapThreadMainLoop() line 1125 + 20 bytes
nsImapProtocol::Run(nsImapProtocol * const 0x12e8588c) line 908
nsThread::Main(void * 0x038fc4a0) line 123 + 26 bytes
_PR_NativeRunThread(void * 0x11d00a48) line 433 + 13 bytes
MSVCRTD! 1020c323()
KERNEL32! 77e92ca8()

nsImapProtocol::ImapThreadMainLoop() line 1125 + 20 bytes
    PR_EnterMonitor(m_urlReadyToRunMonitor); <-- owns monitor

    PRStatus err;

    err = PR_Wait(m_urlReadyToRunMonitor, sleepTime); <-- running here still
owning monitor

    PR_ExitMonitor(m_urlReadyToRunMonitor);

When i crashed there was a newmail notification thingee on the screen

Comment 1

[David :Bienvenu]

were you doing anything at the time? shutting down? or just sitting there? Is it
possible that you'd been disconnected from the imap server or something?

You're showing two different, unrelated imap theads, and there's one imap
protocol object per thread, so you're not talking about the same monitor.

Comment 2

[timeless]

it's possible that the imap server connnection got stuck (i run imap over ttssh
forwarding, when someone tries to connect to that port from a place other than
localhost the forwarding blocks, and i get a dialog, but i don't remember
getting such a dialog), however not very likely since it had obviously just
worked to get new mail. i wasn't shutting down.

i'm pretty sure i was just reading mail or doing normal browsing stuff.

sorry that was the only other thread that looked remotely interesting, i don't
know much about mozilla locks/monitors especially not in mailnews.

Comment 3

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 4

[timeless]

the assertion ere mentions in bug 221491 comment 16 is vaguely familiar, but i 
obviously can't say if i saw that assert in the session for my crash :)

Comment 5

[David :Bienvenu]

I think this might have been fixed by the patch in 221023 - I think the body id
monitor wasn't cleared in some situations.

Comment 6

[David :Bienvenu]

I checked in a change for bug 221023 that I believe may have fixed this, so I'm
marking this fixed. We weren't releasing the body id monitor in a certain
failure case, and that would generate the assertion on destruction of the
protocol object (and since it's a PR_Assert, it aborts).