User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8) Gecko/20051111 Firefox/1.5 1. open the Firefox browser; 2. type "www.it.com.cn" in the address; 3. perss the "Enter" button; 4. the Firefox Browser will occur crash. Reproducible: Always Steps to Reproduce: 1. open the Firefox browser; 2. type "www.it.com.cn" in the address; 3. perss the "Enter" button; 4. the Firefox Browser will occur crash.

Works fne for me: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Confirming crash Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8) Gecko/20051107 Firefox/1.5 TB: TB12425042M

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051130 Firefox/1.6a1 ID:2005113005 WFM on branch and trunk + flash 8.0r22.

Has a possible dupe in bug 326411 with a number of talkbacks...

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

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

I am having a similar issue with my install of FireFox as of this morning. I've attached the stack trace. The event is TB18495137M. Hope this was helpful.

I went to the website which was posted by the reporter. I messed around with it until a crash happened and let Dependency Walker grab the information. I attached it, maybe it will be useful -- it's all greek to me :-)

Comment on attachment 221554 [details] Dependency Walker Output that's funny. 0x77C478C0==msvcrt!strlen+0x20 so you probably can blame bsmedberg for this crash. It should mean strlen(0). msvcrt!strlen: 77c478a0 8b4c2404 mov ecx,[esp+0x4] 77c478a4 f7c103000000 test ecx,0x3 77c478aa 7414 jz msvcrt!strlen+0x20 (77c478c0) 77c478ac 8a01 mov al,[ecx] 77c478ae 41 inc ecx 77c478af 84c0 test al,al 77c478b1 7440 jz msvcrt!strlen+0x53 (77c478f3) 77c478b3 f7c103000000 test ecx,0x3 77c478b9 75f1 jnz msvcrt!strlen+0xc (77c478ac) 77c478bb 0500000000 add eax,0x0 77c478c0 8b01 mov eax,[ecx] ; you are crashing here. which is derefencing a null pointer 77c478c2 bafffefe7e mov edx,0x7efefeff 77c478c7 03d0 add edx,eax 77c478c9 83f0ff xor eax,0xffffffff 77c478cc 33c2 xor eax,edx 77c478ce 83c104 add ecx,0x4 77c478d1 a900010181 test eax,0x81010100 77c478d6 74e8 jz msvcrt!strlen+0x20 (77c478c0) 77c478d8 8b41fc mov eax,[ecx-0x4] 77c478db 84c0 test al,al 77c478dd 7432 jz msvcrt!strlen+0x71 (77c47911)

I thought that PL_strlen was supposed to catch those cases. May PL_strlen isn't used everywhere. PR_IMPLEMENT(PRUint32) PL_strlen(const char *str) { size_t l; if( (const char *)0 == str ) return 0; l = strlen(str); /* error checking in case we have a 64-bit platform -- make sure * we don't have ultra long strings that overflow an int32 */ if( sizeof(PRUint32) < sizeof(size_t) ) PR_ASSERT(l < 2147483647); return (PRUint32)l; }

PL_strlen does, nsCRT::strlen did until it was replaced by NS_strlen which does not.

Comment on attachment 221554 [details] Dependency Walker Output Note that while the discussion about the crash involving msvcrt.dll (as observed from the dependency walker log) is still valid, but does not related to this bug seeing as how the dep. walker log is from a different crash.

TB18535159E -- newest crash on my end, walker log attached.

no crash for me with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090617 Minefield/3.6a1pre (.NET CLR 3.5.30729)

WFM as well. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091221 Firefox/3.7a1pre I don't see nsComboboxControlFrame::CreateAnonymousContent calling strlen, so I don't know what to make of the stuff timeless was talking about.