Closed Bug 234412 Opened 21 years ago Closed 21 years ago

SYS3178 in GKLAYOUT.DLL each time I open a specific page

Categories

(Core Graveyard :: GFX: OS/2, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: marcus, Assigned: mkaply)

References

(
URL
)

Details

(Keywords: crash, stackwanted)

Attachments

(1 file)

Check for divide by zero
775 bytes, patch
dbaron
: review+
mkaply
: superreview+
Details | Diff | Splinter Review 
User-Agent:       
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040117

Mozilla 1.6 (OS/2) crashes on the following URL:
http://banspam.javawoman.com/hiding1.html

Here is the log:

02-15-2004  14:55:05  SYS3178  PID 00f8  TID 0001  Slot 00d8
G:\MOZILLA\OS2\1.6\MOZILLA.EXE
c0000095
140e16a2
EAX=00c70e7f  EBX=0000000c  ECX=0013b6b4  EDX=00c62084
ESI=00c73324  EDI=0013b8c4  
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:140e16a2  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013b7d0  SSACC=f0f3  SSLIM=ffffffff
EBP=0013b80c  FLG=00002202

GKLAYOUT.DLL 0001:001116a2

I created a local copy of the page (Ctrl-E/Save as...) and the crash remained
the same :-(

Reproducible: Always
Steps to Reproduce:
1. Start Mozilla 1.6 (OS/2)
2. enter URL http://banspam.javawoman.com/hiding1.html


Actual Results:  
Crash in GKLAYOUT.DLL

Expected Results:  
Show the page

This is OS/2 specific, it does not occur in Windows. I disabled Innotek Font
Engine with the same results so it doesn't seem to be related to any font rendering.

I've a backup of the page on my local system. If Marjolein changes her page, I
can provide the original version.
I just switched profiles and the crash was no longer there. Is there anything in
my profile I can delete or rename to make the bug go away? I believe it's some
cached info (not the page cache, something internal).

can you check bug 232180 comment 3 ? Are you possibly sharing profiles (just an
idea, I'm don't know OS/2 much) ?
I don't run several browser versions at the same time, but I keep my profile
each time I upgrade the Mozilla version. I guess I have to delete XUL.mfl again,
but that's probably not enough.

WFM Mozilla OS/2 build 2004020908
I've tracked it down to the following user preference:

user_pref("font.minimum-size.x-western", 9);

Removing the pref cures the problem, adding it to a virgin profile makes Mozilla
crash on the page (only in OS/2, not in Windows).
Marking NEW since it has the pref which cause crash.
Assignee: general → mkaply
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX: OS/2
Ever confirmed: true
Keywords: crash, stackwanted
I don't see this crash even if the preference is set.
It seems to be related to my specific installation. Running Moz 1.6 (even with
font engine running) in a Virtual PC works fine. I'm going to reinstall Mozilla
on my main system (eCS 1.14) and will come back with the results.

O.K. it can be reproduced! 

Steps:

1) install eCS (German) in a Virtual PC (no VPC additions!)
2) install Mozilla 1.6
3) edit preferences: appearance->minimum font size: 9
4) go to the URL http://banspam.javawoman.com/hiding1.html

I tried it in the VPC setup as detailed above, but also on my eCS base
installation on my current machine with identical results. Can it be related to
the SDD drivers on eCS?

It really only fails on eCS?

Unlikely that it is our problem.
(In reply to comment #10)
> It really only fails on eCS?

I can reproduce it under eCS but not under one of my older OS/2 installations.
SDD is *not* the culprit as the crash occured in my VPC installation even after
I installed the Innotec VPC additions which bring a new video driver (still
gradd). My aim was to create an environment that can be reproduced by someone of
the team to track down the crash further than I could do.

Marcus
WFM in trunk and 1.6 with ft2lib 1.0.

Crash for me in trunk and 1.6 without ft2lib. Setting minimum from none to 9
while page is loaded also crashes.

This puzzling pair is from my single trunk crash:
02-17-2004  11:52:39  SYS3170  PID 0085  TID 0001  Slot 0094
H:\MOZILLA\BIN\MOZILLA.EXE
c0010001
1c03c4a1
EAX=00000001  EBX=00000000  ECX=02610000  EDX=00000000
ESI=00000000  EDI=00000000  
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:1d99014d  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013fd80  SSACC=f0f3  SSLIM=ffffffff
EBP=00000000  FLG=00012206

DOSCALL1.DLL 0003:0000c4a1

------------------------------------------------------------

02-17-2004  11:54:40  SYS3178  PID 0094  TID 0001  Slot 0094
H:\MOZILLA\BIN\MOZILLA.EXE
c0000095
1dd2ff22
EAX=013a0f7f  EBX=0000000c  ECX=0013abe8  EDX=00bfade4
ESI=013afeb4  EDI=0013add8  
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:1dd2ff22  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0013ace4  SSACC=f0f3  SSLIM=ffffffff
EBP=0013ad20  FLG=00002202

GKLAYOUT.DLL 0001:0010ff22
So basically all platforms except Os/2 appear to have floating point divide by
zero exceptions turned off.

Argh.

Fix here is to check for 0 before dividing by it.

Note I have verified on Windows that font->mSize is 0 in this case, but Windows
doesn't crash - lh ends up as 0 after the computation.
Comment on attachment 141665 [details] [diff] [review]
Check for divide by zero

dbaron, this is your code, could you take a look?
Thanks
Attachment #141665 - Flags: review?(dbaron)
Comment on attachment 141665 [details] [diff] [review]
Check for divide by zero

r=dbaron if you make the ==0 case do lh = minimumFontSize instead of lh = 0.
Attachment #141665 - Flags: review?(dbaron) → review+
> r=dbaron if you make the ==0 case do lh = minimumFontSize instead of lh = 0.

Will that produce correct results given that previous to my patch lh was ending
up 0 every time?
If it's ending up zero all the time then something related to the OS/2 font code
is severly broken and you probably shouldn't check this in.  Why is it zero all
the time?
Sorry, my point was that if you debug this case on Windows (where the divide by
zero happens), you will see that lh ends up as 0 (on Windows)

On Windows, dividing by zero results in zero.

The only OS/2 specific thing about this bug is that we crash because we don't
have divide by zero faults turned off in floating point.

If you create a new profile, go to the above page and then go to prefs and
change minimum font to 9, you will see that font->mSize is zero. As a matter of
fact, the font structure contains nothing at all.
I still think =minimumFontSize is probably the right thing to do.
Comment on attachment 141665 [details] [diff] [review]
Check for divide by zero

taking dbaron as sr.

Javier pedemonte looked at this one and r=
Attachment #141665 - Flags: superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: