Trunk & M096 crash [@ COOKIE_GetCookie]

VERIFIED FIXED in mozilla0.9.7

Status

()

Core
Networking: Cookies
--
critical
VERIFIED FIXED
17 years ago
4 years ago

People

(Reporter: jay, Assigned: Stephen P. Morse)

Tracking

({crash, topcrash})

Trunk
mozilla0.9.7
x86
All
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
This has been a topcrasher on recent MozillaTrunk builds on Linux and Windows. 
Here is the latest info from Talkback:

COOKIE_GetCookie   17 
BBID range: 37842192 - 38084054
Min/Max Seconds since last crash: 80 - 97197
Min/Max Runtime: 4004 - 141778
Crash data range: 2001-11-10 to 2001-11-15
Build ID range: 2001110612 to 2001111516
Keyword List : 
Stack Trace: 

	 COOKIE_GetCookie()
	 COOKIE_GetCookieFromHttp()
	 nsCookieService::GetCookieStringFromHttp()
	 nsCookieHTTPNotify::OnModifyRequest()
	 XPTC_InvokeByIndex()
	 nsProxyObject::Post()
	 nsProxyEventObject::CallMethod()
	 PrepareAndDispatch()
	 nsXPTCStubBase::Stub3()
	 nsHttpHandler::OnModifyRequest()
	 nsHttpChannel::Init()
	 nsHttpHandler::NewProxiedChannel()
	 nsIOService::NewChannelFromURI()
	 nsDocShell::DoURILoad()
	 nsDocShell::InternalLoad()
	 nsDocShell::LoadURI()
	 nsDocShell::LoadURI()
	 XPTC_InvokeByIndex()
	 XPCWrappedNative::CallMethod()
	 XPC_WN_CallMethod()
	 js_Invoke()
	 js_Interpret()
	 js_Invoke()
	 js_InternalInvoke()
	 JS_CallFunctionValue()
	 nsJSContext::CallEventHandler()
	 nsJSEventListener::HandleEvent()
	 nsEventListenerManager::HandleEventSubType()
	 nsEventListenerManager::HandleEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 PresShell::HandleEventInternal()
	 PresShell::HandleEventWithTarget()
	 nsEventStateManager::CheckForAndDispatchClick()
	 nsEventStateManager::PostHandleEvent()
	 PresShell::HandleEventInternal()
	 PresShell::HandleEvent()
	 nsView::HandleEvent()
	 nsViewManager::DispatchEvent()
	 HandleEvent()
	 nsWidget::DispatchEvent()
	 nsWidget::DispatchWindowEvent()
	 nsWidget::DispatchMouseEvent()
	 nsWidget::OnButtonReleaseSignal()
	 nsWindow::HandleGDKEvent()
	 dispatch_superwin_event()
	 handle_gdk_event()
	 libgdk-1.2.so.0 + 0x1722b (0x4032622b)
	 libglib-1.2.so.0 + 0xff96 (0x40354f96)
	 libglib-1.2.so.0 + 0x10561 (0x40355561)
	 libglib-1.2.so.0 + 0x10701 (0x40355701)
	 libgtk-1.2.so.0 + 0x8ccf9 (0x4027bcf9)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 main1()
	 main()
	 libc.so.6 + 0x189ae (0x404589ae)     (38080606)	URL: www.darkhorse.com
(38080606)
Comments: Once I enter the website URL and waited  it just killed Mozilla.
     (37934099)	URL: www.fuckedcompany.com
(37934099)
Comments: Viewing the products that are for sale.   There were alot of pictures
of themouse pads.    I do not why it crashed.

Here's another stack trace from a Windows crash (darkhorse.com)with filenames
and line numbers:
Incident: 38080606

