376188 - Crash / memory corruption with ​ (zero width space)

Status: RESOLVED DUPLICATE of bug 366643

(Core :: Layout: Text and Fonts, defect)

Description

[Philip Taylor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070401 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070401 Minefield/3.0a4pre

In the attached test case, loading the page into a new instance of Firefox then doing some stuff (reloading, exiting, clicking, opening menus, changing text size, etc) usually results in a crash with reading/writing invalid memory in varying locations. Trying it several times, I got:

  0x00034cdd read 0x00034cdd
  0x601a030c read 0x000a0004
  0x77fcaff8 wrote 0x0064006f
  0x77fcd79a wrote 0x00000000
  0x77fcd79a wrote 0x000c0104
  0x77fcd79a wrote 0x0000000f

The only non-trivial thing in the test case is the string with ​, and it doesn't seem to crash if I remove those characters. If I change the text size, sometimes the text vanishes, and usually it crashes soon after - so I'm guessing this is possibly related to text rendering in some way.

Reproducible: Sometimes

Comment 1

[Philip Taylor]

Attachment: test case

Probably not quite the minimal test case, but fairly close.

Comment 2

[Mats Palmgren (inactive)]

WFM, trunk and branch builds on Windows XP, MacOSX, Linux.

Comment 3

[Mats Palmgren (inactive)]

Philip, if you still have the original file before you started minimizing
it to a testcase please attach that too, thanks.

Comment 4

[Philip Taylor]

I can't easily attach it, but the original is at http://canvex.lazyilluminati.com/tests/20070402/tests/index.all.html - that contains 185 iframes each with a separate document. FF trunk crashes at a seemingly random point, usually before it has finished loading many of them - if not, pressing the refresh button is usually enough to kill it.

Each of the iframed documents contains some ​ characters - if I replace them with spaces, then it loads with no problem. In both cases it loads without crashing in FF 2.0.0.3 (although then it seems to freeze after loading, but I guess that's unrelated and is just caused by having way too many iframes).

Comment 5

[Philip Taylor]

Hmm, it works for me on
  Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a4pre) Gecko/20070401 Minefield/3.0a4pre
but fails on
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070401 Minefield/3.0a4pre
where the only difference is the OS (plus the rest of the computer). I don't have any other Windows 2000 machines to try it on, so I can't tell if that's the issue. If nobody can reproduce it, I'll see if I can get anywhere by attempting to debug it myself.

Comment 6

[Mats Palmgren (inactive)]

URL also WFM, trunk and branch builds on Windows XP, MacOSX, Linux.

Philip, could you enable Talkback and send us crash data please?
See http://kb.mozillazine.org/Quality_Feedback_Agent

Could the crash depend on font settings or installed fonts?

Does the crash occur in Firefox Safe Mode?
http://kb.mozillazine.org/Safe_Mode

Comment 7

[Philip Taylor]

TB30800528Z (the more common crash location) and TB30800713X (less common) - using the Alpha 3 release (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3) Gecko/20070322 GranParadiso/3.0a3), since I suppose it's easier to get debug symbols for that one.

It still crashes with a new profile; and also with a new profile plus safe mode; and also when the sans-serif font is set to either Arial or Bitstream Vera Sans.

Comment 8

[Philip Taylor]

Attachment: corrupted text rendering

On one occasion while testing, one line of text became quite oddly corrupted. After scrolling down the page (so that line went off the top) then back, that text was invisible (but still underlined), and then it crashed.

Comment 9

[Mats Palmgren (inactive)]

Which encoding is selected in the "View->Character Encoding" menu
when you visit the URL?  If you reload a few times, does it show different
values?

Is this a recent trunk regression?  does it also happen in Firefox 2.0.0.3?

Comment 10

[Philip Taylor]

[I'm using the page in the URL, not the attached test case, since it's much more reliable at breaking.]

If the encoding is set to Auto-Detect, then it selects ISO-8859-1 after loading the outer page. If I manually set it ISO-8859-1 or UTF-8, it still crashes. I can't reload the page (because it always crashes) but it does the same each time I restart the browser.

If I replace all the "​" with the equivalent UTF-8 character, and then load the page as UTF-8 (or Auto-Detect), then it crashes. If I load it with ISO-8859-1, then it just displays the misinterpreted bytes (instead of the zero width space) and doesn't crash.

It's not very recent: it crashes in Gran Paradiso Alpha 1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061204 GranParadiso/3.0a1). But it doesn't crash in 2.0.0.3 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3).

Comment 11

[Philip Taylor]

An easier way that I can reliably reproduce the issue: copy the text
    x.​x.​x
(which has a U+200B in the middle of each ".x", unless Bugzilla ate them) and paste it into the address bar once or (rarely) a few times, then it crashes.

If I replace the "."s with a punctuation character (I tried "," and ":" and "#"), it still crashes.
If I replace the "."s with a letter (I tried "x" and "a" and "i"), it never crashes.

Comment 12

[Martijn Wargers (dead)]

I can't reproduce this on windowsxp sp2.
Maybe this is related to bug 366643? (which also only happens on win2000/winxp sp1)

Comment 13

[Philip Taylor]

Looks very much like it is - the test case in bug 366643 crashes for me in the same way as in this bug, so I'll move over there.

Thanks!