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.

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

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.

over to XPToolkit for a look.

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?

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?

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.

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.

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.

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.

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.

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.

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.

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'.

Worksforme now, build 2000060708 (non-installer version), Mac OS 9.0. I guess it was just a StuffIt glitch. (sigh)

Verified workforMatthew. Thanks.

Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.