Bugzilla

Assignee

Comment 1

•

23 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

Comment 2

•

23 years ago

*** Bug 110744 has been marked as a duplicate of this bug. ***

Assignee

Comment 3

•

23 years ago

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

Alvaro Munoz-Aycuens

Comment 4

•

23 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

Alex Vincent [:WeirdAl]

Comment 5

•

23 years ago

Okay, so which cookie from my cookies.txt file was laced with digital cyanide?  :)

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

Alvaro Munoz-Aycuens

Comment 6

•

23 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

•

23 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.

Alvaro Munoz-Aycuens

Comment 8

•

23 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

•

23 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

•

23 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

•

23 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

•

23 years ago

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

Christian :Biesinger (don't email me, ping me on IRC)

Comment 13

•

23 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.

Comment 14

•

23 years ago

*** Bug 111761 has been marked as a duplicate of this bug. ***

Comment 15

•

23 years ago

*** Bug 111948 has been marked as a duplicate of this bug. ***

Comment 16

•

23 years ago

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

•

23 years ago

Matti, can you reproduce it starting with a fresh profile?  I just tried doing 
what you said and could not reproduce it.

Comment 18

•

23 years ago

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.

Comment 19

•

23 years ago

*** Bug 112019 has been marked as a duplicate of this bug. ***

Assignee

Comment 20

•

23 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.

Comment 21

•

23 years ago

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

•

23 years ago

Attached patch bullet-proofing to prevent crash (obsolete) — Details — Splinter Review

Assignee

Comment 23

•

23 years ago

cc'ing alecf and sgehani for reviews

Target Milestone: mozilla0.9.9 → mozilla0.9.7

Alex Vincent [:WeirdAl]

Comment 24

•

23 years ago

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

•

23 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

•

23 years ago

sorry, it seems my build has submitting problems...

Blocks: 112011

Target Milestone: mozilla0.9.9 → mozilla0.9.7

Assignee

Comment 27

•

23 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.

Samir Gehani

Comment 28

•

23 years ago

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

Does patch this work for file:/// URLs?

Assignee

Comment 29

•

23 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.

Alec Flett

Comment 30

•

23 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+

Samir Gehani

Comment 31

•

23 years ago

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

r=sgehani

Attachment #59237 - Flags: review+

David Einstein

Comment 32

•

23 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.

David Einstein

Comment 33

•

23 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.

Darin Fisher

Comment 34

•

23 years ago

Attached patch fix for nsURLParsers.cpp — Details — Splinter Review

Darin Fisher

Comment 35

•

23 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

•

23 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

•

23 years ago

Attached patch enhanced bullet-proofing — Details — Splinter Review

Attachment #59237 - Attachment is obsolete: true

Assignee

Comment 38

•

23 years ago

alecf, darin, please review my enhanced bullet-proofing patch.

Assignee

Comment 39

•

23 years ago

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

r=morse

Attachment #59282 - Flags: review+

Alec Flett

Comment 40

•

23 years ago

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

doh!
sr=alecf

Attachment #59282 - Flags: superreview+

Alec Flett

Comment 41

•

23 years ago

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

sr=alecf

Attachment #59283 - Flags: superreview+

Assignee

Comment 42

•

23 years ago

Patch for nsURLParsers.cpp checked in.

Enhanced bullet-proofing patch will be checked in as soon as review is obtained.

Comment 43

•

23 years ago

I can confirm that your patch (nsURLParsers.cpp) fixed the crash.
(only "host" is empty in cookiemanager and the path is "/C:/Dokumente...")

Samir Gehani

Comment 44

•

23 years ago

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

r=sgehani

Attachment #59283 - Flags: review+

Assignee

Comment 45

•

23 years ago

Enhanced bulletproofing is now checked in as well.  Marking bug as fixed.

Status: ASSIGNED → RESOLVED

Closed: 23 years ago

Resolution: --- → FIXED

Boris Zbarsky [:bzbarsky]

Assignee

Comment 46

•

23 years ago

*** Bug 112247 has been marked as a duplicate of this bug. ***

Jay Patel [:jay]

Reporter

Comment 47

•

23 years ago

verified fixed.  this crash last happened with MozillaTrunk builds 20011126xx.

Status: RESOLVED → VERIFIED

gavin long

Comment 48

•

23 years ago

*** Bug 114165 has been marked as a duplicate of this bug. ***

Comment 49

•

23 years ago

*** Bug 111897 has been marked as a duplicate of this bug. ***

Thomas Buffington Jr.

Comment 50

•

23 years ago

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

•

23 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.

Comment 52

•

23 years ago

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 ?

Jay Patel [:jay]

Reporter

Comment 53

•

23 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

Closed: 23 years ago → 23 years ago

Resolution: --- → FIXED

Summary: Trunk crash [@ COOKIE_GetCookie] → Trunk & M096 crash [@ COOKIE_GetCookie]

Assignee

Comment 54

•

23 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.