305849 - Crash sending mail through Exchange 2000 server (using IMAP) [crash @ nsMsgProtocol::DoGSSAPIStep2]

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[Mike Stockman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+
Build Identifier: version 1.6a1 (20050823)

Any attempt to send mail on my Exchange 2000 server account at work causes a
crash. Attempting to send mail through other IMAP accounts (for example, my AOL
account configured in the same profile) succeeds.

Talkback ID (among others): TB8670055W

Reproducible: Always

Steps to Reproduce:
1. Launch TBird
2. Compose mail
3. Send


Actual Results:  
Crash

Expected Results:  
Not Crashed

Comment 1

[Scott MacGregor]

nsMsgProtocol::DoGSSAPIStep2 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgProtocol.cpp,
line 946]
nsSmtpProtocol::AuthGSSAPIStep 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp,
line 1001]
nsSmtpProtocol::ProcessProtocolState 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp,
line 1618]
nsMsgProtocol::OnDataAvailable 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgProtocol.cpp,
line 350]
nsInputStreamPump::OnStateTransfer 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 437]
nsInputStreamPump::OnInputStreamReady 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 341]
nsOutputStreamReadyEvent::EventHandler 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/io/nsStreamUtils.cpp,
line 120]
SETUPAPI.DLL + 0x30c24 (0x778b0c24)

Comment 2

[David :Bienvenu]

since this is Windows, we'd be using SSPI, right? You might try going into
options | advanced | config editor and flipping the pref network.auth.use-sspi
to false. That'll probably get around the crash for now, while we figure out why
we're crashing with Exchange 2000.

Comment 3

[David :Bienvenu]

getting an smtp protocol log might be helpful as well, by following these
instructions replacing "protocol" with SMTP.

Comment 4

[David :Bienvenu]

do you have secure authentication turned on for accessing the imap server, to
read mail, under tools | account settings | server settings? If not, does
turning that on crash?

Comment 5

[Mike Stockman]

Thanks for the workaround suggestionss. The results:

1) setting network.auth.use-sspi to false did not work around the problem... it
still crashed

2) I couldn't change the setting for Use Secure Authentication for the IMAP
server to read mail, but then it occurred to me that I was crashing while
sending, so I looked into authentication methods on the SMTP server. I couldn't
find any doc on the Web about this setting:

mail.smtpserver.smtp1.auth_method

So, without being sure what the various methods are, I'll report this: when it
was set to 1, it was crashing. I set it to 0, and it stopped crashing on send.

Let me know if there's other info I can collect.

Comment 6

[David :Bienvenu]

Thx for the info. Turning off secure authentication would definitely fix the
problem - I forgot we had that pref.

Last time, I forgot to paste in the link about how to generate protocol logging.
If you follow these instructions, replacing "protocol" with "SMTP", and
reproduce the crash scenario, the log might help us. (You'd have to turn secure
authentication back on first.)

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

The reason I asked you to try secure authentication for imap was to determine if
the problem is in our core secure authentication code, in which case, imap would
 probably crash as well, or in the smtp sending code. The log above is probably
more helpful, though. What did you mean by "I couldn't change the setting for
Use Secure Authentication for the IMAP server"? Did you not find the UI checkbox
for it, or did that setting not stick, or did authentication just fail when you
turned on secure authentication? One thing to be careful of if you do turn on
secure authentication for imap is that you don't have tbird set to automatically
select the inbox of that server on startup or you might crash on startup every
time :-(

Comment 7

[Simon Wilkinson]

*** Bug 305629 has been marked as a duplicate of this bug. ***

Comment 8

[Simon Wilkinson]

There are assorted talkback entrys from similar crashes, occuring on both
Windows and Linux.

Unfortunately, I'm not going to have a chance to investigate this further until
later on this evening. All of the crashes in talkback are from the SMTP code -
either the problem is unique to this code path, or we're just seeing it there
because its the only place that secure auth is enabled by default.

My current theory is that we're somehow-or-other calling DoGssapiStep2 without
calling Step1, or in a situation where Step1 has failed. However, at the moment,
I can't see route through the SMTP code that would cause this.

It would be good to know if enabling secure auth for either IMAP or POP causes
Thunderbird to crash when fetching mail.

Comment 9

[David :Bienvenu]

we have reason to believe that the nightly builds don't have the auth module in
them - that would mean that DoGSSAPIStep1 should be failing - but I think we're
still getting into step2 after that...even though we're sending the "*" auth
string, I bet we're still getting to Step2 with a null auth module.

Comment 10

[Mike Stockman]

Attachment: SMTP log of the crash

An SMTP log showing the crash after re-enabling SMTP authentication. I changed
the server names to protect my workplace privacy.

Comment 11

[Mike Stockman]

Sorry, forgot to reply to David's comment (#6) about why I couldn't change the
IMAP authentication settings in the UI. It's because of a Preferences dialog bug
where I can make changes, but clicking OK doesn't accept the changes (or dismiss
the dialog). Only cancel is accepted.

