Closed Bug 36928 Opened 24 years ago Closed 24 years ago

Mozilla opens infinite minimal windows on startup

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: mpt, Assigned: mpt)

Details

(Keywords: crash, Whiteboard: [dogfood-][nsbeta2+]unable to reproduce.)

Attachments

(4 files)

"Mozilla Registry" file at the time of the alleged incident
1.13 KB, application/octet-stream
Details
Apple System Profiler report
32.00 KB, text/plain
Details
StdLog from MacsBugApp (probably not very useful)
35.39 KB, text/plain
Details
StdLog from MacsBug (considerably more useful than the previous one)
24.63 KB, text/plain
Details 
Build: 2000-02-23 nightly build, Win98

To reproduce:
* Start Mozilla in an environment where there are no current Mozilla profiles,
  but a number of 4.x profiles. (This might happen in other environments, but
  the situation I describe is the only one I have to test with.)

What should happen:
* The select profile dialog should appear.

What actually happens:
* Mozilla begins opening an infinite number of minimal windows -- ones with an
  empty title, an icon, and the standard windowing widgets, but no content.
* If Mozilla is not End-Tasked within a few seconds of this starting to happen,
  Windows crashes so hard that even Ctrl+Alt+Del doesn't do anything.

This has probably already been reported, but none of the current browser blocker 
bugs look similar.

This also happened with a nightly build which was a couple of days old, but it 
only the second time I started Mozilla -- the first time it ran fine. I deleted 
all Mozilla-related files (including mozregistry.dat) before installing the new 
build.
Keywords: crash
Ok, the bad news:

(1) Someone on #mozilla tried using exactly the same Windows nightly build I did,
    also on Win98, and did not have the same problem. Meanwhile, I deleted
    mozilla/, mozregistry.dat, and mozver.dat, and reinstalled Mozilla, and still
    had the problem. I tried mozilla -console, and it showed nothing unusual --
    up to the point where it started going WEBSHELL += 1, WEBSHELL += 2, WEBSHELL
    += 3, WEBSHELL += 4 ...

(2) I'm back at university, and won't have access to a Windows box for testing
    Mozilla for another six months or so.

So this might end up being resolved worksforme.

On 20000428 it gets to WEBSHELL+ = 5, and then gives a "<start page> loaded 
successfully" message for me. Only one window.

Gerv
Ive seen this happen on macintosh. Same circumstances. when I blew away my 
profile and mozregistry.dat everything cleared up.

Resolving this WORKSFORME  mpt, please reopen if you get back in front of a 
machine that displays this behavior.  Thanks
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
It's back, this time on Mac. May 27th nightly build, Mac OS 8.6.

Newly-created profile, newly-created Mozilla Registry file. Start Mozilla. Lots 
of tiny little windows start opening in the top left corner of the screen ... and 
if you don't force-quit Mozilla within about ten seconds, the Mac goes belly-up.
Status: RESOLVED → REOPENED
OS: Windows 98 → All
Hardware: PC → All
Resolution: WORKSFORME → ---
over to XPToolkit for a look.
Assignee: asadotzler → trudelle
Status: REOPENED → NEW
Component: Browser-General → XP Toolkit/Widgets
QA Contact: jelwell → jrgm
I can't repro, using 53108 verif. build on Mac OS 8.6.  John, these steps sound
like a typical scenario for QA, have you ever seen this?
Whiteboard: unable to reproduce.
This is a typical scenario for me, and anyone testing regularly. I haven't seen 
this and I checked with claudius(8.5.1) and shrir (9.0) and it's unknown to 
them. Any better luck with today's build Matthew.

Sounds like we'll need to know more details about the configuration of the
machine's software - how is it different from the machines we have here?
Matthew, could this be related to bug 27601 (or one of its frequent dups)?
The problem there was a missing system library needed by gecko.
I can't explain the Mac, however...

Symptoms & fix, from bug 27601 (sometimes MSVCRT.DLL seems to be needed, too):

------- Additional Comments From fisher7@thegrid.net 2000-03-04 23:56 -------

[...] it started spawning multiple copies of itself and sucking up system
resources until 95 crashed.  

