557932 - crash nsLDAPConnection::AddPendingOperation

Status: RESOLVED WORKSFORME

(MailNews Core :: LDAP Integration, defect)

Description

[Wayne Mery (:wsmwk)]

crash [@ nsLDAPConnection::AddPendingOperation(nsILDAPOperation*)]

#156 crash for v3.0.4
note: Bug 557928's stack is the same, except this crash adds top frame of nsLDAPConnection::AddPendingOperation

bp-6f51d32b-58e9-421b-8262-a0c092100325
"Modifying a list in my personal address book"

bp-a7e28896-421b-4bea-81e6-d45fe2100317 (truncated stack)
creating appointment

bp-81562743-b010-4733-bb47-903b92100406
sending an email
0	thunderbird-bin	nsLDAPConnection::AddPendingOperation	 directory/xpcom/base/src/nsLDAPConnection.cpp:394
1	thunderbird-bin	nsLDAPOperation::SimpleBind	directory/xpcom/base/src/nsLDAPOperation.cpp:337
2	thunderbird-bin	nsAbLDAPListenerBase::OnLDAPInit	mailnews/addrbook/src/nsAbLDAPListenerBase.cpp:323
3	thunderbird-bin	nsLDAPAutoCompleteSession::OnLDAPInit	mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp:444
4	libxpcom_core.dylib	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
5	libxpcom_core.dylib	nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
6	libxpcom_core.dylib	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:521
7	libxpcom_core.dylib	NS_ProcessPendingEvents_P	nsThreadUtils.cpp:200
8	thunderbird-bin	nsBaseAppShell::NativeEventCallback	widget/src/xpwidgets/nsBaseAppShell.cpp:121
9	thunderbird-bin	nsAppShell::ProcessGeckoEvents	widget/src/cocoa/nsAppShell.mm:418
10	CoreFoundation	CFRunLoopRunSpecific

Comment 1

[timeless]

422 nsLDAPConnection::RemovePendingOperation(nsILDAPOperation *aOperation)
427 NS_ENSURE_TRUE(mPendingOperations, NS_OK); 

