On the Mac, launching apprunner (the Mar 23 build) will result in an unexpected quit if the Largest Unused Block of memory is larger than the minimum amount of memory specified in the Get Info window for apprunner, but not much bigger. How much bigger it needs to be, I'm not sure. On my iMac, the About This Computer box shows that the Largest Unused Block is 11.7 MB. (Virtual memory is turned off; Mac OS 8.5.1 and Communicator 4.51 are running with the default amount of RAM allocated. This leaves ~12 MB.)

Set target milestone to M7.

Move to beta milestone ...

On my machine I can't find any relation with memory allocations and quitting. apprunner (M7) quits (clean quit not an unexpected quit with an error message) right after launching anyway -- even if I try to match the allocation with largest unused block. Virtual memory on, Mac OS 8.5.1

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

Sorry, bugzilla created attachment to wrong bug, please ignore previous attachment.

David, can you take a look at this before we go beta. No hurry. :-)

So is this bug that we need to up our minimum memory requirements?

I'm not exactly sure what this bug means. I'm guessing we should up the minimum RAM required to start apprunner, or see if the crash was due to some other reason...

Adding sfraser. Simon do you remember what tests we did to determine what the minimum parition size should be in 4.5?

I don't think we need to do any tests to check the heap size when running. All our memory allocations are smart about using temp mem if they have to. QA should check that we don't crash with a small partition size, but other than that, there is nothing to do.

M15.

Move to M16 for now ...

I'm not sure what this bug is about. It sounds like it might be a dup of 4051, but I'm not sure.

IIRC bug 4051 was "app crashes when its memory size is set to >35 MB"; this is "app crashes if system free memory as reported by About This Computer is <12 MB". Not the same bug I think.

This is mine.

Eli, can you see if this is still a valid bug. Christopher, feel free to check it out too.

cpratt, could you possibly check this? I don't have anything less powerful than a G4 w/quarter gig of RAM, but understand that you be fortunately to possess much more suitable equipment. ;)

Doh, yes, this is still relevant. Today's commercial build crashes on launch with a 16.7 MB largest memory block available. (Netscape requires 16,510K)

crash is: PowerPC access exception at 0DE55DE4 JS_HashTableRawLookup+00048 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 01F178D4 02F39700 PPC 01F0245C main+00130 02F396A0 PPC 01F0196C main1(int, char**, nsISupports*)+00938 02F393E0 PPC 0CFB850C nsAppShellService::Run()+00018 02F393A0 PPC 0BBB79AC nsAppShell::Run()+00038 02F39350 PPC 0BBB80A8 nsMacMessagePump::DoMessagePump()+0003C 02F39300 PPC 0BBB86B0 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 02F392B0 PPC 0BBCDD74 Repeater::DoRepeaters(const EventRecord&)+00030 02F39270 PPC 0BB95F3C nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&)+000 0C 02F39230 PPC 0BB96054 nsMacNSPREventQueueHandler::ProcessPLEventQueue()+ 000B0 02F391C0 PPC 0B667084 nsEventQueueImpl::ProcessPendingEvents()+00038 02F39150 PPC 0B6C45B8 PL_ProcessPendingEvents+0004C 02F39110 PPC 0B6C46A0 PL_HandleEvent+00020 02F390D0 PPC 09E280B0 nsStreamListenerEvent::HandlePLEvent(PLEvent*)+00024 02F39080 PPC 09E28C14 nsOnStartRequestEvent::HandleEvent()+00048 02F39030 PPC 09E8CBA4 nsFileChannel::OnStartRequest(nsIChannel*, nsISupports*)+00020 02F38FF0 PPC 09EB56DC nsResChannel::OnStartRequest(nsIChannel*, nsISupports*)+00024 02F38FB0 PPC 0D62F73C nsDocumentOpenInfo::OnStartRequest(nsIChannel*, nsISupports*)+00 0EC 02F38F30 PPC 0D63018C nsDocumentOpenInfo::DispatchContent(nsIChannel*, nsISupports*)+0 0718 02F38D40 PPC 0D630918 nsDocumentOpenInfo::InvokeUnknownContentHandler(nsIChannel*, con st char*, nsIDOMWindow*)+0010C 02F38CD0 PPC 0E8A3118 nsUnknownContentTypeHandler::HandleUnknownContentType(nsIChannel *, const char*, nsIDOMWindow*)+0032C 02F38B50 PPC 09D36B54 GlobalWindowImpl::OpenDialog(JSContext*, long*, unsigned int, ns IDOMWindow**)+0001C 02F38B10 PPC 09D3BFD4 GlobalWindowImpl::OpenInternal(JSContext*, long*, unsigned int, int, nsIDOMWindow**)+00A8C 02F383B0 PPC 09D3DD14 GlobalWindowImpl::ReadyOpenedDocShellItem(nsIDocShellTreeItem*, nsIDOMWindow**)+00044 02F38330 PPC 0B6549C0 nsCOMPtr_base::assign_from_helper(const nsCOMPtr_helper&, const nsID&)+00028 02F382E0 PPC 0B6B6500 nsGetInterface::operator()(const nsID&, void**) const+00084 02F38270 PPC 0BB7D040 nsWebShell::GetInterface(const nsID&, void**)+000FC 02F38220 PPC 0BB7625C nsDocShell::EnsureScriptEnvironment()+000E4 02F381D0 PPC 09D22CDC NS_CreateScriptContext+0005C 02F38180 PPC 09D21570 nsJSContext::InitContext(nsIScriptGlobalObject*)+ 000E0 02F38120 PPC 09D21BF8 nsJSContext::InitClasses()+000FC 02F380B0 PPC 09DB8EF4 NS_InitKeyEventClass+0087C 02F38050 PPC 0DE05D38 JS_SetProperty+0006C 02F38000 PPC 0DE32408 js_SetProperty+00144 02F37F40 PPC 0DE4709C js_hash_scope_lookup+00014

since this is a crash bug I am setting keywords to crash -- would this be a common problem or is it more of an outside chance kind of issue?

This may be a relatively common problem on Mac OS computers that shipped with only 32 M bytes of physical RAM, eg a few million iMacs.

so, it is more wide spread than I thought, am adding nsbeta3 to this one -- Simon, if you disagree, just holler

On a low-memory machine, this is the kind of crash that could bite someone every time they tried to run.

adding brackets to status whiteboard

setting priority in status whiteboard

update whiteboard

moving this over to m19, this should be addressed but can be look at in detail with other performance issues

Before RTM, we need to tune the heap size so that we startup without hitting temp mem.

simon, can you provide more detailed information based on the rtm criteria, is this really a p2 or is it really a p3?

No time to address this, and I think it will only affect a small minority of users with very tight memory availability.

removing need info and adding rtm-

For what its' worth, I've experienced this bug with version .08 (haven't downloaded a very recent build, but it looks like no one's really addressed this). Here's what happens-- I'll click on a link in a program like AIM or something where Mozilla has been assigned the default browser. I have always had other apps running, and I guess the problem is there's no room for Mozilla to load.. so what happens is-- the Mozilla "splash" box comes up, it looks like there's 1 or 2 seconds of loading, then-- blammo-- it disappears with no errors. Splash box gone. No mozilla running. I have a feeling this could be important to fix. Thats my 2cents anyway.

jay, this probably wouldn't show up as a top crasher b/c of the small mac population but if there are crashes in the system that fit this profile it'd be nice to know so we can get some sense of how often people are hit by this. e.g. what if this were in the top 20 or so mac specific crashers? just something to keep in mind if you see startup crashes on (only)mac

If anyone has a recent stack trace for this crash, can you please post it? It will help me look in the talkback data for similar crashes and hopefully get you guys more info. Thanks.

removing myself from the cc list

I get this crash at startup using Mac OS 8.6 Largest unused memory block is > 70 MB. Happens every time with no other apps running. Crash description precisely matches that of comment #33 From Waldo.

Still getting this crash with RC3. Browser launched and worked the first time, but on subsequent launches it crashed. Mac OS 8.6 Largest unused memory block > 70 MB

Ver 1.1a will hang on startup on my machine (Biege G3, >50meg unused memory) if file sharing is enabled. Disable file sharing and this bug goes away.

Followup to #39. OS is 8.6

That's a different bug. Please file it as such.

I opened bug 154932 against the macos 8.6 + filesharing blocker, and attached a fix there.

OS 9 is dead.