332060 - IMAP exits a monitor it hasn't entered [@ PR_ExitMonitor - nsImapProtocol::ProcessMailboxUpdate]

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[George Nychis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051217 Firefox/1.0.7
Build Identifier: version 1.5 (20060326)

I can generate this crash every single time.  How I can generate it is by clicking on the subject of an e-mail in my Inbox which is over an IMAP server, and then before that message finishes loading/downloading, i click on two other message subjects. 

Reproducible: Always

Steps to Reproduce:
1. Setup as IMAP
2. Click on message in inbox
3. Click on two other messages before the message you clicked on finishes loading

Actual Results:  

h3dAssertion failure: _PT_PTHREAD_MUTEX_IS_LOCKED(mon->lock.mutex), at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:546
/usr/libexec/mozilla-launcher: line 117:  9961 Aborted                 "$mozbin" "$@"
thunderbird-bin exited with non-zero status (134)

Comment 1

[Pierre Willenbrock]

This also seems to be a bug in seamonkey. Additionally to the above steps, you need a slow imap-server.

Assertion failure: _PT_PTHREAD_MUTEX_IS_LOCKED(mon->lock.mutex), at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:546

Program received signal SIGABRT, Aborted.
[Switching to Thread -1415132256 (LWP 4174)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb746c681 in raise () from /lib/libc.so.6
#2  0xb746dcd9 in abort () from /lib/libc.so.6
#3  0xb7cab66d in PR_Assert (
    s=0xb7cd1ca0 "_PT_PTHREAD_MUTEX_IS_LOCKED(mon->lock.mutex)",
    file=0xb7cd1bdc "../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c",
    ln=546) at ../../../../mozilla/nsprpub/pr/src/io/prlog.c:538
#4  0xb7cc1a32 in PR_ExitMonitor (mon=0x9806c08)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:546
#5  0xb325a6f3 in nsImapProtocol::ProcessMailboxUpdate (this=0x9624e38,
    handlePossibleUndo=0) at nsImapProtocol.cpp:3584
#6  0xb325bfca in nsImapProtocol::SelectMailbox (this=0x9624e38,
    mailboxName=0x960e8d0 "INBOX") at nsImapProtocol.cpp:2678
#7  0xb325cf31 in nsImapProtocol::ProcessSelectedStateURL (this=0x9624e38)
    at nsImapProtocol.cpp:1928
#8  0xb32609b9 in nsImapProtocol::ProcessCurrentURL (this=0x9624e38)
    at nsImapProtocol.cpp:1378
#9  0xb325f3e9 in nsImapProtocol::ImapThreadMainLoop (this=0x9624e38)
    at nsImapProtocol.cpp:1140
#10 0xb325f4ff in nsImapProtocol::Run (this=0x9624e38)
    at nsImapProtocol.cpp:931
#11 0xb7ea72a0 in nsThread::Main (arg=0x96fc3c8) at nsThread.cpp:118
#12 0xb7cc8d03 in _pt_root (arg=0x95fc8e8)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:220
#13 0xb7c6c294 in start_thread () from /lib/libpthread.so.0
#14 0xb74ff52e in clone () from /lib/libc.so.6

Comment 2

[David :Bienvenu]

does this crash on a release build? Because the PR_ASSERT crashing is a debug build "feature"

This is a 1.5 build, not a trunk or 2.0 build? Have you tried a 2.0 or trunk build?

Comment 3

[Pierre Willenbrock]

(In reply to comment #2)
> does this crash on a release build? Because the PR_ASSERT crashing is a debug
> build "feature"
> 
> This is a 1.5 build, not a trunk or 2.0 build? Have you tried a 2.0 or trunk
> build?

This is a Gentoo System, with nspr-4.6.2 and seamonkey-1.0.2. nspr is configured with CFLAGS set to contain -ggdb, which triggers the DEBUG define, i guess. But it did silently crash otherwise.

I tracked this down to the code at nsImapProtocol.cpp:3584(currently at 3700), but i see now, it is fixed in trunk by darin, between revision 1.623 and 1.624.

I will try to verify that it is really this bug that caused the crash.

Comment 4

[Pierre Willenbrock]

I found out that the configure script in this package[1] always defines DEBUG if called without --disable-debug. Is this a bug in the package, or should gentoo  set --disable-debug?

[1] ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6.2/src/nspr-4.6.2.tar.gz

Comment 5

[Luca Barbato]

Also happens on thunderbird 1.5

Comment 6

[Wayne Mery (:wsmwk)]

do you see this with current trunk?

Comment 7

[Wayne Mery (:wsmwk)]

package bug as suggested by comment 4?

signature does not appear on talkback for TB2 nor crash-stats trunk build

Comment 8

[Magnus Melin [:mkmelin]]

I'd assume it's a bug if comment 4 still happens. Pierre/Luca, still valid in http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ ?

Comment 9

[Pierre Willenbrock]

nspr 4.7 still sets DEBUG=1 without --disable-debug. configure --help only talks about the debug symbols, so this may be just a documentation issue.

(Gentoo is now using --disable-debug, so i would not see the negative effects of omitting --disable-debug)

Comment 10

[Magnus Melin [:mkmelin]]

->INVALID then since this was due to building without --disable-debug for nspr. Whether nspr should default to DEBUG=1 would be another bug.

Comment 11

[timeless]

I'm concerned. i really wish we had individual asserts for each possible error state we don't want to hit instead of ASSERT no_error.

Most of the reachable states i could find are deadlocks which means you're going to die and might as well die this way.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

I'll grant that hitting an assertion botch in a (supposedly) non-debug build
is a build issue, but OTOH, the fact that it hits this assertion says that 
something is actually wrong with some code, either IMAP code or NSPR code.
I think that bug should be tracked down and fixed, even if the immediate 
assertion issue is invalid, due to a build error.

Comment 13

[Wan-Teh Chang]

The assertion that failed is at ptsynch.c:546:

540 PR_IMPLEMENT(PRStatus) PR_ExitMonitor(PRMonitor *mon)
541 {
542     pthread_t self = pthread_self();
543 
544     PR_ASSERT(mon != NULL);
545     /* The lock better be that - locked */
546     PR_ASSERT(_PT_PTHREAD_MUTEX_IS_LOCKED(mon->lock.mutex));
547     /* we'd better be the owner */
548     PR_ASSERT(pthread_equal(mon->owner, self));

That assertion failure indicates a mistake in nsImapProtocol's
use of the PRMonitor.  A monitor is a kind of lock.  When you
exit a monitor, you should have entered the monitor before.
The assertion failure shows that isn't true.

So this bug should belong to the Product/Component that contains
nsImapProtocol.cpp.

Comment 14

[Pierre Willenbrock]

Comment #3, mentions that the original bug is fixed since a long time in trunk(cvs rev 1.624 of nsImapProtocol.cpp to be precise).

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

So, maybe the right resolution for this bug is resolved/fixed by the patch 
landed for bug 326273 ?

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #15)
> So, maybe the right resolution for this bug is resolved/fixed by the patch 
> landed for bug 326273 ?

Reporter writes "[I] Run Ubuntu instead of Gentoo, no longer have a poor connection to the IMAP server... So I can no longer reproduce the bug."

Comment 17

[Luca Barbato]

Recent thunderbird do not show the issue in Gentoo

Comment 18

[Wayne Mery (:wsmwk)]

WFM per comment 17 and bienvenu. 
feel free to adjust if you have a better resolution :)