125411 - (nubus) [NuBus] Mac installer crashes with a type 12 error (SleepQInstall)

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Simon Fraser [no longer active]]

We got a number of reports on the newsgroup of people getting crashes with the 
Mozilla 0.9.8 installer. Reports state that it crashes while installing xpcom.xpi 
with a type 12 error. I've been sent one macsbug log for the crash.

The users OS version is 9.0.4, machine is PowerMac7100_66, VM on. The crash is:
Undefined A-Trap at 05587F40. We don't have a good stack.

Comment 1

[Simon Fraser [no longer active]]

Attachment: stdlog for installer crash

Note that the A-trap in question is 0xA28A, which is _SleepQInstall. Beard?

Comment 2

[Simon Fraser [no longer active]]

This sounds related to bug 120451, which was fixed on the 0.9.8 branch.

SleepQInstall is in the PowerManager package, and should be present in System 
6.0.4 and later. Perhaps users seeing this have run an older, buggier version of 
Mozilla (with bug 120451) before running the installer?

Comment 3

[Simon Fraser [no longer active]]

User says:
   "Yes, it crashes after rebooting. I tried installing it with all previous
    Mozilla 0.9.7 files deleted, and also on top of an existing install of
    0.9.7. In bothes, the installer extracts the files and then crashes with a
    Type 12."

Comment 4

[Ken Watanabe]

I get this error as well.  The installer crashes (nicely) with a "Type 12 Error" 
immediately after the "Extracting Installer Files" is completed and the 
actual installation begins.  A new Mozilla Folder gets created but the only 
item inside is the Installation Log file (with no entries).  Before running the 
installer, I renamed the previous Mozilla Folder (did not delete it) which 
was for version 0.97.

My system is a PowerMac 8100 80/AV with a NewerTech G3 accelerator.  
VM is off, and it has 232MB of real RAM.  Mac OS is 9.1.  

I tried some things to try to get it to work:
* Restarting and trying again.
* Re-downloading the installer and trying again.
* Increasing the memory requirements of the installer (in the Get Info 
dialog).
* Rebooting with extensions off (which also disables my accelerator).  
This produced a crash at about the same place, but with a dialog that 
read "Installation failed due to error: -2804" instead of the previous Type 
12 Error message.

No luck...

I'd be happy to collect and send any other data about the crash, just let me 
know what to provide and how to get it (if it's not obvious to a mostly 
experienced Mac user).

- Ken, [e-mail]

Comment 5

[Hashimoto, Takehiro]

Bug #123961 is alike.
On 6100/66 + SonnetG3 accelerator, 72M RAM, VM is on, MacOS8.6.
I tried almost same to Mr.Watanabe.

Comment 6

[Simon Fraser [no longer active]]

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

Comment 7

[Daniel Veditz [:dveditz]]

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

Comment 8

[Daniel Veditz [:dveditz]]

bug 129998 has more details on the error.

Comment 9

[Simon Fraser [no longer active]]

Nothing that we don't know already. The crash happens when JS code tries to call
SleepQInstall, on a machine with an accelerator card. Same every time.

Comment 10

[Daniel Finegan]

not corrected in 0.9.9.

Comment 11

[Simon Fraser [no longer active]]

Giving to beard, since the SleepQInstall call is his.

Comment 12

[Ken Watanabe]

I have some more observations regarding this issue.  I confirm Daniel 
Finegan's comment that the installer for version 0.99 has this same 
problem as 0.98.

Also, I don't know about "JS code calling SleepQInstall" but Simon 
Fraser's other point that it happens on "a machine with an accelerator 
card" may not be accurate.  I disabled my G3 accelerator (NewerTech 
model in a PM 8100) by disabling the accelerator's system extension.  
Without the extension, the 8100 does not see the accelerator and runs as 
a standard 8100.  I ran the installer in this mode a received the same 
"Type 12" error.  Based on posts I have read here and on other forums, 
the problem seems to related to running the installer on a Nubus-based 
PowerMac (such as the 8100, 7100, 6100), with or without accelerators 
involved.

Additionally, I have access to a PowerBook 2000, so I ran the same 
installer on that machine.  Mozilla installed and ran great.  I noted that the 
installer did not install any Mozilla-specific extensions into the System 
Folder.  I then copied the newly installed Mozilla Folder from the 
PowerBook 2000 to my 8100 over a network connection.  I tried to run 
Mozilla from my 8100 and received the "Type 12" error, this time from 
running Mozilla itself.  So unless there is a technical reason that I cannot 
copy the Mozilla Folder from one Mac to another and run it, the same 
issue may also exist in the Mozilla application itself.

The last version that worked for me was 0.97.  Perhaps there is 
something different about the build process that has made later versions 
of Mozilla-related apps incompatible with older Nubus PowerMacs.

Comment 13

[Patrick C. Beard]

Checking to see if 0.9.9 installer has same problem.

Comment 14

[Simon Fraser [no longer active]]

Ah, Nubus. That's it. SleepQInstall is in Driver Services Lib, which may not be
present. Patrick, you're going to need a Gestalt test.

Comment 15

[Patrick Tufts]

Occurs with Moz 0.9.9 on MacOS 9.0.4 PowerMac 7100/66 with Sonnet PowerPC G3 
upgrade (PPC enabler 9.0.4).

Installation goes to near-completion with Type 12 error. Application folder 
contains only an empty installer log.

--Pat

Comment 16

[Patrick C. Beard]

Or perhaps just test to see if the routine descriptor isn't NULL, right,
assuming it's weak linked in?

Comment 17

[Simon Fraser [no longer active]]

Right. I think with Pro 7, everything is weak linked, or something.

Comment 18

[mhsu1]

This is my first time using Bugzilla so excuse me if I'm doing anything 
improperly.  But I wanted to make it known that I've been having problems with 
Type 12 errors on my Power Macintosh 7100 (upgraded to G3/260) in the middle of 
the Mozilla 0.9.9 INSTALLER (any of the recent mid-March builds).  In addition 
if I install Mozilla on a different computer and copy the installed folder to my 
computer, the Mozilla APPLICATION will also succumb to Type 12 errors.

I'm wondering if this problem is due to a problem of NuBus computers since the 
same problematic Mozilla builds work great on my PCI-based Power Mac 8500 and 
iMacs.  Also I notice that the Macsbug stdlog attached to bug #125411 was taken 
from a PowerMac 7100.

Comment 19

[Patrick C. Beard]

Attachment: patch check for existence of SleepQInstall, v1

This should prevent the crash, but on those pre-PCI Macs, we probably won't be
able to have the JS clock be drift free after sleeping.

Comment 20

[Daniel Finegan]

beard, does this mean the latest build will install for those of us who have 
been having this problem?

Comment 21

[Patrick C. Beard]

This patch has yet to be reviewed, super-reviewed, nor approved for check-in.
Only after it's been checked in will it appear in a nightly Mozilla build.

Comment 22

[Simon Fraser [no longer active]]

I'd prefer to see ((UInt32)SleepQInstall != kUnresolvedCFragSymbolAddress) so
that a glance at your code tells me what you are trying to do.

Comment 23

[Patrick C. Beard]

I knew you would... just makes the line too wide for my taste.

Comment 24

[Patrick C. Beard]

Attachment: patch to check for existence of SleepQInstall, v2

Addressing nits.

Comment 25

[Simon Fraser [no longer active]]

Comment on attachment 75308 [details] [diff] [review]
patch to check for existence of SleepQInstall, v2

sr=sfraser

Comment 26

[Patrick C. Beard]

Steve, can I get a review please?

Comment 27

[Steve Dagley]

Comment on attachment 75308 [details] [diff] [review]
patch to check for existence of SleepQInstall, v2

r=sdagley

Comment 28

[Asa Dotzler [:asa]]

Comment on attachment 75308 [details] [diff] [review]
patch to check for existence of SleepQInstall, v2

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 29

[Patrick C. Beard]

Fix landed on trunk.

Comment 30

[Grace Bush]

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

Comment 31

