Closed Bug 52257 Opened 24 years ago Closed 24 years ago

Crash logging in via basic auth

Categories

(Core :: Networking, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hume, Assigned: gagan)

References

()

Details

(Keywords: crash, Whiteboard: [nsbeta3+])

Trying to log into a Basic-auth-protected section of a website, mozilla build ID 2000091121 on Solaris crashes reproducibly immediately after filling in user/pass and hitting 'OK' in the password dialog. #0 0xee253ffc in nsHTTPChannel::Authenticate () from /usr/local/mozilla/package/components/libnecko.so #1 0xee254c60 in nsHTTPChannel::ProcessAuthentication () from /usr/local/mozilla/package/components/libnecko.so #2 0xee2546f0 in nsHTTPChannel::ProcessStatusCode () from /usr/local/mozilla/package/components/libnecko.so #3 0xee254100 in nsHTTPChannel::FinishedResponseHeaders () from /usr/local/mozilla/package/components/libnecko.so #4 0xee25a418 in nsHTTPServerListener::FinishedResponseHeaders () from /usr/local/mozilla/package/components/libnecko.so #5 0xee258efc in nsHTTPServerListener::OnDataAvailable () from /usr/local/mozilla/package/components/libnecko.so #6 0xee20f314 in nsOnDataAvailableEvent::HandleEvent () from /usr/local/mozilla/package/components/libnecko.so #7 0xee20ea24 in nsStreamListenerEvent::HandlePLEvent () from /usr/local/mozilla/package/components/libnecko.so #8 0xef65289c in PL_HandleEvent () from /usr/local/mozilla/package/./libxpcom.so #9 0xef6527d0 in PL_ProcessPendingEvents () from /usr/local/mozilla/package/./libxpcom.so #10 0xef653608 in nsEventQueueImpl::ProcessPendingEvents () from /usr/local/mozilla/package/./libxpcom.so #11 0xedea4364 in nsAppShell::SetDispatchListener () from /usr/local/mozilla/package/components/libwidget_gtk.so #12 0xedea4074 in keysym2ucs () from /usr/local/mozilla/package/components/libwidget_gtk.so #13 0xeda20570 in g_io_unix_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #14 0xeda245dc in g_main_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #15 0xeda253d0 in g_main_iterate () from /opt/sfw/lib/libglib-1.2.so.0 #16 0xeda2576c in g_main_run () from /opt/sfw/lib/libglib-1.2.so.0 #17 0xedca4eb4 in gtk_main () from /opt/sfw/lib/libgtk-1.2.so.0 #18 0xedea494c in nsAppShell::Run () from /usr/local/mozilla/package/components/libwidget_gtk.so #19 0xee55c9a0 in nsAppShellService::Run () from /usr/local/mozilla/package/components/libnsappshell.so #20 0x16370 in CheckForNewChrome () #21 0x16874 in main ()
*** Bug 52338 has been marked as a duplicate of this bug. ***
*** Bug 52425 has been marked as a duplicate of this bug. ***
*** Bug 52437 has been marked as a duplicate of this bug. ***
the dups are reported on linux. Confirming bug based on the amount of dups.
Status: UNCONFIRMED → NEW
Ever confirmed: true
keyw.
Keywords: crash
Keywords: nsbeta3
Priority: P3 → P1
Whiteboard: [nsbeta3+]
*** Bug 52661 has been marked as a duplicate of this bug. ***
*** Bug 52657 has been marked as a duplicate of this bug. ***
*** Bug 52661 has been marked as a duplicate of this bug. ***
I've gotten a hopefully more useful stack trace (gdb @ 476M! Wargh!) My knowledge of C++ is minimal, so I have no idea if this will be useful to anybody, it was more an exercise for myself and for the great amusement of watching my Solaris box swap for five minutes flat to respond to a trace. :) #0 nsCOMPtr<nsIStreamListener>::get (this=0x14) at ../../../../dist/include/nsCOMPtr.h:631 #1 0xedbb6678 in nsCOMPtr<nsIStreamListener>::operator nsDerivedSafe<nsIStrea! #2 0xeda672b4 in nsHTTPFinalListener::GetListener (this=0x0) at nsHTTPResponseListener.h:185 #3 0xeda598e4 in nsHTTPChannel::Authenticate (this=0x72c788, iChallenge=0x7944b0 "Basic realm=\"Brandon's Movies'n'Stuff\"", iProxyAuth=0) at nsHTTPChannel.cpp:2198 #4 0xeda5b53c in nsHTTPChannel::ProcessAuthentication (this=0x72c788, aStatusCode=401) at nsHTTPChannel.cpp:2558 #5 0xeda5a6a0 in nsHTTPChannel::ProcessStatusCode (this=0x72c788) at nsHTTPChannel.cpp:2378 #6 0xeda59b50 in nsHTTPChannel::FinishedResponseHeaders (this=0x72c788) at nsHTTPChannel.cpp:2237 #7 0xeda664f8 in nsHTTPServerListener::FinishedResponseHeaders (this=0x70c0e0) at nsHTTPResponseListener.cpp:1039 #8 0xeda63dc4 in nsHTTPServerListener::OnDataAvailable (this=0x70c0e0, channel=0x687de4, context=0x72c788, i_pStream=0x595318, i_SourceOffset=0, i_Length=488) at nsHTTPResponseListener.cpp:427 #9 0xed9d04cc in nsOnDataAvailableEvent::HandleEvent (this=0x7992d0) at nsAsyncStreamListener.cpp:400 #10 0xed9cf074 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x797b70) at nsAsyncStreamListener.cpp:97 #11 0xef53c298 in PL_HandleEvent (self=0x797b70) at plevent.c:575 #12 0xef53bfc4 in PL_ProcessPendingEvents (self=0x73e20) at plevent.c:508 #13 0xef53ea70 in nsEventQueueImpl::ProcessPendingEvents (this=0x9bc98) at nsEventQueue.cpp:356 #14 0xed404a10 in event_processor_callback (data=0x9bc98, source=5, condition=GDK_INPUT_READ) at nsAppShell.cpp:158 #15 0xed404460 in our_gdk_io_invoke (source=0x21d2d0, condition=G_IO_IN, data=0x207a68) at nsAppShell.cpp:58 #16 0xecfa0570 in g_io_unix_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #17 0xecfa45dc in g_main_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #18 0xecfa53d0 in g_main_iterate () from /opt/sfw/lib/libglib-1.2.so.0 #19 0xecfa576c in g_main_run () from /opt/sfw/lib/libglib-1.2.so.0 #20 0xed1e4eb4 in gtk_main () from /opt/sfw/lib/libgtk-1.2.so.0 #21 0xed4053a0 in nsAppShell::Run (this=0x9b398) at nsAppShell.cpp:335 #22 0xee0867ac in nsAppShellService::Run (this=0xd2270) at nsAppShellService.cpp:378 #23 0x22788 in main1 (argc=1, argv=0xeffffa94, nativeApp=0x0) at nsAppRunner.cpp:958 #24 0x231ac in main (argc=1, argv=0xeffffa94) at nsAppRunner.cpp:1139 And some play: (gdb) frame 0 #0 nsCOMPtr<nsIStreamListener>::get (this=0x14) at ../../../../dist/include/nsCOMPtr.h:631 631 return NS_REINTERPRET_CAST(nsDerivedSafe<T>*, mRawPtr); (gdb) print mRawPtr Cannot access memory at address 0x14. (gdb) frame 1 #1 0xedbb6678 in nsCOMPtr<nsIStreamListener>::operator nsDerivedSafe<nsIStrea! 643 return get(); (gdb) frame 2 #2 0xeda672b4 in nsHTTPFinalListener::GetListener (this=0x0) at nsHTTPResponseListener.h:185 185 return mListener; (gdb) print mListener Cannot access memory at address 0x14. (gdb) frame 3 #3 0xeda598e4 in nsHTTPChannel::Authenticate (this=0x72c788, iChallenge=0x7944b0 "Basic realm=\"Brandon's Movies'n'Stuff\"", iProxyAuth=0) at nsHTTPChannel.cpp:2198 2198 rv = channel->AsyncRead(fl -> GetListener (), mResponseContext); (gdb) print mResponseContext (gdb) print mResponseContext $1 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>} (gdb) print fl $2 = (nsHTTPFinalListener *) 0x0 (gdb) print mResponseDataListener $4 = {mRawPtr = 0x0} (gdb) print this $5 = (nsHTTPChannel *) 0x72c788 (gdb) print *this $6 = {<nsIHTTPChannel> = {<nsIChannel> = {<nsIRequest> = {<nsISupports> = { _vptr. = 0xedc73b08}, <No data fields>}, <No data fields>}, <No data! _vptr. = 0xedc73ad8}, <No data fields>}, <nsIProgressEventSink> = {<nsIS! _vptr. = 0xedc73aa0}, <No data fields>}, <nsIProxy> = {<nsISupports> = { _vptr. = 0xedc73a48}, <No data fields>}, <nsIStreamAsFile> = {<nsISuppor! _mOwningThread = 0x52250, mResponse = 0x595370, mHandler = 0x1dcf10, mRequest = 0x72c868, mHTTPServerListener = 0x0, mResponseContext = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}, mCachedResponse = 0x0, mProgressEventSink = {mRawPtr = 0x72e738}, mRealProgressEventSink = {mRawPtr = 0x721090}, mRequestStream = { mRawPtr = 0x0}, mWriteObserver = {mRawPtr = 0x0}, mOriginalURI = { mRawPtr = 0x72d930}, mURI = {mRawPtr = 0x72d930}, mReferrer = { mRawPtr = 0x0}, mEventSink = {mRawPtr = 0x72e6e8}, mRealEventSink = { mRawPtr = 0x72109c}, mConnected = 1, mState = HS_WAITING_FOR_RESPONSE, mPrompter = {mRawPtr = 0x5d85c8}, mRealPrompter = {mRawPtr = 0x5d8278}, mCallbacks = {mRawPtr = 0x71ba34}, mResponseDataListener = {mRawPtr = 0x0}, mBufOutputStream = {mRawPtr = 0x0}, mLoadAttributes = 16642, mLoadGroup = { mRawPtr = 0x721118}, mOwner = {<nsCOMPtr_base> = { mRawPtr = 0x0}, <No data fields>}, mCacheEntry = {mRawPtr = 0x0}, mCachedContentIsAvailable = 0, mCachedContentIsValid = 0, mFiredOnHeadersAvailable = 1, mFiredOpenOnStartRequest = 0, mFiredOpenOnStopRequest = 0, mAuthTriedWithPrehost = 0, mProxy = 0x0, mProxyPort = -1, mProxyType = 0x0, mProxyTransparent = 0, mBufferSegmentSize = 0, mBufferMaxSize = 0, mStatus = 0, mCacheTransport = { mRawPtr = 0x0}, mPipeliningAllowed = 1, mPipelinedRequest = 0x0, mSecurityInfo = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}, mStreamAsFileObserverArray = {mRawPtr = 0x72d8a0}, mApplyConversion = 1, mNotificationProxiesBuilt = 1, mOpenInputStreamHasEventQueue = 1} So... it looks like mDataResponseListener is not being set?
All this is based off a CVS pull done last night at about 8 PM ADT (2000/09/14) And I meant mResponseDataListener above, of course, based on: // Fire the new request... nsIStreamListener *sl = mResponseDataListener; nsHTTPFinalListener *fl = NS_STATIC_CAST (nsHTTPFinalListener*, sl); rv = channel->AsyncRead(fl -> GetListener (), mResponseContext);
Here's another testcase (crashes on Linux 2000-09-15-06): http://webglimpse.net/allusers/ChangeLog-glimpse.txt (you don't need to type any username/passwd for the crash to occur) Some other dupes were reported on Linux also. Changing Platform from Sun to All, and OS from Solaris to All.
OS: Solaris → All
Hardware: Sun → All
I meant just press OK on the dialog box, no need to fill any username/passwd.
*** Bug 52816 has been marked as a duplicate of this bug. ***
i wonder if this is related to image and cookie managment also crashing the moment you click someting in those dialog boxes? (Both OK and Cancel produce the same crash.) Bug 52517 and bug 52736 (possible dup of the former)
hold your horses... I have a fix.
*** Bug 52628 has been marked as a duplicate of this bug. ***
*** Bug 52976 has been marked as a duplicate of this bug. ***
*** Bug 52988 has been marked as a duplicate of this bug. ***
*** Bug 52867 has been marked as a duplicate of this bug. ***
fix checked in at ~4:25 PM (nsHTTPChannel.cpp)
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified: WinNT 2000092111 Linux rh6 2000092008 Mac os8.6 2000091904
Status: RESOLVED → VERIFIED
This bug is still in 2000101212, the login box just keeps poping up and the browser never goes to the web page.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
ccing darin.
WORKSFORME in Linux [build 2000101212] bbaptist: could you please describe the problem in more detail. If you do not enter the correct user/pass and press ok, then the dialog is supposed to keep popping up. If you press cancel, then the dialog should go away and you should see an "Authorization Required" page. Are you experiencing a different behavior? Is mozilla crashing?
*** Bug 56522 has been marked as a duplicate of this bug. ***
Cannot reproduce on 10/16 brach pull local window build. Bret Bapti, are you using branch build or the trunk build when you see the crash ? Which platform are you using ?
CC bbaptist@rocketmail.com so he gets to read the questions, in case he lost track of this bug.
added keyword verifyme.
Keywords: verifyme
This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.
Keywords: nsbeta1
gerardok, can you elaborate on what still needs to be done? thx.
original bug was a crash which is gone so I am marking verified again. Also, I am not having any problems using basic auth on my test http sites. Please open a new bug if you are still having problems.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.