Closed Bug 555771 Opened 15 years ago Closed 7 years ago

Crash sending mail w/ NTLM auth after password change [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ]

Categories

(MailNews Core :: Networking, defect)

Product:
MailNews Core
Component:
Networking
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: matthias.andree, Unassigned)

Details

(Keywords: crash)

Crash Data

User-Agent: Opera/9.80 (Windows NT 6.1; U; de) Presto/2.5.22 Version/10.51 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 bp-031b02bb-26b6-4168-ac0e-2de492090531 I'd changed the password on one of my SMTP servers (Cyrus v2.3.16, with NTLM, CRAM-MD5 and PLAIN auth enabled, using SSL). I'm using port 587 (submit) with STARTTLS enabled, have entered my login, enabled auth, and ticked "use secure auth". I could work around this issue by removing the saved password for the incurred SMTP server and re-sending the message. If this doesn't match the backtrace from the crash report, feel free to ask further questions. Reproducible: Always Steps to Reproduce: 1. setup an account as detailed above, save the password (for instance by sending a message and letting thunderbird remember the PW) 2. change the PW through the server's web interface 3. send another email Actual Results: thunderbird crashes, apparently after NTLM authentication failed. Expected Results: presented information that authentication failed and queried the new password. crash report ID (from about:crashes) is bp-031b02bb-26b6-4168-ac0e-2de492090531
Sorry, copy & paste error. Crash Report is bp-ec4c5d92-cef0-4994-ba98-90a352100329
Keywords: crash, crashreportid
Version: unspecified → 3.0
Status: UNCONFIRMED → NEW
Component: General → Networking
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: general → networking
Summary: Crash sending mail w/ NTLM auth after password change → Crash sending mail w/ NTLM auth after password change [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ]
Version: 3.0 → unspecified
0 thunderbird.exe nsMsgProtocol::DoNtlmStep2 mailnews/base/util/nsMsgProtocol.cpp:967 1 thunderbird.exe nsSmtpProtocol::AuthLoginStep2 mailnews/compose/src/nsSmtpProtocol.cpp:1309 2 thunderbird.exe nsSmtpProtocol::ProcessProtocolState mailnews/compose/src/nsSmtpProtocol.cpp:1768 3 thunderbird.exe nsMsgProtocol::OnDataAvailable mailnews/base/util/nsMsgProtocol.cpp:359 4 thunderbird.exe nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:508 5 thunderbird.exe nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:398 6 xpcom_core.dll nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:111 7 xpcom_core.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:521 8 xpcom_core.dll NS_ProcessNextEvent_P objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:247 9 thunderbird.exe nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:170 10 thunderbird.exe nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:193 11 thunderbird.exe XRE_main toolkit/xre/nsAppRunner.cpp:3321 12 thunderbird.exe NS_internal_main mail/app/nsMailApp.cpp:103 13 thunderbird.exe wmain toolkit/xre/nsWindowsWMain.cpp:110 14 thunderbird.exe __tmainCRTStartup objdir-tb/mozilla/memory/jemalloc/src/crtexe.c:591 15 kernel32.dll kernel32.dll@0x51193 16 ntdll.dll __RtlUserThreadStart 17 ntdll.dll
looks like m_authModule is null. This code was changed recently by BenB but I don't know if it would fix the crash or not. There's definitely not a check for null m_authModule in the latest code...
Keywords: crashreportid
Is this with TB2 or TB2? BuildID in initial comment says Thunderbird/2.0.0.23, but crash report says 3.0.3. Matthias Andree, could you please try with a nightly build <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/> (even 3.1 beta1 is too old)? As bienvenu said, I doubt that would fix it, though, as I didn't change the NTLM code. I did change the password prompt code, though.
According to the about requester, the release displayed is 3.0.3; the Build Identifyer contains Thunderbird/2.0.0.23. Not sure where this comes from. Are you proposing that I use the latest package from <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0.4-candidates/>?
turns out that the useragent.override was set, not sure whence. I've reset that option and now the build identifies as: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 Which is in line with the release version. about:buildconfig reports "built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/72fb5a5e3c82" which in turn shows tags THUNDERBIRD_3_0_3_RELEASE THUNDERBIRD_3_0_2_RELEASE THUNDERBIRD_3_0_3_BUILD1 THUNDERBIRD_3_0_2_BUILD1.
Failure persists with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100329 Lightning/1.0b1 Shredder/3.0.5pre see bp-8a9d2a5a-90fb-4282-afd2-7644a2100329 I'll now retry with the version proposed in Comment #7.
Failure persists with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100329 Lightning/1.0b1 Shredder/3.0.5pre see bp-8a9d2a5a-90fb-4282-afd2-7644a2100329 I'll now retry with the version proposed in Comment #7.
Failure also persists with Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.3a4pre) Gecko/20100329 Shredder/3.2a1pre buildconfig: "built from http://hg.mozilla.org/mozilla-central/rev/ad1c22bcdc27" Crash report: bp-a69af43a-66cd-447c-86ba-a45a52100329 HTH
BTW, I deinstalled mnenhy before testing 3.0.5pre.
Signature nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) UUID a69af43a-66cd-447c-86ba-a45a52100329 Time 2010-03-29 14:37:57.602738 Uptime 117 Last Crash 578 seconds before submission Product Thunderbird Version 3.2a1pre Build ID 20100329033522 Branch 1.9.3 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 23 stepping 10 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x0 Crashing Thread Frame Module Signature [Expand] Source 0 thunderbird.exe nsMsgProtocol::DoNtlmStep2 mailnews/base/util/nsMsgProtocol.cpp:979 1 thunderbird.exe nsSmtpProtocol::AuthLoginStep2 mailnews/compose/src/nsSmtpProtocol.cpp:1426 2 thunderbird.exe nsSmtpProtocol::ProcessProtocolState mailnews/compose/src/nsSmtpProtocol.cpp:1889 3 thunderbird.exe nsMsgProtocol::OnDataAvailable mailnews/base/util/nsMsgProtocol.cpp:359 4 thunderbird.exe nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:508 5 thunderbird.exe nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:398 6 xpcom_core.dll nsOutputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:112 7 xpcom_core.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:527 8 xpcom_core.dll NS_ProcessNextEvent_P objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:250
1278 PRInt32 nsSmtpProtocol::AuthLoginStep1() 1314 else if (m_currentAuthMethod == SMTP_AUTH_NTLM_ENABLED || 1315 m_currentAuthMethod == SMTP_AUTH_MSN_ENABLED) 1319 rv = DoNtlmStep1(username.get(), password.get(), response); rv is lost here! 1350 nsCOMPtr<nsIURI> url = do_QueryInterface(m_runningURL); 1351 status = SendData(url, buffer, PR_TRUE); 1352 m_nextState = SMTP_RESPONSE; 1353 m_nextStateAfterResponse = SMTP_AUTH_LOGIN_RESPONSE; 1354 SetFlag(SMTP_PAUSE_FOR_READ); 1355 NS_Free(base64Str); 1356 1357 return (status); 1358 } 1886 PRInt32 nsPop3Protocol::SendUsername() 1911 if (m_currentAuthMethod == POP3_HAS_AUTH_NTLM) 1912 (void) DoNtlmStep1(m_username.get(), password.get(), cmd); rv is IGNORED here!
Crash Signature: [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ]
Crash Signature: [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ] → [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ] [@ nsMsgProtocol::DoNtlmStep2 ]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
bp-0647090c-6cc2-4a86-8261-1f4e30180613 nsMsgProtocol::DoNtlmStep2 Slightly different stack, but not too different
Flags: needinfo?(m_kato)
(In reply to Wayne Mery (:wsmwk) from comment #15) > bp-0647090c-6cc2-4a86-8261-1f4e30180613 nsMsgProtocol::DoNtlmStep2 > > Slightly different stack, but not too different As long as comment #13, this is different issue. Crash reason is that m_authModule might be nullptr.
Flags: needinfo?(m_kato)
bp-0647090c-6cc2-4a86-8261-1f4e30180613 52.8.0 0 xul.dll nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/base/util/nsMsgProtocol.cpp:986 1 xul.dll nsPop3Protocol::SendPassword() C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/local/src/nsPop3Protocol.cpp:2152 2 xul.dll nsPop3Protocol::ProcessProtocolState(nsIURI*, nsIInputStream*, unsigned __int64, unsigned int) C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/local/src/nsPop3Protocol.cpp:3871 3 xul.dll nsMsgProtocol::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/base/util/nsMsgProtocol.cpp:297 4 xul.dll nsInputStreamPump::OnStateTransfer() netwerk/base/nsInputStreamPump.cpp:600
Status: RESOLVED → REOPENED
Crash Signature: [@ nsMsgProtocol::DoNtlmStep2(nsCString&, nsCString&) ] [@ nsMsgProtocol::DoNtlmStep2 ] → [@ nsMsgProtocol::DoNtlmStep2 ]
Resolution: WONTFIX → ---
Gene, is comment 13 something you can address, assuming it still exists?
Flags: needinfo?(gds)
Wayne, Not sure what you are asking. Maybe you mean can I duplicate the crash. If that's what you mean then right now I can't because I only have various IMAP servers and none are setup up for NTLM. It seems like this bug is about sanding mail which would be via SMTP server. What I don't understand is that the reporter is saying he is sending mail via a Cyrus server which is IMAP only, AFAICT. I think I would have to set up an SMTP server (maybe POSTFIX?) and with NTLM security to test this. -gene
Flags: needinfo?(gds)
I was hoping you might be able to say whether there is anything to follow up on comment 13 by code inspection. But taking a step back, in 6 months there are no crash reports other than the one I cited, nor are there any containing Ntlm in the signature, even further, several (most?) of the nsMsgProtocol::* crashes are 52.x only. So perhaps there is nothing worth pursuing here. I'll mark it so, and if you think otherwise we can reopen
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.