Closed Bug 137693 Opened 22 years ago Closed 22 years ago

[OS/2] crash in ASIACOL.DLL to display specific page with DBCS raster font

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: achain, Assigned: mkaply)

References

(
URL
)

Details

(Keywords: crash, intl)

Attachments

(4 files)

simplified testcase
592 bytes, text/html
Details
Fix for problem
629 bytes, patch
mkaply
: review+
mkaply
: superreview+
jesup
: approval+
Details | Diff | Splinter Review
My prefs.js of 2002051716 (1.0rc3)
460 bytes, text/plain
Details
Fixed ASIACOL.DLL
152.10 KB, application/octet-stream
Details 
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.
Attached file 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
Keywords: crash
Give it to mkaply for further investigation.
Assignee: yokoyama → mkaply
Keywords: intl
Attached patch Fix for problem — — Splinter Review 
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.
Attachment #79512 - Flags: superreview+
Attachment #79512 - Flags: review+
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
Closed: 22 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.

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.
Attached file 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
Closed: 22 years ago → 22 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.

Attachment

General

Creator:
Created:
Updated:
Size: