m3s: Mac crashes near startup in gfx- large leak somewhere?



Core Graveyard
19 years ago
2 years ago


(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Simon Fraser)


Mac System 8.5

Firefox Tracking Flags

(Not tracked)


(Whiteboard: Side-effect of NSPR memory; other bugs filed for this and failure to detect errors)



19 years ago
Mac crashes when drawing windows in gfx:

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  0A477610
  0AE565C0    PPC  0A476620  main+00448
  0AE56500    PPC  0A26F648  nsAppShellService::Run()+00020
  0AE564C0    PPC  0A26176C  nsAppShell::Run()+00108
  0AE563E0    PPC  0A262050  nsMacMessagePump::DoMessagePump()+0011C
  0AE56370    PPC  0A2621B8  nsMacMessagePump::DoUpdate(EventRecord&)+00050
  0AE56320    PPC  0A262B40
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
  0AE562D0    PPC  0A25CBD0  nsMacMessageSink::DispatchOSEvent(EventRecord&,
  0AE56290    PPC  0A258B4C  nsMacWindow::HandleOSEvent(EventRecord&)+0004C
  0AE56230    PPC  0A258F20  nsMacEventHandler::HandleOSEvent(EventRecord&)+00094
  0AE561E0    PPC  0A259950  nsMacEventHandler::HandleUpdateEvent(EventRecord&)+
  0AE561A0    PPC  0A242E5C  nsWindow::HandleUpdateEvent()+0018C
  0AE56120    PPC  0A243080  nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*
  0AE56080    PPC  0A243080  nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*
  0AE55FE0    PPC  0A242F58  nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*
  0AE55F40    PPC  0A243640  nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
  0AE55F00    PPC  0A243548  nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
  0AE55EB0    PPC  09D8B3C0  HandleEvent(nsGUIEvent*)+00064
  0AE55E60    PPC  09D88DE4  nsViewManager::DispatchEvent(nsGUIEvent*,
  0AE55CA0    PPC  09D88100  nsViewManager::Refresh(nsIView*,
nsIRenderingContext*, const nsR
ect*, unsigned int)+0014C
  0AE55C00    PPC  0A231A44
 Return addresses on the stack
  Stack Addr  Frame Addr   ISA   Caller
   0AE55F48                PPC   0A242F58 nsWindow::UpdateWidget(nsRect&,
   0AE55F08    0AE55F00    PPC   0A243640
   0AE55EB8    0AE55EB0    PPC   0A243548 nsWindow::DispatchEvent(nsGUIEvent*,
   0AE55E68    0AE55E60    PPC   09D8B3C0 HandleEvent(nsGUIEvent*)+00064
   0AE55DE0                68K   0AE55E1E
   0AE55DD8    0AE55DD0    PPC   FFD6E9D4 Color2Index+0001C
   0AE55DA8    0AE55DA0    PPC   0A2512CC
   0AE55D68    0AE55D60    PPC   0A412AC0 nsVoidArray::~nsVoidArray()+00030
   0AE55D60                68K   0AE55D9E
   0AE55D58    0AE55D50    PPC   002C5424 TrimRect+00DD0
   0AE55D50                68K   0AE55DAE
   0AE55D48    0AE55D40    PPC   0A464ACC operator delete(void*)+0001C
   0AE55D40    0AE55D3C    68K   0AE55D9E
   0AE55CA8    0AE55CA0    PPC   09D88DE4
nsViewManager::DispatchEvent(nsGUIEvent*, nsEventSt
   0AE55C28                PPC   FFD6D1E0 SetRectRgn+00038
   0AE55C08    0AE55C00    PPC   09D88100 nsViewManager::Refresh(nsIView*,
t*, const nsRect*, unsigned int)+0014C
   0AE55BD8    0AE55BD0    PPC   002625FC __SetHandleSize+00014
   0AE55BC8    0AE55BC0    PPC   0A231A44
   0AE55B68    0AE55B60    PPC   0A231548

Comment 1

19 years ago
cc:ing dcone, who's been messing with Mac drawing surface stuff, and pierre.


19 years ago
Summary: Mac crashes near startup in gfx → m3s: Mac crashes near startup in gfx

Comment 2

19 years ago
we are using a GraphicState whose memory is 0xEFEFEFEF (which means it has
already been deleted). Pierre fixed a bug like this in viewer on monday by upping
the memory partition. I think that's a bad way to fix this problem (even though
it does fix it) because it just masks the problem and pushes it off to later.

Comment 3

19 years ago
This problem is coming from an out-of-memory condition. A GraphicState cannot be
allocated and its previous value (0xEFEFEFEF) makes the application to crash.

It is likely that the lack of memory is coming from an important leak somewhere


19 years ago
Whiteboard: likely that the lack of memory is coming from a leak elsewhere


19 years ago
Summary: m3s: Mac crashes near startup in gfx → m3s: Mac crashes near startup in gfx- large leak somewhere?


19 years ago
Summary: m3s: Mac crashes near startup in gfx- large leak somewhere? → m3s: Mac crashes near startup in gfx


19 years ago
Assignee: chofmann → davidm
Summary: m3s: Mac crashes near startup in gfx → m3s: Mac crashes near startup in gfx- large leak somewhere?

Comment 4

19 years ago
Apprunner opt build didn't actually crash for me, it just got stuck in an
infinite loop on startup. Pierre's right, when you give it a 30MB partition it
eventually uses about 19MB to display a blank window. Viewer eats 13+ MB.

Comment 5

19 years ago
david, can you help in looking at this?

Comment 6

19 years ago
we are definitely deleting the graphic state and then trying to draw into it.
Pink and I just stepped through the app launch watching the gs (and lots of other
stuff) being created only to see it deleted before the call to
nsRenderingContextMac::SelectDrawingSurface.  I'll see what the call chain is on
the delete tomorrow (unless someone is around tonight and wants to step through
the cobe - I've got to leave)

Comment 7

19 years ago
In response to Pink: I did NOT "fix" the problem by increasing the partition. I
am not that vicious!

In response to Steve: The thing that I saw was that the GraphicState was deleted,
then an out-of-mem error occured when re-allocating it, this error was not
properly reported and when the GraphicState was used, it crashed. Of course, I
may be wrong.

Comment 8

19 years ago
nsViewManager::GetDrawingSurface() fails to check the return value from
nsRenderingContextMac::CreateDrawingSurface(); if the GWorld allocation
fails, the error is not handled.

So many bad things:

1. nsViewManager::GetDrawingSurface() fails to check the return value
   from its call to aContext.CreateDrawingSurface().

2. nsRenderingContextMac::CreateDrawingSurface() doesn't nil out the
   returned nsDrawingSurface before it starts anything.

3. GWorlds are being leaked (I guess). This is the real problem

Comment 9

19 years ago
This is interesting. It looks like what is happening is that the GWorld cannot be
allocated in the heap because of fragmentation reasons; something is allcoating
a few small pointers in the heap which don't leave enough contiguous free space
for the huge, Window-sized GWorld.

Also, the GWorld allocation does not do anything sensible, like try to allocate
first in the heap, and then with the useTempMem flag, so the allocation just
fails. And when it fails, we don't fall back to drawing on screen either, as
we should.


19 years ago
Component: Viewer App → Apprunner

Comment 10

19 years ago
Changed component to Apprunner.

Comment 11

19 years ago
Here is the cause of heap fragmentation:

There is a serious memory leak in NSPR, which causes us to leak a 32 byte
pointer on every PR_Read, as far as I can tell.

macio.c, ReadWriteProc() allocates a new UPP thus:

                pbAsync.pb.ioParam.ioCompletion =

and never calls DisposeRoutine descriptor.

This is causing heap fragmentation, which has other serious side-effects
(like GWorld allocations fail).

Bug 3410 has been filed.


19 years ago
Assignee: davidm → sfraser
Whiteboard: likely that the lack of memory is coming from a leak elsewhere → Side-effect of NSPR memory; other bugs filed for this and failure to detect errors

Comment 12

19 years ago
Assigning to myself, rewarding pain with glory. Updated summary.

Comment 13

19 years ago
With the current API, we can't set the 'useTempMem' flag in order to allocate the
offscreen buffer in temp memory because the pixels have to stay locked until they
are disposed (and InsideMac says that 'useTempMem' should always be used in
conjunction with AllowPurgePixels so that other apps can launch). This should
change when the new API (nsIDrawingSurface) is implemented because it contains
methods to lock and unlock the pixels.

With the new API, setting the returned drawing surface to nil in case of error
will be no good because the application will likely consider it as a
nsIDrawingSurface and call some of its methods. If it's nil, it will break too:
the application must test for error codes.


19 years ago
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 14

19 years ago
Simon and Gordon checked in a fix this morning
in mozilla/nsprpub/pr/src/md/mac/macio.c
at 03/04/99 11:27

Marking as duplicate of #3411.

*** This bug has been marked as a duplicate of 3411 ***


19 years ago
QA Contact: 3853

Comment 15

19 years ago
Marking Verified/Duplicate

Comment 16

19 years ago
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component.  Apprunner component will be deleted/retired
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.