Closed Bug 125411 (nubus) Opened 18 years ago Closed 18 years ago

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

Categories

(Core :: JavaScript Engine, defect, blocker)

PowerPC
Mac System 9.x
defect
Not set
blocker

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: timeless)

References

Details

(Keywords: crash, platform-parity)

Attachments

(2 files, 5 obsolete files)

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.
Attached file stdlog for installer crash (obsolete) —
Note that the A-trap in question is 0xA28A, which is _SleepQInstall. Beard?
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?
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."
QA Contact: bugzilla → ktrina
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, kenichi5@mac.com
Keywords: nsbeta1
Keywords: crash, pp
Bug #123961 is alike.
On 6100/66 + SonnetG3 accelerator, 72M RAM, VM is on, MacOS8.6.
I tried almost same to Mr.Watanabe.
*** Bug 123961 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1nsbeta1+
*** Bug 129998 has been marked as a duplicate of this bug. ***
bug 129998 has more details on the error.
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.
not corrected in 0.9.9.
Giving to beard, since the SleepQInstall call is his.
Assignee: syd → beard
Summary: Mac installer crashes with a type 12 error → Mac installer crashes with a type 12 error (SleepQInstall)
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.
Checking to see if 0.9.9 installer has same problem.
Status: NEW → ASSIGNED
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.
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
Or perhaps just test to see if the routine descriptor isn't NULL, right,
assuming it's weak linked in?
Right. I think with Pro 7, everything is weak linked, or something.
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.
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.
beard, does this mean the latest build will install for those of us who have 
been having this problem?
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.
I'd prefer to see ((UInt32)SleepQInstall != kUnresolvedCFragSymbolAddress) so
that a glance at your code tells me what you are trying to do.
I knew you would... just makes the line too wide for my taste.
Addressing nits.
Attachment #75188 - Attachment is obsolete: true
Comment on attachment 75308 [details] [diff] [review]
patch to check for existence of SleepQInstall, v2

sr=sfraser
Attachment #75308 - Flags: superreview+
Steve, can I get a review please?
Comment on attachment 75308 [details] [diff] [review]
patch to check for existence of SleepQInstall, v2

r=sdagley
Attachment #75308 - Flags: review+
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
Attachment #75308 - Flags: approval+
Fix landed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 126827 has been marked as a duplicate of this bug. ***
Verified code fix
Status: RESOLVED → VERIFIED
Please ReOpen, mozilla1.0rc1 's installer still crush.
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)
Status: VERIFIED → REOPENED
Keywords: mozilla1.0
QA Contact: ktrina → timeless
Resolution: FIXED → ---
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
is this still a problem (with builds from today)?
yes :)
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.
jj: 9500/9600 are not NuBus-based, but PCI-based.  
So, they do not reproduce this.  
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 :-/
*** Bug 141257 has been marked as a duplicate of this bug. ***
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
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.
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)
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.
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.
Attached patch Patch take 2 (obsolete) — Splinter Review
Attachment #69407 - Attachment is obsolete: true
Attachment #75308 - Attachment is obsolete: true
Attachment #84854 - Attachment is obsolete: true
Summary: Mac installer crashes with a type 12 error (SleepQInstall) → [NuBus] Mac installer crashes with a type 12 error (SleepQInstall)
*** Bug 137470 has been marked as a duplicate of this bug. ***
Blocks: 138156
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.
Attachment #85827 - Flags: needs-work+
May I add "143454" to "blocks"?
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
Whiteboard: please test build from url field, email success and failure stories to the QA contact
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. 
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.
Attachment #85827 - Attachment is obsolete: true
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
Attachment #88949 - Flags: superreview+
Alias: nubus
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
Attachment #88949 - Flags: review+
No longer blocks: 138156
*** Bug 138156 has been marked as a duplicate of this bug. ***
checked in
i'll send mail to drivers asking about the branch
Severity: normal → blocker
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Keywords: mozilla1.0mozilla1.0.1
Resolution: --- → FIXED
Whiteboard: please test build from url field, email success and failure stories to the QA contact
Component: Installer → JavaScript Engine
Attachment #88949 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Blocks: 149801
fixed on 
branch, 
reopening 
bug 112626 
Comment 
41 From 
Phil 
Schwartau
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
whoops, 
there was 
supposed 
to be a 'per' 
somewhere
. it's kind of 
hard to type 
in a 0x0 
edit box.
Assignee: beard → timeless
Status: REOPENED → NEW
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 -
sorry for all the confusion, this is fixed on trunk and 1.0 branch, i guess 
js1.5 doesn't have a branch.
Status: NEW → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
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 -
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.
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.]
Ken: thank you very much! Marking Verified Fixed -
Status: RESOLVED → VERIFIED
Adding verified1.0.1 keyword -
Keywords: verified1.0.1
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.
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?)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
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)"
whoops, TARGET_CARBON is always defined, it's just 0 when we want to do this
work.
Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

sr=jst
Attachment #90464 - Flags: superreview+
Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

r=dmose
Attachment #90464 - Flags: review+
ok, this code should actually be active in the next available trunk nightly build.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
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 -
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.
Patch verified on build 2002070810 using a 7100 w/G3 upgrade running OS 9.1.
email sent to drivers :-)
Keywords: mozilla1.0.1
Comment on attachment 90464 [details] [diff] [review]
check for TARGET_CARBON=0 instead of defined

a=tor
Attachment #90464 - Flags: approval+
Keywords: mozilla1.0.1fixed1.0.1
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!
Status: RESOLVED → VERIFIED
Keywords: verified1.0.1
Blocks: CarbonNubus
*** Bug 153233 has been marked as a duplicate of this bug. ***
*** Bug 154067 has been marked as a duplicate of this bug. ***
*** Bug 154326 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.