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




17 years ago
16 years ago


(Reporter: achain, Assigned: mkaply)


({crash, intl})

crash, intl

Firefox Tracking Flags

(Not tracked)




(4 attachments)



17 years ago
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.

Comment 1

17 years ago
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.

Comment 2

17 years ago
-> i18n, os/2
Assignee: jaggernaut → yokoyama
Component: XP Toolkit/Widgets → Internationalization
Ever confirmed: true
QA Contact: jrgm → ruixu


17 years ago
Keywords: crash

Comment 3

17 years ago
Give it to mkaply for further investigation. 
Assignee: yokoyama → mkaply


17 years ago
Keywords: intl
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

Javier reviwed this
sr=blizzard for platform specific code.
Attachment #79512 - Flags: superreview+
Attachment #79512 - Flags: review+
Comment on attachment 79512 [details] [diff] [review]
Fix for problem

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.

Comment 8

17 years ago
I'm running 2002042008 but it still crash with the testcase.
04-21-2002  05:56:39  SYS3175  PID 0557  TID 0001  Slot 00b2
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:

Comment 9

17 years ago
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.

Comment 11

17 years ago
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 :)

Comment 13

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 15

17 years ago
Unfortunately, I get the crash on another page:
I'm using 2002050508 trunk build and crash 100% when to open the page.

Could someone recreate?
Resolution: WORKSFORME → ---

Comment 16

17 years ago
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.

Comment 17

17 years ago
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.

Comment 18

17 years ago
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?

Comment 20

17 years ago
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.

Comment 21

17 years ago
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.

Comment 22

17 years ago
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:

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.

Comment 23

17 years ago
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 

Comment 24

17 years ago
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.


Comment 27

17 years ago
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.

Comment 29

17 years ago
Okay, I will notify the workaround to Japanese Warpzilla lovers.
Thank you very much for your investigation.

Comment 30

17 years ago
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

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?

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]

Don't tell ANYONE I gave this to you :)

Please let me know if this new ASIACOL.DLL fixes the problem.
Last Resolved: 17 years ago17 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.

Comment 34

17 years ago
Thanks for the treasure :)
It never crash in all testcases mentioned here.

Comment 35

17 years ago
I also confirmed that Mozilla doesn't crash with new ASIACOL.DLL.

Comment 36

17 years ago
Mark bug as verified as per comments above.
*** 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.