132370 - Under Mac OS 8.6, a crash occurs during application startup

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Chris Petersen]

Build: 2002032008
Platform: Mac OS 8.6

Expected Results: Application should launch and open 
What I got: Shortly after splash screen appears, the application crashes

Steps to reproduce:

1) Install and run the application (in Mac OS 8.6)
2) Application crashes when during the display of the splash screen

Comment 1

[Chris Petersen]

Attachment: Macsbug stdlog file

Comment 2

[Kathleen :Brade]

I can't run a recent build; this is a blocker for me (and Chris Petersen).
I think this is due to changes made by dbaron (just a guess at this point).

Comment 3

[Kathleen :Brade]

oops... change of plans...
now that I've looked at checkins I see that ftang made changes recently

-->ftang

Comment 4

[Kathleen :Brade]

My guess (without spending a day pulling and building on 8.6) is that the
FMGetFontFamilyFromName is the problem.

Can we backout part of this fix or check Gestalt or ???

Comment 5

[Frank Tang]

we could #if TARGET_CARBON some code out.

Comment 6

[Frank Tang]

Attachment: #if TARGET_CARBON

Comment 7

[nhottanscp]

Comment on attachment 75313 [details] [diff] [review]
#if TARGET_CARBON

r=nhotta

Comment 8

[Simon Fraser [no longer active]]

It's better to do a TVector test:

#include <CodeFragments.h>

if ((UInt32)FMGetFontFamilyFromName != 
kUnresolvedCFragSymbolAddress) {
 ... code that calls FMGetFontFamilyFromName
}

We also noted that there are other non-protected calls to the Font 
Manager in other files, which also need the test.

Comment 9

[Simon Fraser [no longer active]]

Comment on attachment 75313 [details] [diff] [review]
#if TARGET_CARBON

Patch needs work

Comment 10

[Chris Petersen]

*** Bug 132368 has been marked as a duplicate of this bug. ***

Comment 11

[Chris Petersen]

*** Bug 132369 has been marked as a duplicate of this bug. ***

Comment 12

[Frank Tang]

Attachment: better fix, run time check. Also fix other similar issue

Comment 13

[nhottanscp]

Comment on attachment 75409 [details] [diff] [review]
better fix, run time check. Also fix other similar issue

r=nhotta

Comment 14

[Kathleen :Brade]

Do we care that we are initializing the same global but for different functions?
  in HasGlyphFor, we initialize gFMAPIAvailableInitialized for one set of
functions and then in nsDeviceContextMac.cpp, we init it based on only 2
functions (do we even know if those calls are the ones causing the crash?)

small nit: in nsDeviceContextMac.cpp, please remove the spaces/tabs from this
line/portion of the patch:
-        
+     

Comment 15

[Simon Fraser [no longer active]]

I think it's only necessary to do a T-Vector test for just one of the symbols,
not all of them. And, like brade, I'd prefer to see this done in one place,
rather than two (although the patch as is sets two separate private static
variables, not the same global as brade implies).

Put a static method somewhere called "FontManagerAvailable()" or something, and
call that.

Comment 16

[Frank Tang]

>I think it's only necessary to do a T-Vector test for just one of the symbols,
not all of them.

ok, if that is the case, which function should we test ?

> I'd prefer to see this done in one place, rather than two 
>Put a static method somewhere called "FontManagerAvailable()" or something, and
call that.
Where you want me to put it ?

Comment 17

[Simon Fraser [no longer active]]

Make a public static method in nsDeviceContextMac, like:

PRBool HaveFontManager90();

PRBool HaveFontManager90()
{
  return ((UInt32)FMGetFontFamilyName != kUnresolvedCFragSymbolAddress);
}

FMGetFontFamilyName should be OK to test.

Comment 18

[kinmoz]

So I'm going to ask the standard sheriff question ... If this bug was introduced
on the 15th, a bug just filed yesterday about it, and ftang is actively working
on it, do we really need it to be a smoketest tree blocker? Or can it be downgraded?

Comment 19

[Frank Tang]

Attachment: patch again

Comment 20

[Frank Tang]

>do we really need it to be a smoketest tree blocker? Or can it be downgraded?

does MacOS 8.6 need to smoke test for daily build? if so, then this should be
smoketest blocker untill got fix. If not, then maybe we can downgrade this one

Comment 21

[Kathleen :Brade]

Comment on attachment 75433 [details] [diff] [review]
patch again

r=brade (with whitespace cleanup discussed on aim)

Comment 22

[Simon Fraser [no longer active]]

Comment on attachment 75433 [details] [diff] [review]
patch again

sr=sfraser

Comment 23

[Frank Tang]

hope this will fix 122875 too.

Comment 24

[Frank Tang]

fixed and check in

Comment 25

[Chris Petersen]

Marking verified on the March 22nd build under Mac OS 8.6 (2002-03-22-08)