I haven't searched for that bug, but I saw some discussion of Preferences dialog
flakiness. Separate issue from this crash, of course...

Comment 12

[David :Bienvenu]

When auth is not installed correctly, if the response code from sending "*" is
3xx, then we will crash. It looks like Exchange isn't returning the correct
error. In any case, if Step1 is failing, should we really be setting
m_nextStateAfterResponse to SMTP_SEND_AUTH_GSSAPI_STEP?

Comment 13

[David :Bienvenu]

I think what I'd prefer here is what we did for pop3, which was to try to init
gssapi before trying it with the server, and caching the response in the
protocol object itself. I can try to code that up, but I can't test it as of
now. We need to get this working quickly, though, since I think they want to
wrap up the beta tonight, and this code landed on the branch yesterday.

Comment 14

[David :Bienvenu]

actually SMTP GSSAPI is simpler - we should be able to just clear the GSSAPI
AUTH flag and return to the state machine and try the next auth method.

Comment 15

[David :Bienvenu]

Attachment: proposed fix

this fix only affects gssapi auth.

If we fail to create gssapi, then we fall back to the next authentication
mechanism instead of doing auth gssapi *. I tested this with an smtp server
with gssapi support, and gssapi logon still works, and if I make the gssapi
first step fail with the debugger, we fall back to auth logon.

Comment 16

[David :Bienvenu]

Simon, does this patch look OK to you?

Comment 17

[Simon Wilkinson]

The patch you've attached looks bogus - it patches nsPop3Protocol?

The approach you've outlined is correct - we should only do GSSAPI if Step1
succeeeds. I thought that's what we were doing, but it looks like the code
committed differs from the code in my local tree...

Following the call to service.Append(hostName) at line 978, the remainder of
AuthGSSAPIFirst() should read:

  rv = DoGSSAPIStep1(service.get(), userName, resp);
  if (NS_FAILED(rv)) {
    ClearFlag(SMTP_AUTH_GSSAPI_ENABLED);
    m_nextState = SMTP_AUTH_PROCESS_STATE;
    return NS_OK;
  }
  else
  {
    command.Append(resp);
    command.Append(CRLF);
    m_nextState = SMTP_RESPONSE;
    m_nextStateAfterResponse = SMTP_SEND_AUTH_GSSAPI_STEP;
    SetFlag(SMTP_PAUSE_FOR_READ);
    nsCOMPtr<nsIURI> url = do_QueryInterface(m_runningURL);
    return SendData(url, command.get());
  }
}

Comment 18

[David :Bienvenu]

Attachment: patch from correct directory

sorry, wrong directory.

Comment 19

[Simon Wilkinson]

Attachment 193853 [details] [diff] looks fine to me.

Is the problem of the auth module not being included likely to be fixed in time
for the betas?

Comment 20

[David :Bienvenu]

that's been fixed (I didn't check in a version of configure.in that turned on
auth for thunderbird), but this needs to be fixed as well, obviously...

Comment 21

[David :Bienvenu]

ok, tomorrow's builds (trunk and branch) should be a lot happier.

Comment 22

[David :Bienvenu]

Mike, if you want to try the latest 1.5 branch build, you can find it here:
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/

or if you want to download a trunk nightly, you can do that as well. It would be
great if you could verify that you can send mail again with
mail.smtpserver.smtp1.auth_method set back to 1. Thx!

Comment 23

[Mike Stockman]

Yes, the latest nightly builds are working without crashing. Thanks for the
quick turnaround on this.

Comment 24

[David :Bienvenu]

thx, marking verified then.