If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in mozilla1.5beta

Status

()

Core
Networking: HTTP
P1
critical
VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: Chris Casciano, Assigned: Darin Fisher)

Tracking

({crash, topcrash})

Trunk
mozilla1.5beta
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
Created attachment 129291 [details]
crash log

full text of the crash log
(Reporter)

Updated

14 years ago
Blocks: 201894
(Assignee)

Comment 2

14 years ago
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.

Comment 3

14 years ago
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).

Comment 4

14 years ago
Created attachment 129321 [details]
Latest crashlog with bare profile.

Here's the latest crashlog, from visiting http://www.threadless.com/ .
(Reporter)

Comment 5

14 years ago
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
(Assignee)

Comment 6

14 years ago
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

Comment 7

14 years ago
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.
(Assignee)

Comment 8

14 years ago
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!

Comment 9

14 years ago
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.

Comment 10

14 years ago
Created attachment 129394 [details]
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.
(Reporter)

Comment 11

14 years ago
*** Bug 215443 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

14 years ago
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.
(Assignee)

Comment 16

14 years ago
Created attachment 129482 [details] [diff] [review]
v1 patch

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.
(Assignee)

Updated

14 years ago
Attachment #129482 - Flags: review?(mvl)
(Assignee)

Comment 17

14 years ago
-> 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
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
(Assignee)

Updated

14 years ago
Attachment #129482 - Flags: approval1.5b?
(Assignee)

Updated

14 years ago
Flags: blocking1.5b?
(Assignee)

Updated

14 years ago
Attachment #129482 - Flags: approval1.5b?
Attachment #129482 - Flags: review?(mvl) → review+
(Assignee)

Updated

14 years ago
Attachment #129482 - Flags: superreview?(bryner)
(Reporter)

Comment 18

14 years ago
*** Bug 215727 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
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/ >

Comment 20

14 years ago
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.

Comment 21

14 years ago
I've been experiencing this bug on my Mac OS X systems.  I'll apply darin's v1
patch and report back.
(Reporter)

Comment 22

14 years ago
*** Bug 215859 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 23

14 years ago
*** Bug 215805 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

14 years ago
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)
(Reporter)

Comment 25

14 years ago
*** Bug 215865 has been marked as a duplicate of this bug. ***

Comment 26

14 years ago
This url will reliably crash the browser as a result of this bug...

http://www.evite.com/pages/invite/viewInvite.jsp?inviteId=FEVGORHSSKBUDNSGXJXK
(Assignee)

Updated

14 years ago
Attachment #129482 - Flags: superreview?(scc) → superreview?(bryner)
Comment on attachment 129482 [details] [diff] [review]
v1 patch

sr=bryner
Attachment #129482 - Flags: superreview?(bryner) → superreview+
(Assignee)

Comment 28

14 years ago
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?

Comment 29

14 years ago
Created attachment 129795 [details]
crash log entry

Comment 30

14 years ago
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

Comment 33

14 years ago
Created attachment 129798 [details]
Crash log for bank site

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)

Comment 34

14 years ago
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
(Reporter)

Comment 35

14 years ago
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 36

14 years ago
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+
(Assignee)

Comment 37

14 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Flags: blocking1.5b?
Resolution: --- → FIXED
(Reporter)

Comment 38

14 years ago
*** Bug 216299 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 39

14 years ago
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.