------- Additional Comments From fisher7@thegrid.net 2000-03-18 16:41 -------

[...] Find msvcirt.dll on the net (here is a copy
http://www.winappz.com/msvcirt.zip), and put it in your
c:\windows\system directory. Then mozilla loads up perfectly!

Sorry for the delay, I've had the flu.

Reproduced with June 1 nightly build. System info:
* Power Macintosh 7300/180, 48 Mb
* Mac OS 8.6
* hard disk had been completely rewritten since Mozilla was last installed (i.e.
  no legacy Mozilla Registry or profile files lying around)

What else do you want to know?
OS: All → Mac System 8.6
Hardware: All → Macintosh
I'd wonder at the fact that the computer is not a G3, but that wouldn't explain 
why it wouldn't have worked on your Win98 box at the university, Matthew.

All the same, could anyone report if they've tried it on another non-G3+ box?
The Win98 box is the home computer ... the Macs are at the university, which 
isn't well-funded enough to afford G3s. :-)

Dogfood. I don't mean to be a nuisance, but while this bug is hanging around I 
can't do any meaningful QA work. Will try again with a newer nightly build in a 
day or two.
Keywords: dogfood
I tried this on a non-G3/G4 machine -- a 9500/132 PowerPC 604, w 64MB RAM, os
8.6 US -- after deleting all the mozilla profiles, and the Mozilla Registry,
using 2000060209 mozilla build: I cannot reproduce this problem on that
machine.

Matthew, could you possibly get a copy of MacsBugs
  http://developer.apple.com/tools/debuggers/MacsBug/index.html and install
it on your Mac.

After you reboot, try running Mozilla and when it gets into the 'multiple
windows launching' hit 'cmd-power' to break into the debugger. Then enter
'stdlog somefilename' in the debugger command-line.  Finally, enter 'sc' to
get a stack crawl of what mozilla is doing at this time. Then attach that
output to this bug report.

[If 'sc' doesn't produce anything usable, try rebooting and restarting
mozilla and breaking into the debugger again to see if you can catch it in
the act.].
Uh, sorry, forgot. To get out of the debugger, enter 'es'. The stuff
that was dumped to the screen, will be captured in a file call 'somefilename'
that will be on your desktop (via the 'stdlog' command).
mpt, have you move your profiles outside.  Can you at least install a clean
daily build on Mac.
Whiteboard: unable to reproduce. → [NEED INFO]unable to reproduce.
Matthew, do you have any other software running at the same time (drivers,
inits, apps)?  If you can't reproduce this on a vanilla machine, please attach a
copy of your system profile, using Apple System Profiler, or some such utility.

[wastes NZ$5.60 ...]

Just downloaded
<ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-mac-M16.sea.bin>, and 
discovered that for some reason it is the *May 27* nightly build. (It worked 
fine, by the way).

[goes back to komodo to try and find a more recent build ...]

Rats. Installing MacsBug requires that I can fiddle with the System Folder from 
the Finder, and I can't. `You cannot move "MacsBug" to the folder "System 
Folder", because you do not have the privilege to make changes.'

Anyway ... Bug reproduced with June 04 nightly build, on a Mac which I'm sure has 
never had Mozilla on it before (because it's not one I've used before). I'm about 
to attach a complete System Profiler report.

Something else which may be useful: when I open the Mozilla "Profile Manager" 
document (rather than the "Mozilla" app itself), I get one minimal window in the 
center of the screen (presumably a defective Profile Manager window), and *then* 
infinite minimal windows in the upper left as usual.

So, does this imply that you were unable to reproduce this with only the Apple 
System extensions enabled?  IIRC, you can always choose these as a locked set 
in Extensions Manager.  BTW, how is it that you cannot move Macsbug to the 
system folder.  Doing so is not necessary, but not being able to do so may be 
significant.
The reason I can't (a) mess with the System Folder, or (b) change the extension 
set used, is because MacPrefect is installed. (These are university machines, 
remember.)

Applications other than the Finder -- the Mozilla Installer, for example -- can 
stick files in the System Folder with no problem; this is presumably an exception 
in MacPrefect's coverage in order to allow ordinary applications (which
read/write System Folder files) to work.

