From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98) BuildID: 00000000 - Bidi build dated 20010404 When trying to change the font for a specific encoding, Mozilla crashes with an illegal operation in GKGFXWIN.DLL Reproducible: Always Steps to Reproduce: 1.Open file Ken.htm 2.From the Edit Menu -> Preferences, select font 3.Select Unicode encoding, and change the fonts to: Serif : Traditional Arabic Sanserif: Courier 4. press OK Actual Results: MOZILLA caused an invalid page fault in module GKGFXWIN.DLL at 0167:00cd0250. Registers: EAX=01f57e20 CS=0167 EIP=00cd0250 EFLGS=00010202 EBX=000007a2 SS=016f ESP=007088a0 EBP=bff224fe ECX=00000019 DS=016f ESI=000000c0 FS=6daf EDX=000004cc ES=016f EDI=0077526c GS=0000 Bytes at CS:EIP: 8b 14 97 d3 ea f6 c2 01 75 22 ff 44 24 10 83 c6 Stack dump: 00009999 01c99620 00708908 000007a2 00000002 01c99620 00cd105b 000007a2 00009999 00000000 01c9fbe0 00000000 00cccc36 000007a2 00009999 00708bac One time I received the following: MOZILLA caused an invalid page fault in module GKLAYOUT.DLL at 0167:0151ef01. Registers: EAX=024eb0c0 CS=0167 EIP=0151ef01 EFLGS=00010202 EBX=00000000 SS=016f ESP=0070d5ec EBP=0070d634 ECX=00000001 DS=016f ESI=024eda20 FS=3fef EDX=0070d5ec ES=016f EDI=024eda20 GS=0000 Bytes at CS:EIP: ff 91 e0 00 00 00 33 c0 c3 56 8b f1 6a 00 8b 46 Stack dump: 024eb0c0 00000001 0151e3c9 024eda20 80000000 0151abf3 00000000 02522710 00000020 00830980 01cdd3a0 01503f83 01cdd3a0 00000000 02522710 013f3100 Expected Results: Mozilla should be able to change the font successfully without crashing.

add crash keyword

[BiDi] is reserved for bugs found by Andreas' team when testing my IBMBIDI and non-IBMBIDI builds.

can be reproduced by 0425 bidi build. reassign to ftang for moz0.9.1

This also cause crash in 0425 nobidi build. Therefore, this crash is independent from IBMBIDI work. Reassign to shanjian to look at.

Since this is a nobidi issue setting QA contact to ylong@netscape.com. Adding keyword intl.

Why it crashes: After font preference setting is changed, font cache is flushed. All cmap are free at this stage, but gGlobalFont are not. (That's a memory leakage!) So when destroyed cmap is referenced through gGlobalfont, we got this crash. frank or naoki, can one of you review the code?

r=nhotta, please remove commented lines if they are unnecessary.

chris, can you sr this one?

+ if (nsFontMetricsWin::gGlobalFonts) //while all cmap is freed, gGlobalFonts's pointer should be freed too. + { Local custom puts curly on same line as |if|. + //if (nsFontMetricsWin::gGlobalFonts[i]) + // nsFontMetricsWin::gGlobalFonts[i].map = nsnull; What nhotta said: if these lines aren't needed, remove 'em. Out of curiosity, do we ever free the 8KB allocated by nsFontMetricsWin::GetCMap()? If not, please file that as a separate bug. Make above changes, and file a bug if necessary, and sr=waterson

modified as suggested, and ready to check in. Cmap is freed. Because cmap is freed using hashtable pointer as reference, and global fonts pointer is not cleared, we have this problem.

fix checked in.

reopen because of a regression in 80756.

what is the status ? any progress ?

previous change was backed out. I am working on new patch now.

patch explaination: "if (0 == --gFontMetricsWinCount)" is not the right way to free all global stuff. This test holds in many situation. Generating cmap is expensive, and reinitialization often cause problem. So I use an observe to do shutdown stuff instead.

/r=yokoyama on 05/16/01 10:28.

sr=waterson; please remove gFontMetricsWinCount completely since it doesn't appear to be needed at all anymore.

fix checked in.

Verified as fixed on 5-31-06 Win32 build.