369 nsLDAPConnection::AddPendingOperation(nsILDAPOperation *aOperation)
394 if (mPendingOperations->Put(key, aOperation)) { 

you're missing a null check.

(And Init() probably failed, so you should have checked for failure elsewhere)

Comment 2

[Wayne Mery (:wsmwk)]

#48 crash for v3.1.6

Comment 3

[Wayne Mery (:wsmwk)]

nsHashtable::Put(nsHashKey*, void*) same crash?  (first two lines match up)

bp-494f5434-44b4-4c5d-9705-c112a2101110
0	xpcom_core.dll	nsHashtable::Put	xpcom/ds/nsHashtable.cpp:210
1	xpcom_core.dll	nsSupportsHashtable::Put	xpcom/ds/nsHashtable.cpp:814
2	thunderbird.exe	nsLDAPConnection::AddPendingOperation	directory/xpcom/base/src/nsLDAPConnection.cpp:395
3	thunderbird.exe	nsLDAPOperation::SimpleBind	directory/xpcom/base/src/nsLDAPOperation.cpp:337
4	thunderbird.exe	nsAbLDAPListenerBase::OnLDAPInit	mailnews/addrbook/src/nsAbLDAPListenerBase.cpp:323
5	thunderbird.exe	nsLDAPAutoCompleteSession::OnLDAPInit	mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp:444
6	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> 422 nsLDAPConnection::RemovePendingOperation(nsILDAPOperation *aOperation)
> 427 NS_ENSURE_TRUE(mPendingOperations, NS_OK); 
> 
> 369 nsLDAPConnection::AddPendingOperation(nsILDAPOperation *aOperation)
> 394 if (mPendingOperations->Put(key, aOperation)) { 
> 
> you're missing a null check.
> 
> (And Init() probably failed, so you should have checked for failure elsewhere)

thanks timeless!

80-90% have calendar installed or mention calendar in the crash comments

~#11 crash for v3.1.7 when combined with nsHashtable::Put(nsHashKey*, void*).
so nominating wanted for 3.1

Comment 5

[Mark Banner (:standard8)]

Given that this seems to be related to calendar, and the location of the crash, I think it will be significantly reduced or eliminated once bug 511484 lands on branch (which it will do for 3.1.8).

Although its a slightly different stack, that crash in that bug would probably occur slightly later in time than the functions here are hit, so its conceivable that they have the same cause.

Comment 6

[Wayne Mery (:wsmwk)]

crash rate actually higher. up now at #7 for v3.1.10, despite patch in  bug 511484  landing for v3.1.8 (according to the bug)

very few duplicate crashes in the list. in fact, skimming install times it looks like there might be lots of people (did a good skim) rather than a few people with lots of crashes (though install time is by no means a measure of user uniqueness)
https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-06-08%2010%3A00%3A00&signature=nsLDAPConnection%3A%3AAddPendingOperation%28nsILDAPOperation*%29&version=Thunderbird%3A3.1.10

however, there no crashes for 3.3.anything or 5.0.anything going back 9 months - so no joy there. Can't say whether the patch had any effect on trunk or sub.trunk builds.

Comment 7

[Ginn Chen]

There is one crash for 5.0 on Mac
https://crash-stats.mozilla.com/report/index/3c124982-82b2-4ac9-9753-31c362111012

Also I saw one core stack for 6.0 on Solaris.

Comment 8

[James C. McPherson]

I see this repeatedly with Solaris 11 and thunderbird 6.0.2:


08046498 libc_hwcap2.so.1`_lwp_kill+7(1, b, 80464b8, fbd00d41)
080464b8 libc_hwcap2.so.1`raise+0x25(b, 80464e0, 0, fc90499e)
08046508 libxul.so`__1cNnsProfileLockSFatalSignalHandler6FipnHsiginfo_pv_v_+0x114(b, 80467f0, 80465f0, 
fbd2db67, b, fbdf1000)
08046528 libc_hwcap2.so.1`__sighndlr+0x15(b, 80467f0, 80465f0, fc904990)
08046598 libc_hwcap2.so.1`call_user_handler+0x2af(b)
080465dc libc_hwcap2.so.1`sigacthandler+0xee(b, 80467f0, 80465f0)
080468a8 libxul.so`__1cQnsLDAPConnectionTAddPendingOperation6MIpnQnsILDAPOperation__I_+0x53(ef6931a0, 1
, f2d9c200, fe07dfa5)
08046958 libxul.so`__1cPnsLDAPOperationKSimpleBind6MrknTnsACString_internal__I_+0x148(f2d9c200, 8046e90
, f72bf920, 0)
08046f08 libxul.so`__1cUnsAbLDAPListenerBaseKOnLDAPInit6MpnRnsILDAPConnection_I_I_+0xb53(f1bf2e20, 
f2da3b80, 0, fdf2cf44)
08046f28 libxul.so`__1cZnsLDAPAutoCompleteSessionKOnLDAPInit6MpnRnsILDAPConnection_I_I_+0x24(f1bf2e20, 
f2da3b80, 0, f2f835e0, feb1bdbc, f1bf2e20)
08046f58 libxul.so`NS_InvokeByIndex_P+0x51(f1bf2e20, 4, 2, e70623a0)
08046f78 libxul.so`__1cVnsProxyObjectCallInfoDRun6M_I_+0x28(f2f835e0, 0, 8046fac, 0)
08046ff8 libxul.so`__1cInsThreadQProcessNextEvent6Mipi_I_+0x257(faa8efa0, 0, 804701c, fe1b80f1)
08047028 libxul.so`__1cVNS_ProcessNextEvent_P6FpnJnsIThread_i_i_+0x42(faa8efa0, 0, feb444b8, fe0c5cf5)
08047068 libxul.so`__1cHmozillaDipcLMessagePumpDRun6MpnEbaseLMessagePumpIDelegate__v_+0x72(f960a0d0, 
faaa03f0, 8047098, fe26a4b0)
08047098 libxul.so`__1cLMessageLoopDRun6M_v_+0x35(faaa03f0, feb1bdbc)
080470c8 libxul.so`__1cOnsBaseAppShellDRun6M_I_+0x40(f96a9b50, 0, 0, fd885948)
080470e8 libxul.so`__1cMnsAppStartupDRun6M_I_+0x32(f8a73c10, faa01210, 8047344, 0)
08047518 libxul.so`XRE_main+0x2671(3)
08047568 main+0xa1(3, 804759c, 80475ac, 8047590)
08047590 _start+0x7d(3, 8047710, 0, 0, 0, 8047742)


Demangling in libxul:

__1cNnsProfileLockSFatalSignalHandler6FipnHsiginfo_pv_v_ == void nsProfileLock::FatalSignalHandler(int,siginfo*,void*)
__1cQnsLDAPConnectionTAddPendingOperation6MIpnQnsILDAPOperation__I_ == unsigned nsLDAPConnection::AddPendingOperation(unsigned,nsILDAPOperation*)
__1cPnsLDAPOperationKSimpleBind6MrknTnsACString_internal__I_ == unsigned nsLDAPOperation::SimpleBind(const nsACString_internal&)
__1cUnsAbLDAPListenerBaseKOnLDAPInit6MpnRnsILDAPConnection_I_I_ == unsigned nsAbLDAPListenerBase::OnLDAPInit(nsILDAPConnection*,unsigned)
__1cZnsLDAPAutoCompleteSessionKOnLDAPInit6MpnRnsILDAPConnection_I_I_ == unsigned nsLDAPAutoCompleteSession::OnLDAPInit(nsILDAPConnection*,unsigned)
NS_InvokeByIndex_P == NS_InvokeByIndex_P
__1cVnsProxyObjectCallInfoDRun6M_I_ == unsigned nsProxyObjectCallInfo::Run()
__1cInsThreadQProcessNextEvent6Mipi_I_ == unsigned nsThread::ProcessNextEvent(int,int*)
__1cVNS_ProcessNextEvent_P6FpnJnsIThread_i_i_ == int NS_ProcessNextEvent_P(nsIThread*,int)
__1cHmozillaDipcLMessagePumpDRun6MpnEbaseLMessagePumpIDelegte__v_ == void mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)
__1cLMessageLoopDRun6M_v_ == void MessageLoop::Run()
__1cOnsBaseAppShellDRun6M_I_ == unsigned nsBaseAppShell::Run()
__1cMnsAppStartupDRun6M_I_ == unsigned nsAppStartup::Run()
XRE_main == XRE_main


I've noticed that this seems to happen for specific address entries in my abook.mab, but not 
all the time - sometimes they'll complete ok. however, if I make a typo and edit the address
in the to/cc/bcc fields, that almost always induces the crash.

Datapoint: I haven't seen this crash with the calendar module.

Comment 9

[Wayne Mery (:wsmwk)]

will the null check be sufficient ?


I don't knwo what the signature is for windows crashes, if there is one.  but for linux and Mac this seems to live on as nsCOMPtr_base::assign_with_AddRef | nsLDAPConnection::AddPendingOperation bp-290ead46-2ce5-4b48-b330-19dd02121119

Comment 10

[Wayne Mery (:wsmwk)]

topcrashes for 17.0.2esr ... #1 and #3 signatures

[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | nsBaseHashtable<PrincipalKey, nsCOMPtr<nsIPrincipal>, nsIPrincipal*>::Put(nsIPrincipal const*, nsIPrincipal*, mozilla::fallible_t const&) ] 
bp-c8191a53-2ce1-4161-8c38-b0d452130212

nsBaseHashtableMT<nsUint32HashKey, nsCOMPtr<nsILDAPOperation>, nsILDAPOperation*>::Put(unsigned int const&, nsILDAPOperation*) 
bp-b34375fe-500c-464a-9c2e-dfdb42130218

These signatures are pretty much *esr-only*.  I haven't checked source lines, but I assume they are the same as this bug report.

Comment 11

[Wayne Mery (:wsmwk)]

#8 crash for 17.0.2esr [@ @0x0 | nsBaseHashtableMT<nsUint32HashKey, nsCOMPtr<nsILDAPOperation>, nsILDAPOperation*>::Put(unsigned int const&, nsILDAPOperation*) ]

Comment 12

[Wayne Mery (:wsmwk)]

James,
Can you still reproduce?

Comment 13

[James C. McPherson]

I can't reproduce this with firefox 19

Comment 14

[Wayne Mery (:wsmwk)]

most crashes with email addresses are Oracle :)

Mac signature
nsBaseHashtableMT<nsUint32HashKey, nsCOMPtr<nsILDAPOperation>, nsILDAPOperation *>::Put
bp-d8c1f7f0-8b73-438e-bdde-205bb2130315

Comment 15

[Wayne Mery (:wsmwk)]

I'm not finding any signifcant activity for the signatures that might exist today.  And not many crashes for any signatures with @oracle.com, like there had been in the past.