If moving MacsBug to the System Folder is not necessary in order to use it (the 
installation instructions tell me it is necessary), then please describe the 
alternative method.

I didn't mean that it could be used outside of the system folder, although 
there used to be a version of it as an app that you might be able to find and 
run.  I wonder if this bug is an incompatibility with MacPrefect, or one of the 
other pieces of software that you are stuck with.  Can you invoke Extensions 
Manager at startup, and temporarily boot without all this junk?
Just out of interest, how possible is it for you to ask your university's
computer staff to let you have privileged access for the purpose of testing
Mozilla? I have found university staff here are very interested in helping
when you ask them for rights for doing something with free software projects.

Ok, I managed to get MacsBugApp to compose a StdLog file while Mozilla was 
plopping merrily away with new windows. Only trouble is, of course, when I type 
`stdlog' the current app reported by the log isn't Mozilla, but MacsBugApp 
itself. I tried entering "atb WaitNextEvent 911^ = 'MOZZ'" (without quotes) in 
MacsBugApp before running Mozilla, but it didn't seem to help.

And as soon as the stdlog finishes, MacsBugApp freezes so I can't type "sc" 
anyway.

Ian: they'd laugh. They wouldn't even let me have NNTP access to news.mozilla.org 
when I asked for that.

Matthew: Ah. :-( Well, if you want to do a year here at Bath University, I'm 
sure you would manage to get in... ;-)

Just on the off-chance that it's a problem with StuffIt ... Can someone for whom
<ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-06-04-20-M16/mozilla-mac-
M16.sea.bin> works fine please download it, unpack it, and then -- *without* 
running Mozilla first --  select the `mozilla-mac-m16' folder, and choose Get 
Info?

I get `103.1 MB on disk (24,399,141 bytes), for 1480 items'. Is that all as it 
should be? (Apart from the obvious fact that 103.1 Mb is far, far too large for 
the number of features being provided ...)

(Ian: Not with my mediocre CompSci grades, I couldn't.)

Ok, just spent a while learning more than I ever wanted to know about Mac OS 
extensions ... But starting Mozilla with just the `Mac OS 8.6 Base' set of 
extensions enabled still gives the bug. I didn't think it would make any 
difference -- after all, Mozilla is always actually starting up, which probably 
wouldn't be the case if an extension conflict was the problem.

Tomorrow (in about 21 hours), now that I can disable the MacPrefect extension (I 
think), I'll install MacsBug proper and see if I can get a decent log and stack 
crawl as requested.

For <ftp://ftp.mozilla.org/pub/mozilla/nightly/ 
                2000-06-04-20-M16/mozilla-mac-M16.sea.bin> 
I get:
  `33.7 MB on disk (25,478,823 bytes), for 1680 items'
You got: 
 `103.1 MB on disk (24,399,141 bytes), for 1480 items'

Gee, that might be a problem ...
MPT: note that >78MB of the 103MB is the waste due to your disks allocation 
unit. Also, init/app conflicts are frequently much more subtle than just 
crashing on startup. As to the Stuffit diffs, I'm very surprised. Are you using 
Deluxe or Expander, or what, and what version?
per PDT request, I have tried the same builds on the same OS and CPU 
combination. This is specific to Matthew's configuration and we are trying
to resolve what the problem is. 

Matthew: any more news on this bug, in particular, the discrepancy in the 
un-stuffed size and filecount? Thanks.
Whiteboard: [NEED INFO]unable to reproduce. → unable to reproduce.
Ok, that StdLog should be more helpful, as it's done using MacsBug proper with 
Mozilla as the current app (while Mozilla was popping up lotsa little windahs).

Peter: I'm using StuffIt Expander version 5.1 (5.1 was recently installed on 
these machines, but this bug was also happening with a previous version of 
Expander). Expander didn't report any errors in the extraction -- I just tried it 
again, and it ...

Whoo, hang on a second.