COOKIE_GetCookie [d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp,
line 639]
COOKIE_GetCookieFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp, line 858]
nsCookieService::GetCookieStringFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieService.cpp, line 179]
nsCookieHTTPNotify::OnModifyRequest
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieHTTPNotify.cpp, line 194]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 154]
nsProxyObject::Post
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEvent.cpp, line 430]
nsProxyEventObject::CallMethod
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 548]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsHttpHandler::OnModifyRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 583]
nsHttpChannel::Init
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 202]
nsHttpHandler::NewProxiedChannel
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 1669]
nsIOService::NewChannelFromURI
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 774]
imgLoader::LoadImage
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 203]
nsImageLoader::Load
[d:\builds\seamonkey\mozilla\layout\base\src\nsImageLoader.cpp, line 123]
nsPresContext::LoadImage
[d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 1499]
nsCSSRendering::PaintBackground
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSRendering.cpp, line 2269]
nsHTMLContainerFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLContainerFrame.cpp, line
101]
CanvasFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 395]
PresShell::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5543]
nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 275]
nsViewManager::RenderDisplayListElement
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1182]
nsViewManager::RenderViews
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1106]
nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp,
line 653]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1728]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 84]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 748]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 770]
nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp,
line 4124]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3081]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1013]
USER32.DLL + 0x2e98 (0x77e12e98)
USER32.DLL + 0x39a3 (0x77e139a3)
USER32.DLL + 0x395f (0x77e1395f)
ntdll.dll + 0x2032f (0x77fa032f)
nsXULDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 2319]
nsContentTreeOwner::SetStatus
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsContentTreeOwner.cpp, line 359]
nsPluginInstanceOwner::ShowStatus
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 2352]
nsPluginHostImpl::PostStartupMessageForType
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
4183]
nsPluginHostImpl::SetUpPluginInstance
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
3636]
nsPluginHostImpl::InstantiateEmbededPlugin
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
3241]
nsObjectFrame::InstantiatePlugin
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1302]
nsObjectFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1126]
nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1038]
nsInlineFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 713]
nsInlineFrame::ReflowFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 522]
nsInlineFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 438]
nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1038]
nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3675]
nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3556]
nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3481]
nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3426]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2461]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2150]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 737]
nsTableCellFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 840]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 737]
nsTableRowFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1238]
nsTableRowFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1133]
nsTableRowFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1408]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 737]
nsTableRowGroupFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1526]
nsTableRowGroupFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1204]
(Reporter)

Updated

17 years ago
Keywords: crash, topcrash
(Assignee)

Comment 1

17 years ago
This may be critical, but I can't reproduce it which means I can't fix it.  I 
looked at the offending code as indicated by the stacktrace and didn't see 
anything that could be causing it.

The line being pointed at is:

      /* calculate the host length by looking at all characters up to a
       * colon or '\0'.  That way we won't include port numbers in domains
       */
      for(cp=host; *cp != '\0' && *cp != ':'; cp++) {
        ; /* null body */
      }
-->   host_length = cp - host;
      if(!cookie_IsInDomain(cookie_s->host, host, host_length)) {
        continue;
      }

Marking as 0.9.9 for now.  If a reproducible test case comes along, I'll get 
right on this.  If none does by 0.9.9 I'll have to future this.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
*** Bug 110744 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

17 years ago
*** Bug 111548 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
Using build id: 2001112203 on Windows 98
Could reproduce the bug, but when i cleaned my cookies couldn't reproduce the
bug anymore, after cleaning it have stored a cookie for trying to reproduce once
more, without luck.
I can only reproduce it with the docPropFSet.htm inside the zip in the
attachment on bug 111548
Okay, so which cookie from my cookies.txt file was laced with digital cyanide?  :)

http://bugzilla.mozilla.org/attachment.cgi?id=59008&action=view

Comment 6

17 years ago
Found a way to reproduce it, with only a cookie that google stores when visiting
the site (cookie named PREF, you can check if you got it at the cookie manager
Edit>>Prefs>>Privacy&Security>>>Cookies).
(Assignee)

Comment 7

17 years ago
Are you saying that you can reproduce it as follows?

- start with a fresh profile
- go to www.google.com
- crash.

That certainly works fine for me.

Comment 8

17 years ago
yeah wfm that way, thats the reproduce procedure, works for me Build id:2001112203.
Sorry for the crappy reproduce description.
(Assignee)

Comment 9

17 years ago
Does anyone have a profile with which this problem can be consistently 
reproduced?  If so, then zip up that profile and attach it to this bug report.  
Or, if you are afraid that your profile might contain some personal information, 
the e-mail it to me privately so that I can reproduce the problem and then I'll 
be able to fix it.

Comment 10

17 years ago
I've found at least part of the problem.
At http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookies.cpp#634
|host| is returned as null, and there is no check for null, so when it tries to
access it at line 651, mozilla crashes.