[K'Trina Medina]

Verified code fix

Comment 32

[Hashimoto, Takehiro]

Please ReOpen, mozilla1.0rc1 's installer still crush.

Comment 33

[timeless]

I'm going to reopen on the principal that the QA messed up, namely: this is 
*not* an untestable codefix. All you need is a NuBus powermac (i have two, 
and once I get my 6100 happy I'd actually be willing to ship it to CA for QA 
to use).

Anyways, enough about principals, let's talk about code
http://developer.apple.com/technotes/tn/tn1083.html
    return ((Ptr) EnterMovies != (Ptr)kUnresolvedCFragSymbolAddress);
attachment 75308 [details] [diff] [review]
           if (&SleepQInstall != (void*)kUnresolvedCFragSymbolAddress) {
The |&| worries me.

In the interim, since I have Macs which have this problem, I'm taking QA. If 
a NSCP QA can find a NuBus mac and would like to take QA, please feel free.

jj: would it be possible to spin an installer with that |&| removed to see if 
this crash goes away? (fwiw, I filed bug 138156 and bug 137470, which are all 
the same problem)

Comment 34

[Conrad Carlen (not reading bugmail)]

It won't. The '&' operator on a function is a no-op. Here's the disasm:

static Boolean HasSleepQInstall()
{
    return (SleepQInstall != (void*)kUnresolvedCFragSymbolAddress);
00000000: 80820000  lwz        r4,SleepQInstall(RTOC)
00000004: 38000000  li         r0,0
00000008: 7C640050  subf       r3,r4,r0
0000000C: 7C002050  subf       r0,r0,r4
00000010: 7C600378  or         r0,r3,r0
00000014: 54000FFE  srwi       r0,r0,31
00000018: 5403063E  clrlwi     r3,r0,24
0000001C: 4E800020  blr

and 

static Boolean HasSleepQInstall()
{
    return (&SleepQInstall != (void*)kUnresolvedCFragSymbolAddress);
00000000: 80820000  lwz        r4,SleepQInstall(RTOC)
00000004: 38000000  li         r0,0
00000008: 7C640050  subf       r3,r4,r0
0000000C: 7C002050  subf       r0,r0,r4
00000010: 7C600378  or         r0,r3,r0
00000014: 54000FFE  srwi       r0,r0,31
00000018: 5403063E  clrlwi     r3,r0,24
0000001C: 4E800020  blr

Comment 35

[Kathleen :Brade]

is this still a problem (with builds from today)?

Comment 36

[timeless]

yes :)

Comment 37

[J.J. Enser]

how are we supposed to address this if the latest patch didn't fix it?

timeless, since you seem to have reported most bugs related to this issue, can
you create dependencies between them (137470, 138156) for easier tracking?

As to QA testing with NuBus Macs, timeless doesn't need to ship his, I have 4+
retired 9500/9600 under my desk I never use (other than to step on to look over
my cube's walls :-)
K'Trina, I'll be happy to bring you one upstairs if you want me to.

Comment 38

[chado]

jj: 9500/9600 are not NuBus-based, but PCI-based.  
So, they do not reproduce this.  

Comment 39

[J.J. Enser]

Oops... don't know what I was thinking, besides trying to help getting this
issue resolved. I guess I just missed a good opportunity to shut up :-/

Comment 40

[Daniel Veditz [:dveditz]]

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

Comment 41

[Ken Watanabe]

Incidentally, the Netscape 7 "PR1" release, that came out today, appears 
to have inherited this bug now.  I downloaded and tried it and got the 
crash with Type 12 error during installation.  The previous release, version 
6.2.3, installed and ran fine.  As I noted before, the last version of Mozilla 
that worked on my G3-upgraded Nubus PowerMac (8100) was 0.98.  The 
newest Netscape must be based on a version after that release.

- Ken Watanabe

Comment 42

[Jeff Leigh]

I don't know why no one else has mentioned this, but you can install and use
Mozilla on a NuBus Mac as long as you have MacsBug installed. You will get a
bunch of undefined A-Traps, but hitting 'g' will allow the install to continue
and the app to launch when it is done. Not a very pretty solution, but all we
can do until the code fix is put in.

Comment 43

[Jeff Leigh]

Here are the errors that MacsBug reports:

Installer:

Undefined A-Trap at 06368C90
Undefined A-Trap at 08219CA0
(the installer crashed completely the first time, second install attempt is below)
Undefined A-Trap at 06368C70
Undefined A-Trap at 08219CA0

Mozilla:

Undefined A-Trap at 06B29140
Undefined A-Trap at 08219CA0
(one error when launched, one error when it is quit)

Comment 44

[Jeff Leigh]

Attachment: Disassembly of the four undefined A-traps

Comment 45

[Ken Watanabe]

Thank you, Jeff Leigh, for the tip on using MacsBug.  I was able to install 
and run Netscape 7.0 PR1, so I assume I would be able to do the same 
with the latest Mozilla.  As Jeff has already noted, Netscape does drop into 
the debugger once during launch and once during quit, but it ran perfectly 
in between.  I'm wondering if there needs to be a separate bug report for 
this problem with the Mozilla application itself, since this bug report is 
about the installer problem.

Comment 46

[timeless]

one bug is quite enough, but if you need more you can follow the unstricken 
bug links and use one of them. note that there are standard logs attached to 
some of the other referenced bugs.

Comment 47

[timeless]

Attachment: Patch take 2

Comment 48

[timeless]

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

Comment 49

[timeless]

Comment on attachment 85827 [details] [diff] [review]
Patch take 2

this won't work at all for CFM builds. but we kind of knew that.

What we don't know, and what I should find out is whether this is actually an
issue for CFM builds.

Comment 50

[Hashimoto, Takehiro]

May I add "143454" to "blocks"?

Comment 51

[Marco Moreno]

Please excuse my ignorance as I'm not a mac developer and very new to 
Bugzilla.  I installed and used Macsbug as described here and have 
experienced behavior identical to what others have described.

However, I also encountered another SleepQInstall error that has NOT 
been mentioned here: "Get new mail"  This happens when the button is 
clicked or when selected via File menu.

Will the patch covered by this bug report also fix this mail bug?  Or should 
it  be addressed as a separate bug?

I'd be happy to provide additional info or do more testing.

-Marco

Comment 52

[Curt Jacobs]

Build 2002062109 correctly installed then opened without needing intervention
from MacBugs. Browser functions properly after opening, and correctly imported
profile. Browser shuts down without calling MacBugs. 

Comment 53

[timeless]

Attachment: we need to include Traps.h to actually build, and none of this stuff is for carbon

ok, the test builds are based on the patch i've just attached.

they didn't have the #ifndef bit, but that's ok because they were built w/o the
define.

Comment 54

[Patrick C. Beard]

Comment on attachment 88949 [details] [diff] [review]
we need to include Traps.h to actually build, and none of this stuff is for carbon

sr=beard

Comment 55

[Simon Fraser [no longer active]]

Comment on attachment 88949 [details] [diff] [review]
we need to include Traps.h to actually build, and none of this stuff is for carbon

r=sfraser

Comment 56

[timeless]

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

Comment 57

[timeless]

checked in
i'll send mail to drivers asking about the branch

Comment 58

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 59

[timeless]

fixed on 
branch, 
reopening 
bug 112626 
Comment 
41 From 
Phil 
Schwartau

Comment 60

[timeless]

whoops, 
there was 
supposed 
to be a 'per' 
somewhere
. it's kind of 
hard to type 
in a 0x0 
edit box.

Comment 61

[Phil Schwartau]

timeless: thanks! 

Now that the patch is in both trunk and branch, we would now
normally mark this bug Fixed. Want to do that? Then I can 
verify the patch on both trunk and branch and mark it Verified -

Comment 62

[timeless]

sorry for all the confusion, this is fixed on trunk and 1.0 branch, i guess 
js1.5 doesn't have a branch.

Comment 63

[Phil Schwartau]

I need help on this: could someone with a NuBus powermac verify this
for me and mark the bug "Verified" if the bug is now fixed?

Thank you -

Comment 64

[Ken Watanabe]

Would the change be in the latest Nightly Build?  Must be some other 
build (or I took it too soon) because I just downloaded the Nightly Build 
and ran the installer.  Same problem ("unexpectedly quit with Type 12 
error") at the same point during the install process, right after "extracting 
files..." is displayed.

My system is a Nubus PowerMac 8100/80 with a NewerTech 300 MHz G3, 
running Mac OS 9.1.

Comment 65

[Ken Watanabe]

timeless pointed me to a download that had the fix (the nightly build I used
earlier, which still had the problem, was downloaded at about 6:00am-Pacific).

This build (labeled 2002-06-21-11-TEST125411) worked great.  I was able to run
the "typical" install without any problems.  After installing, I started
Mozilla.  I ran it for about 30 minutes doing things I normally do.  I do not
use the email module, but someone mentioned the problem existed there, so I at
least ran the mail module.  I quit Mozilla.  All that without any problems.  

I have restarted Mozilla now and I have marked the bug as VERIFIED per request
from Phil Schwartau.  Thank you!

[OOPS - The system won't let me change status to VERIFIED so I'll leave it as
RESOLVED FIXED.]

Comment 66

[Phil Schwartau]

Ken: thank you very much! Marking Verified Fixed -

Comment 67

[Phil Schwartau]

Adding verified1.0.1 keyword -

Comment 68

[Jeff Leigh]

Does anyone know why this still isn't in the nightly builds? Just checked the 7/6 builds and they still crash in the same spot.

Comment 69

[Phil Schwartau]

Reopening bug based on Jeff's report -

AFAICT, the fix should be in the nightlies, since timeless'
patch is in both the trunk and MOZILLA_1_0_BRANCH in CVS.

Jeff, can you say exactly which builds you downloaded?
(i.e. were they trunk or branch?)

Comment 70

[Jeff Leigh]

Bug test was in build 2002070608 for Mac OS 8.x/9.x. The download is listed as mozilla-mac-trunk-full.bin on the ftp site.

Comment 71

[chado]

timeless : 
You should not delete this issue from Release Notes for 1.1 alpha.  
Those release builds have gone, already.  

I have tried: 
 2002-06-26-08-trunk, 
 2002-06-28-03-trunk, 
 2002-07-04-08-trunk and 
 2002-07-05-08-trunk 
on G3-upgraded 8100.  Then, seeing Type 12 error.  Only the 
2002-06-21-11-TEST125411 was fine.  

Seeing lxr, the patch attached 2002-06-24 has been applied (time stamp is Jun 25 20:01).
But this patch looks to act for us on non-carbon build only (as mentioned in 
comment#53).
Isn't there possibility for that current build system can build only carbon builds ?
If so, regular builds do not answer for us, except for who can build non-carbon 
builds by themselves.

FYI: timeless opened new META bug for carbon build : bug 153391 - 
    "i'd like to run Carbon Mozilla on my NuBus PowerMac 7100/66 (9.0.4)"

Comment 72

[timeless]

Attachment: check for TARGET_CARBON=0 instead of defined

whoops, TARGET_CARBON is always defined, it's just 0 when we want to do this
work.

Comment 73

[Johnny Stenback (:jst)]

Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

sr=jst

Comment 74

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

r=dmose

Comment 75

[timeless]

ok, this code should actually be active in the next available trunk nightly build.

Comment 76

[Phil Schwartau]

timeless: this latest patch has not been checked into the 1.0 branch.
Do you want to have it there, as with the previous patch?

As before, I will need someone with a NuBus Mac to verify this fix
for me. Could someone try an up-to-date trunk build and see if the
problem has gone away?

Thanks -

Comment 77

[Ken Watanabe]

OK, downloading the latest Nightly Build... (16 minutes later)

Running installer with fingers crossed... Excellent!  It installed just fine, 
and Mozilla itself is up and running very well.  FYI - The installer package 
(the downloaded archive) has date/time of 7/8/02 at 1:06PM (created).  
The Mozilla build is ID'ed as 2002070810.

Thanks for giving users of "ancient and obsolete" Macs a chance to try the 
"latest and greatest."  I'll let others with similar hardware know about it.

Comment 78

[Jeff Leigh]

Patch verified on build 2002070810 using a 7100 w/G3 upgrade running OS 9.1.

Comment 79

[timeless]

email sent to drivers :-)

Comment 80

[tor]

Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

a=tor

Comment 81

[Phil Schwartau]

Adding the verified1.0.1 keyword, since the fix is now in
the MOZILLA_1_0_BRANCH as well as in the trunk in CVS.

Furthermore, Ken and Jeff have verified above that this patch
fixes the bug. Marking Verified Fixed. Thanks to all!

Comment 82

[Greg K.]

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

Comment 83

[Greg K.]

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

Comment 84

[Greg K.]

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