Closed Bug 137322 Opened 22 years ago Closed 20 years ago

URL: long strings -> crash [@ MSVCRT.DLL ]


(Core :: Networking, defect, P1)

Windows XP





(Reporter: cplyon, Assigned: gordon)



(Keywords: crash)

Crash Data


(2 files, 1 obsolete file)

Using build 2002041203 on WinXP.

Steps to reproduce:
1. Enter a 998+ character string into the URL Bar
or click an http link that long.

Results: crash

I admit this is an unlikely scenario, but according to the discussion in bug 
56192,  Mozilla should support URLs up to 2048 characters.

Talkback IDs:
Adding crash keyword.
Keywords: crash
can't reproduce this in 0.9.9 or trunk 2002041218 on linux
WFM trunk win32 (xp) 2002041203 - so same build, same os...
I will research this bug.
i test the long url of attachment,mozilla didn't crash,but it will hang on.
+cc: more URL help...
Summary: Extremely long URLs crash Mozilla → URL: long strings -> crash
WFM 0.9.9 linux.

I don't think this could be located in core networking, there is no limit on
urllength in there. Other possible locations where urls are stored:


Could someone take a look at these talkback IDs and publish a stacktrace or
something similar here? That should give a clue.
I think this bug should be closed,because browser didn't crash.
Closed: 22 years ago
Resolution: --- → WORKSFORME
Still crashes for me on 2002041710 on WinXP with a clean profile.

New talkback id:

Reopening until someone posts the talkback info or stack trace.  Crashes 
shouldn't be dismissed so quickly :)

Antonio: are you clicking the link in the attachment?  What build are you 
using?  What OS?
Resolution: WORKSFORME → ---
i use 2002041510 build on win2000,i click the linking in the attachment,but mozilla 
didn't crash,it will hang on,did you waiting for a long time before mozilla crash.
It crashes almost instantly after clicking the link.

I can reproduce using Mozilla 1.0 RC1 (2002041711) on Win XP - clean install.
Talkback id: 
Crashed for me, WIN98SE, Talkback ID: TB5657688X. Using Mozilla 1.0RC1 Build:
*** Bug 151904 has been marked as a duplicate of this bug. ***
It'd be nice if someone looked at this. Kinda nasty, if someone wanted to be "bad". 

Copying Mattis' comment from Bug 151904:

memset() line 108
PR_ConvertIPv4AddrToIPv6(unsigned int 0, PRIPv6Addr * 0x00000000) line 1529 + 13 
nsDNSLookup::HostnameIsIPAddress() line 693 + 22 bytes
nsDNSLookup::InitiateLookup() line 709 + 8 bytes
nsDNSLookup::EnqueueRequest(nsDNSRequest * 0x041cedb8) line 784 + 8 bytes
nsDNSService::Lookup(nsDNSService * const 0x01071238, const char * 0x03f26f48, 
nsIDNSListener * 0x03e5121c, nsISupports * 0x00000000, nsIRequest * * 
0x03e51234) line 1476 + 12 bytes
nsSocketTransport::doResolveHost() line 734 + 78 bytes
nsSocketTransport::Process(short 0) line 517 + 8 bytes
nsSocketTransportService::ProcessWorkQ() line 306 + 10 bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x010bdf3c) line 
552 + 11 bytes
nsThread::Main(void * 0x010bd3a0) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x010c6f60) line 433 + 13 bytes
_threadstartex(void * 0x01015c38) line 212 + 13 bytes
KERNEL32! 77e86523()