Comment 11

17 years ago
However I don't crash on the listed urls, so I don't know if they are a
different issue.
(Assignee)

Comment 12

17 years ago
Samuel, that's excellent progress.  Can you tell me what is in "address" when 
extractUrlPart is called on line 634?

Comment 13

17 years ago
address="file:///tmp/test/cookie.html"
This is the solution for bug 111548, but it looks like this bug is a different
issue.
*** Bug 111761 has been marked as a duplicate of this bug. ***
*** Bug 111948 has been marked as a duplicate of this bug. ***
I can easy reproducve this crash with the attachment in bug 111948
(save the attachment localy and open it in mozilla on win2k)
(Assignee)

Comment 17

17 years ago
Matti, can you reproduce it starting with a fresh profile?  I just tried doing 
what you said and could not reproduce it.
win2k SP2 german, Athlon 1.3Ghz, 512MB RAM, ISDN (64Kbit) connection over NAT.
I saved the file to my desktop as test.html

I tested it with a new profile and i crashed at the end of the loading.
(the attachment loads additional files from the web)
It crashed also everytime if I hit the stop button during page load.
*** Bug 112019 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

17 years ago
Something very strange is going on here and yet I'm not able to reproduce it.  
There have been too many different sightings of this problem for me to dismiss 
it as user error.  Specifically it has been observed by

  bug 110744: titanic73@hotmail.com (Christopher Curzio)
  bug 111548: jscript@pacbell.net (Alex Vincent)
  bug 110560: alvarom@altavista.net (Alvaro Munoz-Aycuens)
  bug 110560: samuel@sieb.net (Samuel Sieb)
  bug 111761: cbiesinger@web.de (Christian Biesinger)
  bug 111958: pat@lvs.informatik.rwth-aachen.de (Patrick)
  bug 111958: matti@epost.de (Matthias Versen)
  bug 112019: svante@nemesis.se (Svante Kleist)

I sure wish that I could reproduce this so that I could analyze it and put in 
the correct fix.  But in the interim I'll try to put in some bullet-proofing 
based on the details that Samuel Sieb provided.
stupid question: 
result = ioService->ExtractUrlPart(address, nsIIOService::url_Path, 
                                     &start, &end, &path);
is it correct that path="/c:/blah/foo.html" contains a "/" as first character ?

BTW: If you understand german you can use my german VC6++ via VNC :-)
(Assignee)

Comment 22

17 years ago
Created attachment 59237 [details] [diff] [review]
bullet-proofing to prevent crash
(Assignee)

Comment 23

17 years ago
cc'ing alecf and sgehani for reviews
Target Milestone: mozilla0.9.9 → mozilla0.9.7
This bug is blocking our efforts to confirm bug 112011.  I crashed on it just as
Svante Kleist did.

Per the literal definition of severity at bug_status.html, I recommend bumping the
severity up to blocker.
Blocks: 112011

Comment 25

17 years ago
What should the host be for a local file?  This question is related to bug
112011 as well.
No longer blocks: 112011
Target Milestone: mozilla0.9.7 → mozilla0.9.9

Comment 26

17 years ago
sorry, it seems my build has submitting problems...
Blocks: 112011
Target Milestone: mozilla0.9.9 → mozilla0.9.7
(Assignee)

Comment 27

17 years ago
I don't know what the host should be for a local file.  That's up to the 
networking team who wrote the extractURL routine.  But whatever it is, it 
shouldn't be null.  And on my build it is definitely not null.

Comment 28

17 years ago
Comment on attachment 59237 [details] [diff] [review]
bullet-proofing to prevent crash

Does patch this work for file:/// URLs?
(Assignee)

Comment 29

