this is debian unstable 64bits.

tried 5 previous builds, and none crashed, but would loop around the ISA Server 

(No comment was entered for this change.)

(No comment was entered for this change.)

Original title reported an ERROR with http_auth_gssapi_posix.cc, but the crash is actually in a different location.

Andy, it may make sense to downgrade the ERROR for no credentials to a WARNING (or even INFO) as it's an environment issue instead of a Chrome issue.

Curious - NULL username and password are passed into the NTLM authenticator despite the fact that this does not allow default credentials on non-Windows builds. 

has there been no progress on this?
i've tested all daily builds since the bug was reported and still cant make chromium work with ISA server on debian.
Chrome 6.0.472.22 dev on WinXP works fine :(

I'm unable to repro on my local ubuntu box. I'll add some additional logging today so you can test on the next daily build. Thanks for helping look into this.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=55109 

------------------------------------------------------------------------
r55109 | cbentzel@chromium.org | 2010-08-05 12:28:20 -0700 (Thu, 05 Aug 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.cc?r1=55109&r2=55108

Leftovers from wstring->string16 conversion in authentication code.

I'm really confused how this even compiled in the first case (such as the npos comparison).

BUG=50517
TEST=net_unittests, tested on Ubuntu against NTLM server + proxy.

Review URL: http://codereview.chromium.org/2808107
------------------------------------------------------------------------

is there need for newer logs?

I have been affected by this bug. How can I help? Or is it fixed? If so, I can test the fixed revision for you.

still not fixed
  Installed: 7.0.498.0~svn20100818r56475-0ubuntu1~ucd1~lucid

almost 2 months to fix a proxy bug :(

ch 15.7 KB   View   Download

7.0.503.0 (57022) still has this.
So i'm assuming that v6 will soon go into public beta with a bug that makes it crash in linux workstations behind ISA servers

BUGabundo: If you grab a post r57073 build, can you run with --auth-schemes=ntlm? I want to make sure this isolated to NTLM rather than a problem with Negotiate+NTLM.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=57211 

------------------------------------------------------------------------
r57211 | cbentzel@chromium.org | 2010-08-24 11:51:40 -0700 (Tue, 24 Aug 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.cc?r1=57211&r2=57210

Fail rather than crash if username+password are unspecified for NTLM on Linux+OSX.

This will be yanked out, but is being used to triage a bug.

BUG=50517
TEST=None

Review URL: http://codereview.chromium.org/3150033
------------------------------------------------------------------------

Also, if you grab a post r50517 build can you see if the crash is avoided (even if authentication fails)? Thanks.

so so sorry for not replying sooner!
changed my laptop to SSD and have yet to migrate my mail client.

As of this moment, i can say this is fixed.
I'm using 7.0.507.0 (57625) Built on Ubuntu 10.04, running on Debian unstable


Thanks

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=57914 

------------------------------------------------------------------------
r57914 | wtc@chromium.org | 2010-08-30 15:14:09 -0700 (Mon, 30 Aug 2010) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_auth_handler_ntlm.cc?r1=57914&r2=57913

Merge 57211 - Fail rather than crash if username+password are unspecified for NTLM on Linux+OSX.

This will be yanked out, but is being used to triage a bug.

BUG=50517
TEST=None

Review URL: http://codereview.chromium.org/3150033

TBR=cbentzel@chromium.org
Review URL: http://codereview.chromium.org/3239009
------------------------------------------------------------------------

49950 may be a related bug. 

I'm going to move this to M7. The M6 crash is fixed, but I don't understand the underlying problem still.

I believe the multi-round auth fixed this. I'm too skittish to remove the null pointer early return from mstone 7 though. Moving to mstone8 to remove the null pointer catch. 

Actually, marking as fixed now that the crash is no longer happening.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)