Last Comment Bug 311378 - freeze/hang in several seconds when a character which does not exist in fonts is rendered
: freeze/hang in several seconds when a character which does not exist in fonts...
Status: VERIFIED FIXED
[tjp-dl]
: intl, jp-critical, perf, verified1.8.0.2, verified1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: GFX: Win32 (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: mozilla1.8.1
Assigned To: Masatoshi Kimura [:emk]
: Hixie (not reading bugmail)
Mentors:
Depends on: 334217
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-06 11:04 PDT by Masayuki Nakano [:masayuki] (Mozilla Japan)
Modified: 2010-05-03 14:47 PDT (History)
10 users (show)
dveditz: blocking1.8.0.2+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
test case1(EUDC) (577 bytes, text/html; charset=Shift_JIS)
2005-10-06 11:19 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
test case2(�) (498 bytes, text/html)
2005-10-06 11:23 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
Patch rv 1.0 (11.65 KB, patch)
2005-12-13 07:34 PST, Masatoshi Kimura [:emk]
timeless: review+
Details | Diff | Splinter Review
Patch rv 1.1 (11.64 KB, patch)
2005-12-13 14:31 PST, Masatoshi Kimura [:emk]
VYV03354: review+
rbs: superreview+
Details | Diff | Splinter Review
Patch rv 1.2 (11.63 KB, patch)
2005-12-14 05:21 PST, Masatoshi Kimura [:emk]
VYV03354: review+
VYV03354: superreview+
rbs: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-10-06 11:04:50 PDT
If we render a character which is not existing on the system fonts, Firefox and
Thunderbird freeze in several seconds(10 or more). But this is occured in first
time only. I cannot reprodue two or more times.
# This problem is occured by spam mail and non-UTF8 encoded URL.

I think that this problem is occured with U+FFFD or PUA characters.
The glyph of U+FFFD is not exiting on many fonts on Windows. And many systems
are not using EUDC characters too.
Comment 1 Simon Montagu :smontagu 2005-10-06 11:18:51 PDT
Is this really All/All? 
Comment 2 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-10-06 11:19:19 PDT
Created attachment 198708 [details]
test case1(EUDC)
Comment 3 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-10-06 11:23:40 PDT
Created attachment 198709 [details]
test case2(�)
Comment 4 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-10-06 11:26:28 PDT
(In reply to comment #1)
> Is this really All/All? 

The Japanese tester said. This problem is reproduced on Mac. But other tester
said,  cannot reproduce on Linux. I think this problem is related the count of
fonts. If user's system has many fonts, this freeze may be also long.
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-10-06 11:31:44 PDT
I think that this is GFX's performance bug. *But* do we use U+FFFD in converting
Native code to Unicode? And should we support EUDC on default setting in
converting Shift_JIS to Unicode?
Comment 6 Majken Connor [:Kensie] 2005-11-21 22:37:18 PST
Hmm this might be the bug I'm looking for.  I'll describe, and if it's not the same I'll keep looking.

I've only come across this in xp. When someone has a *lot* of fonts installed (reporters of the problem commonly had an adobe program installed that came with many fonts) and they try to load a page that has an international font that they *don't* have (like japanese) cpu goes to 100% for the csrss.exe process and freezes the browser.  I don't have a lot of fonts myself but I still saw a spike, but not as large and it went away pretty quickly. The problem can actually be seen in about:config if the user scrolls to the fonts entries.

The thread that I figured this out in is here http://forums.mozillazine.org/viewtopic.php?p=1671364#1671364
 that post is around where we started figuring it out.

Is this the same issue?
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-11-21 22:46:54 PST
Yeah, maybe, does it occur when the "network.IDN.blacklist_chars" or "font.name-list.*" is shown? If so, this is same problem.
Comment 8 Majken Connor [:Kensie] 2005-11-21 23:02:06 PST
Yes the font.name-list entries are the about:config entries I meant. Like you, I seem to recall the cpu spike in the cases I've seen only happen the first time in a session, but if you restart the browser it happens again.
Comment 9 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-12-13 06:03:02 PST
The Mac tester go to vacation. We cannot get other report for this problem on Mac.
We have a proposal patch in bugizlla-jp. Therefore, we will fix this bug on Win only. If you can reproduce this problem on non-Win OS, please file a new bug.
Comment 10 Masatoshi Kimura [:emk] 2005-12-13 07:34:52 PST
Created attachment 205727 [details] [diff] [review]
Patch rv 1.0

timeless:
Could you take a look?
Comment 11 Masatoshi Kimura [:emk] 2005-12-13 07:35:50 PST
Comment on attachment 205727 [details] [diff] [review]
Patch rv 1.0

timeless:
Could you take a look?
Comment 12 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-12-13 07:36:32 PST
Curreny performance for font finding score is 7.94277 sec.
I get this score by following patch.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3029&action=view

With following patch
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3030&action=view

the score is 0.487671 sec!!
This is great!!!

Both tests are done immediately after system reboot.
The test environment is:
Athlon64 3700+, Memory 1G * 2(Dual channel),
Win2000, Fonts folder has 470 files.

We want this patch for 1.8.x.
Let's fix it.
Comment 13 timeless 2005-12-13 09:38:34 PST
Comment on attachment 205727 [details] [diff] [review]
Patch rv 1.0

>Index: gfx/src/windows/nsFontMetricsWin.cpp
>diff -u -8 -p -r3.239 nsFontMetricsWin.cpp
>@@ -2725,69 +2725,120 @@ nsFontMetricsWin::SameAsPreviousMap(int 
>+#ifndef WINCE
>+static
>+void BitFromUnicodeRange(PRUint32 range, DWORD usb[4])
>+{
>+  memset(usb, 0, sizeof(DWORD) * 4);
>+  for (int i = 0, dword = 0; dword < 3; ++dword) {
>+    for (int bit = 0; bit < sizeof(DWORD) * 8; ++bit) {
>+      if (range == gBitToUnicodeRange[i]) {
>+        usb[dword] |= 1 << bit;
>+      }
>+      ++i;

any reason not to do:
+    for (int bit = 0; bit < sizeof(DWORD) * 8; ++bit, ++i) {
?
Comment 14 Masatoshi Kimura [:emk] 2005-12-13 14:31:44 PST
Created attachment 205757 [details] [diff] [review]
Patch rv 1.1
Comment 15 rbs 2005-12-14 02:20:21 PST
Comment on attachment 205757 [details] [diff] [review]
Patch rv 1.1

Nice fix. It fits nicely with the spirit of not doing premature optimizations.

+ memset(usb, 0, sizeof(DWORD) * 4);

To increase the readability a little bit, use: memset(usb, 0, sizeof(usb));
Comment 16 rbs 2005-12-14 02:41:26 PST
Actually, I don't like the usb[4] as argument. I like the following way better:

+static
+void BitFromUnicodeRange(PRUint32 range, DWORD* usb)
+{
+  for (int i = 0, dword = 0; dword < 3; ++dword) {
+    for (int bit = 0; bit < sizeof(DWORD) * 8; ++bit, ++i) {
+      if (range == gBitToUnicodeRange[i]) {
+        usb[dword] |= 1 << bit;
+      }
+    }
+  }
+}

[...]

+  PRUint32 range = (c <= 0xFFFF) ? FindCharUnicodeRange(c) : kRangeSurrogate;
+  DWORD usb[4];
+  memset(usb, 0, sizeof(usb));
...
Comment 17 Masatoshi Kimura [:emk] 2005-12-14 05:21:40 PST
Created attachment 205824 [details] [diff] [review]
Patch rv 1.2

Integrated rbs' comment.
Comment 18 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-12-14 06:53:01 PST
checked-in.

Thank you, Mr.emk!

# unfortunately, today's nightly build has been built.
Comment 19 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-12 09:56:30 PST
Comment on attachment 205824 [details] [diff] [review]
Patch rv 1.2

Let's go to 1.8.1 too. We don't have any regression reports. And this patch's performance is so fantastic!
Comment 20 Stefan Sitter 2006-01-22 04:35:11 PST
Could the check in for this bug be the cause for Bug 324311 (Profile creation fails on windows if non-ascii characters in profile path)? Works in win32-2005-12-13-07-trunk build, fails in win32-2005-12-14-08-trunk build.
Comment 21 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-22 06:12:42 PST
I don't think so. Because the patch changed only gfx code.
Comment 22 rbs 2006-01-30 14:24:38 PST
What does this branch‑1.8.1 thing mean? (i.e., how does it differ from approval1.8.1). And why is it assigned to me?
Comment 23 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-31 02:18:16 PST
rbs:

See http://developer.mozilla.org/devnews/index.php/2006/01/30/tree-rules-for-the-18-branch/

Now, we don't need approval from drivers@m.o for checkin to 1.8 branch. But we need approval from module owner or peers.
Comment 24 rbs 2006-01-31 19:30:04 PST
Comment on attachment 205824 [details] [diff] [review]
Patch rv 1.2

+'ing for the 1.8 branch. Go for it then.
Comment 25 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-02-01 06:31:17 PST
checked-in to 1.8 branch.
Comment 26 Daniel Veditz [:dveditz] 2006-02-14 15:23:37 PST
How can this bug depend on a WONTFIX bug? (bug 319034). Someone please fix the inconsistency (remove dependency or reopen the other bug)
Comment 27 Daniel Veditz [:dveditz] 2006-02-14 15:58:24 PST
Comment on attachment 205824 [details] [diff] [review]
Patch rv 1.2

approved for 1.8.0 branch, a=dveditz for drivers
Comment 28 Masatoshi Kimura [:emk] 2006-02-15 04:23:54 PST
Bug 319034 was proposed as a workaround. It's no longer required to fix the problem.
Removing dependency.
Comment 29 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-02-17 08:01:43 PST
-> v.
Comment 30 tim 2006-05-13 05:07:22 PDT
I'm still suffering this problem in FF 1.5.0.3 I am a graphic designer and have approx 4000 fonts installed. Just to note, I have Adobe's Type Manager software installed.
One page that freezes up is on Google. Click on 'About Google', then click on 'Google Labs'. At this point, FF freezes, HDD starts churning away and the csrss.exe process canes the CPU at 100% for a couple of minutes. Then, all is well. Frustrating.

cheers
Tim
Comment 31 Leonard Mada 2010-05-03 14:47:31 PDT
I am still experiencing this bug in the latest Firefox dev-build, and I am fairly convinced that this is the bug, please see:
https://bugzilla.mozilla.org/show_bug.cgi?id=553854

I have still adobe ATM installed on my Win2k system, and probably a fair amount of fonts. However, Seamonkey (latest official build) runs smoothly, so this issue has been introduced recently (in one of the FF dev builds).

Note You need to log in before you can comment on or make changes to this bug.