122083 - Typing "vi " or "v " into URL bar and pressing enter freezes Mozilla

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Jukka Laurila]

When you type "vi " or "v " in the URL bar and press Enter the browser freezes
and consumes all available CPU. Turning Internet Keywords or autocompletion on
or off has no effect. I wasn't able to find any other words that hang the
browser. Other single letters than v and other two-letter words beginning with
v work as expected (I tried them all).

In particular, the word "emacs" works just fine ;)

The bug exists at least in Mozilla 0.9.7 (I tried all the words only on 0.9.7),
0.9.6 and the most recent nightly build. I tried removing my .mozilla directory
and my .netscape directory and thus restarting with the default configuration,
but the bug remained.

Comment 1

[Ian Graham]

This also happens under Windows 98, on builds 2001122106 (0.9.7)
and 2002010204 (with SVG and MathML). CHanging OS to all.

Comment 2

[Arthur]

Also on Linux 2002012505, 0.9.8 branch. Show yourself, vi-hater ;)

Comment 3

[David Gerard]

Whoo, there it goes! Confirmed 2002012605-0.9.8/WinNT4.

Man, this is a great Stupid Mozilla Trick ;-)

Comment 4

[Bradley Baetz (:bbaetz)]

...and because the url popup was active, X had grabbed the cursor. I had to
change to a different VC and kill mozilla-bin to get mozilla to exit.

/me avoid making a snide remark about vi's FAQ being "how do I quit"

Oh. Oops. Too late. ;)

Comment 5

[Bradley Baetz (:bbaetz)]

OK, debugging from the console gives me:

###!!! ASSERTION: not a UTF8 string: 'Error', file
/home/bbaetz/src/mozilla/string/obsolete/nsString2.h, line 682
###!!! Break: at file /home/bbaetz/src/mozilla/string/obsolete/nsString2.h, line 682
###!!! ASSERTION: calculator calculated incorrect length: 'count == mLength',
file /home/bbaetz/src/mozilla/string/obsolete/nsString2.cpp, line 1556
###!!! Break: at file /home/bbaetz/src/mozilla/string/obsolete/nsString2.cpp,
line 1556

I managed to ctrl-c, and change threads from gdb. The backtrace was pointing
into js land, and (I'm not quite sure why the entire assertion string didn't
show. I could have lost it in the scrollback, which only lasts til I change to
another VC)

I lost the top of the stack, but it SetCapacity with a very very large argument
(ie several million) was at the top, and below the string code was just generic
xpconnect stuff.

ccing jag, although I'm not sure that this is a strings thing.

Comment 6

[Matthias Versen [:Matti]]

Attachment: win2k stack trace

Comment 7

[jag (Peter Annema)]

The problem lies here:

nsDefaultURIFixup.cpp:

if (uriString.EqualsIgnoreCase("view-source:", 12))
{
  ...
  tempString = Substring(uriString, 12, uriString.Length() - 12);
}

with uriString = "vi"

For some odd reason, this matches.

[some time passes]

Actually, it's not odd... The StrCompareXtoY are broken, and it looks like they
have been broken for a good while. Have a fix.

Comment 8

[jag (Peter Annema)]

Attachment: Fix TranslateCompareResult to address the situation where sourceStr, destStr or both are shorter than aCount

Comment 9

[Arthur]

Is this low risk enough and therefore could land on the 0.9.8 branch?

Comment 10

[Alec Flett]

Comment on attachment 66738 [details] [diff] [review]
Fix TranslateCompareResult to address the situation where sourceStr, destStr or both are shorter than aCount

doh! sr=alecf

Comment 11

[Alec Flett]

I think so.

Comment 12

[brightice]

confirmed on HP-UX, mozilla build 2001122723

Comment 13

[David Bradley]

Comment on attachment 66738 [details] [diff] [review]
Fix TranslateCompareResult to address the situation where sourceStr, destStr or both are shorter than aCount

r=dbradley

Looks good to me. I couldn't find any holes in the logic now.

Comment 14

[Asa Dotzler [:asa]]

a=asa (on behalf of drivers) for checkin to 0.9.8

Comment 15

[jag (Peter Annema)]

Checked in to trunk and branch.