Ok, MacsBug just popped up and told me that StuffIt Expander got a bus error. 
This was about 3/4 of the way through the expansion of mozilla-mac-M16.sea. When 
I typed 'es', Expander carried on extracting as if nothing had happened, and 
didn't report any errors. Hmmm.

So it looks like we might have two bugs here. The first would be that there's 
something wrong with Expander (both this version and the previously installed 
version), or that it's Expander which is having the system conflict (and not 
Mozilla). And the second would be that Mozilla needs to be a *lot*
better-behaved, when coming across missing/corrupt files, than it is now.

The next step on your side, I guess, is to tell me what the Mac OS equivalent of 
typing "ls -laR" is; so I can attach a complete directory listing of the
mozilla-mac-m16 folder, jrgm can do the same, and a diff can be run to see what's 
missing. (No, expanding all the folders by hand in Finder's list view and then 
typing Ctrl+A Ctrl+C won't work -- it doesn't copy the contents of the 
subfolders.)

And the next step on my side is to try with a new nightly build on Mac OS 9 
(which was just installed yesterday on most of the university Macs), and see if 
the bug still happens.

curiouser and curiouser!  Could Stuffit Expander be spawning off multiple 
processes to handle the expansion, and one of these hits a snag?  I'm using 
version 5.1.3 here, BTW, so perhaps you need to upgrade. To get a complete, 
recursive directory listing on Mac OS, I usually use MPW Shell, with the 
command "files -r -f -l". Plus, you can redirect output to a file (just as if 
you were using a real OS ;-)  If you have a good install, you can just compare 
the two directories with "backup -r -a -c -from <goodDir> -to <badDir>".  As 
for handling corrupted installs, please file a separate bug on that.
PDT is gonna put this on [dogfood-][nsbeta2+] radar for now.
Whiteboard: unable to reproduce. → [dogfood-][nsbeta2+]unable to reproduce.
The Macsbug log is in Necko URL parsing, but there is no reason to believe that 
has anything to do with the problem, since Macsbug was entered via NMI.  Our 
best chance of nailing this is for you to debug it on your end, perhaps with 
some coaching from a Mac programmer via phone or IRC. DanM is familiar with 
Mac and window opening, cc'ing him, reassigning to MPT.
Assignee: trudelle → mpt
With the latest nightly (June 07) M17 build on Mac OS 8.6 (same hardware, but 40 
Mb memory rather than 48 Mb) ... StuffIt Expander 4.5 (note the earlier version) 
appears to completely unpack the mozilla-mac-m17.sea file quite happily -- but 
once it has finished, I get told that Expander quit with a Type 1 error. Then 
when I start Mozilla I get the same popping windows as before.

Sorry, but I'm not going to download 20-odd megs of MPW disk image (as well as 
the tool with which to unpack the disk image) just to get a directory listing 
from MPW Shell. Surely there must be an easier way ... like an AppleScript or 
something?

This may be just too obvious, but have you tried eliminating the possible Expander 
problem by using the self-extractor in the .sea itself? BTW, StuffIt Expander 4.0.x are 
known to be a good versions unlike (based on what I've read) some releases in the 5.x 
series.
Tried the installer yesterday, on Mac OS 9.0. It crashed (`Sorry, a system 
error occurred') about 3/4 of the way through.

With the .sea.bin, StuffIt 4.x stuffed up (so to speak) the same as 5.x.
OS: Mac System 8.6 → All
Ok, I tried extracting the installer again and this time it worked. I can run 
Mozilla! So this is no longer dogfood. Still got to track down the problem with 
the non-installer .sea.bin, though.
Keywords: dogfood
OS: All → Mac System 8.6
So, Matthew -- since you can run Mozilla on these machines when you get a 
good 'un-stuff', is this an active mozilla bug? 

By the way, I did file bug #42198 to address the general problem that mozilla
keeps trying to load modules ad infinitum, and should probably admit defeat
rather than do this 'throw endless windows into the top left corner'.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Worksforme now, build 2000060708 (non-installer version), Mac OS 9.0. I guess it 
was just a StuffIt glitch. (sigh)

Verified workforMatthew. Thanks.
Status: RESOLVED → VERIFIED
Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: