Closed Bug 215270 Opened 21 years ago Closed 21 years ago

Crash (in cookies?) [nsHttpChannel::GetCallback]

Categories

(Core :: Networking: HTTP, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.5beta

People

(Reporter: chris, Assigned: darin.moz)

References

()

Details

(Keywords: crash, topcrash)

Attachments

(6 files)

Camino 2003080502 trunk


Ok... this report is kind of weak... shoot me

- Filing in Camino as thats where I had the crash, but I suspect its a Mozilla bug
- I don't have cookie notifications on so I don't know what site crashed me, but
I'll go through my history in a bit and see if i can repro anywhere

Relevant stack (attaching a full stack in a minute):


Date/Time:  2003-08-06 12:08:02 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       pnhTiObject.local.

Command:    Camino
PID:        6274

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
 #0   0x00468084 in nsHttpChannel::GetCallback(nsID const&, void**)
 #1   0x0046ef40 in nsHttpChannel::SetCookie(char const*)
 #2   0x00467924 in nsHttpChannel::ProcessResponse()
 #3   0x0017c314 in nsInputStreamPump::OnStateStart()
 #4   0x0017c228 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*)
 #5   0x050933c8 in nsInputStreamReadyEvent::EventHandler(PLEvent*)
 #6   0x05045ecc in PL_HandleEvent
 #7   0x05045df0 in PL_ProcessPendingEvents
 #8   0x05046d88 in nsEventQueueImpl::ProcessPendingEvents()
 #9   0x00404b48 in -[EventQueueHandler eventTimer:]
 #10  0x97df4dd8 in __NSFireTimer
 #11  0x90163230 in __CFRunLoopDoTimer
 #12  0x90148d28 in __CFRunLoopRun
 #13  0x90180f58 in CFRunLoopRunSpecific
 #14  0x969a3b70 in RunCurrentEventLoopInMode
 #15  0x969b3b00 in ReceiveNextEventCommon
 #16  0x969dabbc in BlockUntilNextEventMatchingListInMode
 #17  0x9308dedc in _DPSNextEvent
 #18  0x930a0158 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
 #19  0x930b1d88 in -[NSApplication run]
 #20  0x9315fc58 in NSApplicationMain
 #21  0x00004820 in _start
 #22  0x000046a0 in start

CC'g darin as it looks like he's had the last few checkins to nsHttpChannel.cpp
Attached file crash log
full text of the crash log
Blocks: 201894
i don't see this happening on the trunk mozilla build with my recent HTTP
changes.  i don't have a mac to test this out on.

saari@netscape.com is also a dead email address.... this needs to have a better
owner.
I've been experiencing the same thing in Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.5b) Gecko/20030805 Camino/0.7+ . So far it's only occured on
sites for which I've specifically denied all cookies. The crash log is almost
exactly the same (though for some reason I'm getting odd characters in place of
the parens and such).
Here's the latest crashlog, from visiting http://www.threadless.com/ .
ok.. confirming... crashed on my first vist in camino to the threadless address
(and one other time that I can't pin down to a site.. actually think it may have
been an ad pushing a cookie as Camino wasn't even in focus at the time of the crash)

did not crash on subsequent visits in 08-05-02... i'm clearing my cookies and
gonna run with 08-04-02 and seamonkey 08-05-03 for a bit
Status: UNCONFIRMED → NEW
Ever confirmed: true
hmm... that site uses flash... i wonder if that could be related to this problem.

in fact, the only way i can think of that that function would crash is if the
GetInterface method returned NS_OK with a NULL valued out param.  hmm... could
it be that some part of the flash plugin is implementing GetInterface??  hmm...

it might help to see what URL is being loaded... we can learn that from a HTTP
log.  instructions for capturing a HTTP log are available here:

  http://www.mozilla.org/projects/netlib/http/http-debugging.html
I don't believe so, as I had it happen a few times yesterday when I was trying
to view an image at members.msn.com . I did check, and the server was indeed
trying to send me a cookie.
i tried visiting the site using the 2003-08-06 linux trunk w/ flash installed,
and i could not repro the crash.  if you can repro under OSX, then please
capture a HTTP log.  thanks!
OK. I have a log.

This is from Sprint PCS's billpayment. It was trying to pop open a window at the same time. Also, in 
the terminal window, I got the message:

[nightstalker:Camino.app/Contents/MacOS] avidriss% ./Camino 
2003-08-07 19:24:13.338 Camino[1057] JS error: Security Error: Content at https://
manage1.sprintpcs.com/Manage?layer=0&target=Controls&action=pay_invoice may not load data 
from https://nj25.speedpay.com/myaccount_payments.asp.
Bus error
[nightstalker:Camino.app/Contents/MacOS] avidriss% 

... if that matters. Let me trim the file a bit, take out the secure info, and I'll attach it.
Attached file HTTP log
I visited sprintpcs.com, logged in, selected to pay my bill, and then clicked
on an "online check" link. A window popped up, the status bar said it was
loading from nj25.speedpay.com, and then it blew up.

It's probably only the last 40k that matters, but here you go. Good luck.
*** Bug 215443 has been marked as a duplicate of this bug. ***
avi: it would actually be helpful to me if i could see the full HTTP log...

  NSPR_LOG_MODULES=nsHttp:5

if you want you can just email it to me directly.  thanks!
At http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsLoadGroup.cpp#770
nsLoadGroup::GetNotificationCallbacks always returns NS_OK, even when the result
value is null. At
http://lxr.mozilla.org/mozilla/source/netwerk/protocol/http/src/nsHttpChannel.cpp#793
that (maybe null) value is used, without checking.
Could that be the problem?
*** Bug 215522 has been marked as a duplicate of this bug. ***
from bug 215522:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../../dist/include/xpcom/nsCOMPtr.h, line 668
Break: at file ../../../dist/include/xpcom/nsCOMPtr.h, line 668
(gdb) bt
#0  0x08d23c08 in nsHttpChannel::GetCallback(nsID const&, void**)
(this=0xa804320, aIID=@0x8ddbeb0, aResult=0xbfffe3a0) at
../../../../../src/netwerk/protocol/http/src/nsHttpChannel.cpp:799/Volumes/Ben/mozilla/chimera/netwerk/protocol/http/src/
#1  0x08d2d9b0 in nsHttpChannel::SetCookie(char const*) (this=0xa804320,
aCookieHeader=0xa73f010 "ananova_user=62.190.123.102.103381060365899165; path=/;
expires=Mon, 08-Sep-03 18:04:59 GMT; domain=.ananova.com\nHistory=jd-12272.-_a;
expires=Tue, 07-Oct-03 18:04:59 GMT; path=/") at
../../../../../src/netwerk/protocol/http/src/nsHttpChannel.cpp:3204/Volumes/Ben/mozilla/chimera/netwerk/protocol/http/src/
#2  0x08d233c0 in nsHttpChannel::ProcessResponse() (this=0xa804320) at
../../../../../src/netwerk/protocol/http/src/nsHttpChannel.cpp:664/Volumes/Ben/mozilla/chimera/netwerk/protocol/http/src/

So this is a nullpointer. However, the line number looks odd.
Attached patch v1 patchSplinter Review
patch to shore up notification callback handling...

mvl: yeah, you are right.  if the load group does not have a notification
callback then it would return NS_OK and a NULL out param.  and, moreover that
is completely OK for the load group to do.  so, we do need a fix in
nsHttpChannel.	a simple NULL check would suffice, but i decided to simplify
GetCallback some what in the process.
Attachment #129482 - Flags: review?(mvl)
-> reassigning to me, and making this a general necko bug...
Assignee: saari → darin
Component: General → Networking: HTTP
Product: Camino → Browser
Target Milestone: --- → mozilla1.5beta
Version: unspecified → Trunk
Status: NEW → ASSIGNED
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
Attachment #129482 - Flags: approval1.5b?
Flags: blocking1.5b?
Attachment #129482 - Flags: approval1.5b?
Attachment #129482 - Flags: review?(mvl) → review+
Attachment #129482 - Flags: superreview?(bryner)
*** Bug 215727 has been marked as a duplicate of this bug. ***
Following from comment 15, which line number looks odd? I have probably edited
the file concerned.

My line 799 is
"                rv = cbs->GetInterface(aIID, aResult);",
the official line 793 .

How are popke getting logs? Does the ENVIRONMENT file system sill work?
<URL: http://books.mozdev.org/html/mozilla-app-a-sect-2.html > and
<URL: http://www.geocrawler.com/archives/3/130/1999/11/0/2928560/ >
I have made this modification, which allows me to browse the sites
in question.

@@ -782,22 +788,28 @@
     NS_ASSERTION(aResult, "Invalid argument in GetCallback!");
     nsresult rv;
     if (mCallbacks)
         rv = mCallbacks->GetInterface(aIID, aResult);
     else
         rv = NS_ERROR_NO_INTERFACE;
     if (NS_FAILED(rv)) {
         if (mLoadGroup) {
             nsCOMPtr<nsIInterfaceRequestor> cbs;
             rv = mLoadGroup->GetNotificationCallbacks(getter_AddRefs(cbs));
-            if (NS_SUCCEEDED(rv))
-                rv = cbs->GetInterface(aIID, aResult);
+            if (NS_SUCCEEDED(rv)) {
+                if( *aResult ) {
+                  rv = cbs->GetInterface(aIID, aResult);
+                } else {
+                  NS_WARNING( "nsHttpChannel::GetCallback *aResult is NULL " );
+                  return NS_ERROR_NO_INTERFACE;
+                }
+            }
         }
     }
 
     // defend against bad nsIInterfaceRequestor implementations.
     if (NS_SUCCEEDED(rv) && !*aResult)
         return NS_ERROR_NO_INTERFACE;
 
     return rv;
 }

Rightly or wrongly, I don't check *aResult until after the assignment to
it ... Perhaps the value should be checked at that point ...

This tends to indicate that the root of this bug is where we think that
it is.
I've been experiencing this bug on my Mac OS X systems.  I'll apply darin's v1
patch and report back.
*** Bug 215859 has been marked as a duplicate of this bug. ***
*** Bug 215805 has been marked as a duplicate of this bug. ***
Comment on attachment 129482 [details] [diff] [review]
v1 patch

ok, scott... can you please sr= this patch once you've confirmed that it works?
 thx!
Attachment #129482 - Flags: superreview?(bryner) → superreview?(scc)
*** Bug 215865 has been marked as a duplicate of this bug. ***
This url will reliably crash the browser as a result of this bug...

http://www.evite.com/pages/invite/viewInvite.jsp?inviteId=FEVGORHSSKBUDNSGXJXK
Attachment #129482 - Flags: superreview?(scc) → superreview?(bryner)
Comment on attachment 129482 [details] [diff] [review]
v1 patch

sr=bryner
Attachment #129482 - Flags: superreview?(bryner) → superreview+
Comment on attachment 129482 [details] [diff] [review]
v1 patch

requesting approval to crash fix for 1.5 beta.	fix is low risk.  while this
bug report only sites a crash in camino, i believe this crash is possible in
seamonkey as well.
Attachment #129482 - Flags: approval1.5b?
Attached file crash log entry
The crash log snip I submitted is from visiting http://www.allposters.com . I
saw it mentioned in the mailing list this morning. I should have added this note
to that post. Build ID: 2003081302 
*** Bug 213455 has been marked as a duplicate of this bug. ***
this is a topcrasher for camino, at least
Keywords: topcrash
My bank also crashes Camino

https://myaccounts.navyfcu.org/cgi-bin/ifsewwwc

Console log attached.

This is above my head.

Thanks to all those that keep Camino running and letting me use it as my main
browser.

Camino 0.7 2003081102
iMac G4 (FP) ::800MHz :: 768MB :: 60GB :: SuperDrive :: Mac OS X 10.2.6 (6L60)
I have encountered this bug as well.

It was fine in Camino 2003080402 but crashed since 2003080502.

Here is a url that surely crash it:
http://www.macuser.co.uk/MacReviewZone/reviews/reviews_story.php?id=30918
In the interest of preventing any further onslaught of "me too" bugspam I think
we have enough examples of sites that are triggering this crash now ;)

The next step now is to wait for the fix to get checked in and a build to get
out with the fix to verify all links here work ok.
Comment on attachment 129482 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to Mozilla 1.5beta.
Attachment #129482 - Flags: approval1.5b? → approval1.5b+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Flags: blocking1.5b?
Resolution: --- → FIXED
*** Bug 216299 has been marked as a duplicate of this bug. ***
V. Fixed

Camino 2003081810 trunk
Status: RESOLVED → VERIFIED
QA Contact: winnie → moz
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: