Virtual Memory problem.

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • rollasoc

    #1

    Virtual Memory problem.

    Hi,

    Our application, seems to run fine for several hours, then pops up with a
    low virtual memory message. This sometimes then crashes the system, since it
    will then say one of the objects has not been instantiated.

    I'm assuming we've been a bit lax with the disposing of objects. Is there a
    difinitive list of things we should be disposing manually?

    The application is graphic intensive and we have been disposing of variosu
    graphic \ pens and brushes objects, but what about temporary bitmaps (i.e.
    backbuffers) etc.

    Any tips as to what else I might need to Dispose rather than let the GC have
    a go at an unspecified point?

    rollasoc


  • Michael Giagnocavo [MVP]

    #2
    Re: Virtual Memory problem.

    You should call Dispose on every object that implements it. If an
    object is finalizable, calling dispose will ensure it doesn't goto the
    finalize queue, which will let the GC collect the memory sooner.

    If calling Dispose doesn't fix the problem, look into profiling the
    app.

    -mike
    MVP

    "rollasoc" <hotmail@hotmai l.com> wrote in message
    news:uWK8P2mZDH A.1128@tk2msftn gp13.phx.gbl...[color=blue]
    > Hi,
    >
    > Our application, seems to run fine for several hours, then pops up[/color]
    with a[color=blue]
    > low virtual memory message. This sometimes then crashes the system,[/color]
    since it[color=blue]
    > will then say one of the objects has not been instantiated.
    >
    > I'm assuming we've been a bit lax with the disposing of objects. Is[/color]
    there a[color=blue]
    > difinitive list of things we should be disposing manually?
    >
    > The application is graphic intensive and we have been disposing of[/color]
    variosu[color=blue]
    > graphic \ pens and brushes objects, but what about temporary bitmaps[/color]
    (i.e.[color=blue]
    > backbuffers) etc.
    >
    > Any tips as to what else I might need to Dispose rather than let the[/color]
    GC have[color=blue]
    > a go at an unspecified point?
    >
    > rollasoc
    >
    >[/color]


    Comment

    • rollasoc

      #3
      Re: Virtual Memory problem.

      Cheers Michael,

      I've started disposing of things as I go and the problem hasn't been seen in
      a couple of days (though I'm system testing it this afternoon, so we shall
      see).

      I've just downloaded a profiler as well, so will have a go with that.

      rollasoc

      "Michael Giagnocavo [MVP]" <mggUNSPAM@Atre vido.net> wrote in message
      news:#PmvZUoZDH A.2328@TK2MSFTN GP12.phx.gbl...[color=blue]
      > You should call Dispose on every object that implements it. If an
      > object is finalizable, calling dispose will ensure it doesn't goto the
      > finalize queue, which will let the GC collect the memory sooner.
      >
      > If calling Dispose doesn't fix the problem, look into profiling the
      > app.
      >
      > -mike
      > MVP
      >
      > "rollasoc" <hotmail@hotmai l.com> wrote in message
      > news:uWK8P2mZDH A.1128@tk2msftn gp13.phx.gbl...[color=green]
      > > Hi,
      > >
      > > Our application, seems to run fine for several hours, then pops up[/color]
      > with a[color=green]
      > > low virtual memory message. This sometimes then crashes the system,[/color]
      > since it[color=green]
      > > will then say one of the objects has not been instantiated.
      > >
      > > I'm assuming we've been a bit lax with the disposing of objects. Is[/color]
      > there a[color=green]
      > > difinitive list of things we should be disposing manually?
      > >
      > > The application is graphic intensive and we have been disposing of[/color]
      > variosu[color=green]
      > > graphic \ pens and brushes objects, but what about temporary bitmaps[/color]
      > (i.e.[color=green]
      > > backbuffers) etc.
      > >
      > > Any tips as to what else I might need to Dispose rather than let the[/color]
      > GC have[color=green]
      > > a go at an unspecified point?
      > >
      > > rollasoc
      > >
      > >[/color]
      >
      >[/color]


      Comment

      Working...