-> Networking
Noting that it crashes with the latest nightlies on win32.
Lets put a sample URL into the URL field of this bug...
If I was still "there" (refer to old BA postings as I woulda
done it. 

This is ugly. This will generate bad PR. This has been around since the first
Moz-based public releases. Someone will exploit this. 

I'm just sayin. Adding my cheesy attachment. Adding Darin too. I'm just a QA
guy. If I knew how to code, I'd be dangerous.

Attached image win32 moz killer (obsolete) —
D'oh. Sorry. The above attachment will not crash your browser if you open it.
You have to click on a link first. I'm being "nice". :)
Attachment #87773 - Attachment is obsolete: true
since our DNS implementation varies from platform to platform, its perhaps no
surprise that this crash is only reported under windows.  i'll take a look...
Assignee: new-network-bugs → darin
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
CONFIRMED: Chimera 0.3, while I am at it, using the example from bug 151904.
+nsbeta1, all/all

Keywords: nsbeta1
OS: Windows XP → All
Hardware: PC → All
Should we bump up the priority? Reproducible crash, possible exploit....
-> DNS (gordon)
Assignee: darin → gordon
I am still experiencing this crash on 2002090708 on WinXP.

Talkback id: TB10556787Z
UPDATE: Mozilla 1.1, Mac OS X and Linux. did not reproduce.
Received DNS error (cannot be found).
Changing product.
Component: Networking → NSPR
Product: Browser → NSPR
Target Milestone: mozilla1.1beta → ---
Wan-Teh, shouldn't PR_StringToNetAddr() catch this and fail?
Assignee: gordon → wtc
QA Contact: benc → wtc

PR_StringToNetAddr() probably should catch this and fail.
I suggest that you work around this in your code.  Two
possible workarounds:
1. Check the string's length before passing it to
2. Check the return value of BufAlloc and handle a nsnull
return value as you do in nsDNSLookup::ConvertHostEntry().

#2 seems like a good thing to do anyway.
Assignee: wtc → gordon
Component: NSPR → Networking
Product: NSPR → Browser
QA Contact: wtc → benc
Okay, I'll work around it in our code, and write up a separate bug for
Priority: P2 → P1
I can still reproduce this on 20021130 on WinXP

upgrading to critical since this is an exploitable crasher.
Severity: major → critical
+clean-report - this needs to be targeted, unless there is further info needed.
Keywords: clean-report
re comment 28:
When I have my proxy enabled (as usual) this also does not crash, only give the
said DNS error.
But when I switch to "directly connected to the internet" I get this crash.
So maybe proxy settings make the difference.
2003012508 on Win2k.
Andreas: if I understand the problem correctly, the crash occurs in handling
DNS/IP addressing. A proxy configuration does not do this, the URL is directly
sent to the proxy.
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Still as reported using Moz 1.4:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

Talkback ID: TB22264128M
*** Bug 216553 has been marked as a duplicate of this bug. ***
crash loading testcase, TalkbackID of latest Mozilla:
TB22857576X with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030818
the dns rewrite eliminates the BufAlloc code, which should have the side-effect
of fixing this bug.
Depends on: 205726
Summary: URL: long strings -> crash → URL: long strings -> crash [@ MSVCRT.DLL ]
As Darin said, this bug is gone. Tested with current cvs build on Win2k.
Can anybody test on Linux/Mac? (I guess it makes no difference...)
So this can be resolved, right?
WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040117
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

Marking resolved.

Closed: 22 years ago20 years ago
Resolution: --- → FIXED
Resolution: FIXED → ---
No patch / checkin has been identified for having fixed the bug.

Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
> the dns rewrite eliminates the BufAlloc code, which should have 
> the side-effect of fixing this bug.

This comes close enough, no?
That was my thought as well... Jason? It's certainly not a WFM resolution.
Resolution: WORKSFORME → ---
Okay, fair enough.  Fixed by "DNS rewrite".  But if anybody knows the bug number
for that, please reference it here.
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Yes, I'm an idiot.  Fixed by bug 205726.
Verified, per windows users comments above.
has not been a problem in mac or linux since 1.1 (see #28).

BTW, fixed w/ a dependency is best way to resolve this!
OS: All → Windows XP
Hardware: All → PC
Crash Signature: [@ MSVCRT.DLL ]
You need to log in before you can comment on or make changes to this bug.