17 years ago
Patch should work for all urls, file or otherwise.  In no case should a null 
host be returned so the patch should never kick in.  But apparently under some 
conditions (which I can't reproduce), the host is coming back as null.

Comment 30

17 years ago
Comment on attachment 59237 [details] [diff] [review]
bullet-proofing to prevent crash

sr=alecf

You can also use NS_ENSURE_SUCCESS(result);
Attachment #59237 - Flags: superreview+

Comment 31

17 years ago
Comment on attachment 59237 [details] [diff] [review]
bullet-proofing to prevent crash

r=sgehani
Attachment #59237 - Flags: review+

Comment 32

17 years ago
I crash on Matthias Versen's example, but before I crash I trigger all sorts of
asserts in the History database routines.  The offending lines appear to be
around line 710 of nsGlobalHistory.cpp

  ioService->ExtractUrlPart(aURL, nsIIOService::url_Host, 0, 0,
getter_Copies(hostname));

  SetRowValue(row, kToken_HostnameColumn, hostname);

Hostname is returned as a null pointer dressed as an nsXPIDLCString (this seems
similar to the cookie problem.)

The cause of this appears to be in nsIOService::ExtractUrlPart (nsIOService.cpp:538)

First we
    if (urlPart)
        *urlPart = nsnull;
Make URL part a null pointer.

then ignore it until

    else if (flag < url_Directory || flag & url_Port) {
        PRUint32 usernamePos, passwordPos, hostnamePos;
        PRInt32 usernameLen, passwordLen, hostnameLen;
        PRInt32 port;

        if (authLen < 0)
            return NS_OK;

we return NS_OK having done nothing but clearing *urlPart.

this then goes on to wreak havoc in the depths of the mork database code.

I am however unsure of what the right thing to do is.

Comment 33

17 years ago
I have verified that the cookie bug appears to be the same problem. It appears
to be related to bug 111072.  I suspect that the patch for 111072 just moved the
bug from the path to the host.
If this makes any sense to anyone but me, it might be a good ide to cc Darin.

Comment 34

17 years ago
Created attachment 59282 [details] [diff] [review]
fix for nsURLParsers.cpp

Comment 35

17 years ago
morse, alecf: can you please review the patch i just attached. it corrects the
behavior of nsNoAuthURLParser::ParseAfterScheme to assume a empty hostname
instead of a NULL hostname if the hostname is zero length. this will correct the
problem with nsIOService::ExtractUrlPart and fix this bug.

morse's patch is good because ExtractUrlPart can return a NULL value if the
input string contained no delimiters that would identify the result.
(Assignee)

Comment 36

17 years ago
Let me clarify darin's comment a bit.

First, I'm now able to reproduce the crash.  I won't bore you by 
explaining why I couldn't before.

Second, my patch was not correct because it didn't go far enough.  There were 
other places that I needed to apply the patch.  Also the patch needs to test not 
only for a bad return value but for a null string as well (now that I can 
reproduce it, I see that in this crasher case we were actually getting a good 
return value).

So I'm about to post a corrected patch.  That patch is bullet-proofing and by 
itself will stop the crash.  But it will also result in file: urls from being 
unable to set/read cookies.  That's where darin's patch comes in -- it returns 
empty strings (rather than null pointers) in the case of file: url's.
(Assignee)

Comment 37

17 years ago
Created attachment 59283 [details] [diff] [review]
enhanced bullet-proofing
Attachment #59237 - Attachment is obsolete: true
(Assignee)

Comment 38

17 years ago
alecf, darin, please review my enhanced bullet-proofing patch.
(Assignee)

Comment 39

17 years ago
Comment on attachment 59282 [details] [diff] [review]
fix for nsURLParsers.cpp

r=morse
Attachment #59282 - Flags: review+

Comment 40

17 years ago
Comment on attachment 59282 [details] [diff] [review]
fix for nsURLParsers.cpp

doh!
sr=alecf
Attachment #59282 - Flags: superreview+

Comment 41

17 years ago
Comment on attachment 59283 [details] [diff] [review]
enhanced bullet-proofing

sr=alecf
Attachment #59283 - Flags: superreview+
(Assignee)

Comment 42

17 years ago
Patch for nsURLParsers.cpp checked in.

Enhanced bullet-proofing patch will be checked in as soon as review is obtained.
I can confirm that your patch (nsURLParsers.cpp) fixed the crash.
(only "host" is empty in cookiemanager and the path is "/C:/Dokumente...")

Comment 44

17 years ago
Comment on attachment 59283 [details] [diff] [review]
enhanced bullet-proofing

r=sgehani
Attachment #59283 - Flags: review+
(Assignee)

Comment 45

17 years ago
Enhanced bulletproofing is now checked in as well.  Marking bug as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 46

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

Comment 47

16 years ago
verified fixed.  this crash last happened with MozillaTrunk builds 20011126xx.
Status: RESOLVED → VERIFIED

Comment 48

16 years ago
*** Bug 114165 has been marked as a duplicate of this bug. ***
*** Bug 111897 has been marked as a duplicate of this bug. ***
I am still experiencing the crashes and will list the incident IDs.


TB235278Z
TB235182K
TB233652X
TB230547H
TB200081Y
TB199920E
TB199905G
TB199887G
TB199875W
TB198089Q
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 51

16 years ago
I'm confused.  jpatel said that this crash hasn't happened since 20011126xx.  
And now buffington is contradicting that and has reopened this report.

Please post some evidence to indicate that this particular crash is still 
occuring.  Do you have stack traces for these "incident IDs" that show that the 
crash is the same one that is describe3d in this bug report?

Re-closing until some confirmation is made that this is still occuring.
Stephen P. Morse: 
FYI This is 100% fixed for me on win2k and i could reproduce the crasher
everytime before you fixed this.

Thomas Buffington Jr. :
Why are you sure that you see the same crash ?
If you are not sure you should file a new bug.
Where do you see this crash ?
(Reporter)

Comment 53

16 years ago
Marking this fixed again...I took a look at Thomas Buffington Jr.'s incidents,
and they are all occurring with MozillaBranch build 2001112012 (which is the
Mozilla 0.9.6 release).  They are indeed the same crash, but with an older build.

Thomas:  Please try downloading a nightly Mozilla build and see if you can
reproduce this crash with a more recent build.  You are crashing with a Mozilla
Milestone (Mozilla 0.9.6)...which was released before this fix was checked into
the MozillaTrunk.

Just for the record, here is Thomas's most recent incident:

Incident 235278:
Stack Signature  COOKIE_GetCookie 12baf355
Trigger Time 2001-12-09 01:20:17
Email Address ToMaSRoOsA@Netscape.net
URL visited http://www.darkhorse.com/
User Comments
Build ID 2001112012         <-------- This is the release build for M096 
Product ID MozillaBranch    <-------- This means it happened on the M096 Branch
Platform
Operating System Win32
Module
Trigger Reason Access violation
Stack Trace
COOKIE_GetCookie [d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp,
line 636]
COOKIE_GetCookieFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp, line 855]
nsCookieService::GetCookieStringFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieService.cpp, line 179]
nsCookieHTTPNotify::OnModifyRequest
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieHTTPNotify.cpp, line 194]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 154]
nsProxyObject::Post
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEvent.cpp, line 430]
nsProxyEventObject::CallMethod
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 548]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsHttpHandler::OnModifyRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 583]
nsHttpChannel::Init
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 203]
nsHttpHandler::NewProxiedChannel
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 1669]
nsIOService::NewChannelFromURI
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 774]
imgLoader::LoadImage
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 203]
nsImageLoader::Load
[d:\builds\seamonkey\mozilla\layout\base\src\nsImageLoader.cpp, line 123]
nsPresContext::LoadImage
[d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 1417]
nsCSSRendering::PaintBackground
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSRendering.cpp, line 2269]
nsHTMLContainerFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLContainerFrame.cpp, line
101]
CanvasFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 395]
PresShell::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5543]
nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 275]
nsViewManager::RenderDisplayListElement
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1182]
nsViewManager::RenderViews
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1106]
nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp,
line 653]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1728]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 84]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 748]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 770]
nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp,
line 4124]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3081]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1013]
KERNEL32.DLL + 0x3613 (0xbff63613)
KERNEL32.DLL + 0x248f7 (0xbff848f7) 
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED
Summary: Trunk crash [@ COOKIE_GetCookie] → Trunk & M096 crash [@ COOKIE_GetCookie]
(Assignee)

Comment 54

16 years ago
Well I thought I closed it out when I made comment #51 but I guess I didn't.  
jpatel, thanks for closing it for me.
(Assignee)

Comment 55

16 years ago
Marking as verified based on comment #52 and comment #53, and also because 
that's the status it was in before being reopened.
Status: RESOLVED → VERIFIED
Crash Signature: [@ COOKIE_GetCookie]
You need to log in before you can comment on or make changes to this bug.