592 bytes, text/html
629 bytes, patch
|Details | Diff | Splinter Review|
460 bytes, text/plain
152.10 KB, application/octet-stream
2002040708 and later builds crash in ASIACOL.DLL (OS/2 system DLL for Asian collation) when I open the URL and if "MINCHO" or "MINCHO Proportional" is set for Japanese font. If font for Japanese is "Tms Rmn" (default by clean install) or "MINCHO HeiseiMincho-*", browser doesn't crash. I think this bug is related to recent changes for bug 132660. Reproducible: Always Steps to Reproduce: 1.Re-install mozilla and run it with new profile. 2.Change Preferences/Appearance/Fonts/font for Japanese/Serif from "Tms Rmn" to "MINCHO". 3.Open the URL. Actual Results: MOZILLA.EXE crash with SYS3175 in ASIACOL.DLL. Expected Results: Doesn't crash.
Created attachment 79402 [details] simplified testcase Testcase, simplified and modified from the URL. This html says "charset=Shift_JIS" in own meta header but no Japanese characters are included.
-> i18n, os/2
Assignee: jaggernaut → yokoyama
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → Internationalization
Ever confirmed: true
QA Contact: jrgm → ruixu
Give it to mkaply for further investigation.
Assignee: yokoyama → mkaply
Created attachment 79512 [details] [diff] [review] Fix for problem The problem appears to be an OS/2 bug where we get 65535 when we query the leading of a certain MINCHO font. The workaround is to cast the leading to a signed short before using it. This should fix things.
Comment on attachment 79512 [details] [diff] [review] Fix for problem r=pedemont Javier reviwed this sr=blizzard for platform specific code.
Comment on attachment 79512 [details] [diff] [review] Fix for problem firstname.lastname@example.org
Attachment #79512 - Flags: approval+
I checked in what I hope is a fix for this. I am going to leave the bug open until we do some more checking. Attempted fix will be in tomorrows builds both trunk and branch.
I'm running 2002042008 but it still crash with the testcase. ------------------------------------------------------------ 04-21-2002 05:56:39 SYS3175 PID 0557 TID 0001 Slot 00b2 F:\WARPZILLA-NIGHTLY\BIN\MOZILLA.EXE c0000005 111100d8 P1=00000001 P2=301c30a5 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=0012c4b6 ECX=301c3001 EDX=00000052 ESI=0012c4a4 EDI=0079eda0 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:111100d8 CSACC=f0df CSLIM=ffffffff SS:ESP=0053:0012bda0 SSACC=f0f3 SSLIM=ffffffff EBP=0012c60c FLG=00212246 ASIACOL.DLL 0001:000000d8 ------------------------------------------------------------ Additional information: One of my PC doesn't crash just by open the testcase. It needs to change font size (Ctrl++/Ctrl+-) to crash. Another 100% crash site: http://www.geocities.co.jp/SiliconValley-Bay/4081/index.html
All OS/2 box I have (2 MCP1 and 1 MCP2) still have crash in ASIACOL.DLL but my friends say they have never seen the crash. At this time I should say this crash appears only in me. I wonder what is the different between me and them. Is there anything I should try?
We have seen the crash, but it is very difficult to recreate. I've even seen it just bringing up the history on my Japanese machine, but then when I tried it again, it worked. It seems to happen more on release builds than debug builds. I'm going to be looking at this more today and I hope to have something soon.
2002042409 and later builds never crash in ASIACOL.DLL with testcases. The final build having crash was 2002042208. The problem was gone..?
Did you change anything else about your system? I would be very happy if this crash was gone :)
Nothing of my system was changed. I still have the crash if I use 2002042208 or older build on my current system. I wonder if 2002042008-2002042208 included your patch actually.
Not sure, but we did put some new font code in. Glad to see it is working. I'll mark this WORKSFORME. Please open it again if you see the problem.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Unfortunately, I get the crash on another page: http://www.zeryx.com/English/download.html I'm using 2002050508 trunk build and crash 100% when to open the page. Could someone recreate?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Additional information: I copy the ZxMail page to my local site and modify a little - remove java script and merge external style sheet. 1) http://www.serina.org/~mozilla/137693/test1.html - mozilla crash 2) http://www.serina.org/~mozilla/137693/test2.html - doesn't crash A difference between 1 and 2 is "Helvetica" is present or not in font-family of style for body.
2002051308 trunk build is back to stable with testcase of comment 16. I currently have no specific site to crash this build. Mmm...give me a few more days to validate with a lot of sites.
I saw the crash once after comment 17 (but I lost the URL of the site). I think the problem still is... By the way, Other Japanese guy reported that he had same crash at google.com then he renamed ASIACOL.DLL to avoid the crash. So we wonder what the ASIACOL.DLL is for. Is it necessary for OS/2 system? OS/2 English version has the DLL too? If the DLL is not important for our system, renaming it will be workaround for this bug.
I am having a great deal of trouble reproducing this again. I am using the nightly on a Japanese system. What are your fonts set to? Does it happen with a new profile?
Here is font settings from prefs.js for your reference. user_pref("font.default", "sans-serif"); user_pref("font.language.group", "x-western"); user_pref("font.name.cursive.ja", "System Monospaced"); user_pref("font.name.cursive.x-western", "Arial"); user_pref("font.name.fantasy.ja", "System Monospaced"); user_pref("font.name.monospace.ja", "�ｭ�ｳ 繧ｴ繧ｷ繝�け"); *1 user_pref("font.name.sans-serif.ja", "MINCHO Proportional"); user_pref("font.name.serif.ja", "MINCHO Proportional"); *1: Actual font is "MS Gothic" I am using a common profile setting MOZILLA_HOME variable in config.sys. So for a test purpose I unzipped mozilla-os2.zip (2002051716) in a new directory. I could successfully access to google.com (google.co.jp) using default font settings, but if I once set Japanese fonts as avobe the subsequent attempts to access the site failed in ASIACOL.DLL.
Fortunately (or unfortunately?), I have not been seeing this crash on trunk builds since May 16. I will back to trunk build and continue to watch the crash.
I think Masao is using 1.0 branch build then I also tried 2002051716(1.0rc3). I didn't get the crash at Google, however, I found another crash page: http://www.opera.com/download/get.pl?uilang=en&opsys=OS/2 All I did at preferences since clean install of this build (w/o migration) was let mozilla use localhost:10080 as a http proxy because I don't have direct connection at here. Note that I didn't change any font and character set configuration. Mike and Masao, can you recreate the crash? If not, I think we cannot share the procedure to recreate this crash anyway. # Cc: Masao # Masao, please remove your address from CCs list if you don't like.
Created attachment 84421 [details] My prefs.js of 2002051716 (1.0rc3) This is my prefs.js which is enough to crash 2002051716 (1.0rc3) at http://www.opera.com/download/get.pl?uilang=en&opsys=OS/2
I confirmed 100% crash on the opera.com as reported in comment #22. Used build is 2002051716 and I renamed my prefs.js for test, so Mozilla was executed under default settings and he always fell in crash.
I'm having no trouble reproducing this now. At this point it looks like a compiler optimzer bug. We are still investigating.
I just uploaded Mozilla RC3 and I did not optimize the NSLOCALE.DLL. Can you see if this fixes the trap? We are still investigating the problem. Thanks
Is the build rc3-2002052410 in /pub/mozilla/releases/mozilla1.0rc3/ ? 110024 2002-05-24 11:44 mozilla.exe 40584 2002-05-24 11:43 components/nslocale.dll It still crashes in asiacol.dll at the page of Opera site.
OK, we have determined the problem. It is an OS/2 bug. ASIACOL.DLL has a System calling convention while LIBUNI has an Optlink calling convention. This means this can never work right. The correct workaround is to rename ASIACOL.DLL to ASIACOL.BAK. We are working with the OS/2 folk to figure out how this happened.
Okay, I will notify the workaround to Japanese Warpzilla lovers. Thank you very much for your investigation.
I could have found a font setting to cause the crash. It depends on whether MINCHO Proportional is used as a font for proportional text or not. So there are two combinations of Japanese fonts to meet this condition. They are: "Proportional: Serif" --> "Serif: MINCHO Proportional" and "Proportional: Sans Serif" --> "Sans Serif: MINCHO Proportional". Using one of the above settings I have tested various builds for reproducing this problem and got the following result. google.co.jp opera.com ------------ --------- 2002041116 (Release 0.9.9) ok ok 2002042516 (Release 1.0rc1) crash crash 2002050308 (Nightly) crash ok 2002051021 (Release 1.0rc2) crash crash 2002051508 (Nightly) ok ok 2002052108 (Nightly) ok ok 2002052308 (Nightly) ok ok 2002052410 (Release 1.0rc3) crash ok Even if on crash builds I have once avoid using MINCHO Proportional as a proportional text font, Mozilla worked fine on any url. As for this issue, Nightlies seem, at least on my MCP2 box, to be more stable than Release builds. Is there any difference between them?
Shiomi-san, I understand you are seeing different results with different builds, but the solution is really to rename ASIACOL.DLL. The reason 0.9.9 worked so well is that the new font code was not even in. As far as nightlies vs. release, they are the same code. I think this problem is greatly dependent on the state of the system. ASIACOL.DLL is definitely broke and we are going to discuss it with the OS/2 team next week.
Created attachment 86481 [details] Fixed ASIACOL.DLL Don't tell ANYONE I gave this to you :) Please let me know if this new ASIACOL.DLL fixes the problem.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → WONTFIX
As this is an OS/2 bug, we can't fix it. I've put something about this in the Moz 1.0 README.
Thanks for the treasure :) It never crash in all testcases mentioned here.
I also confirmed that Mozilla doesn't crash with new ASIACOL.DLL. Thanks.
Mark bug as verified as per comments above.
Status: RESOLVED → VERIFIED
*** Bug 191983 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.