• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: memory allocation and virtual memory increase
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory allocation and virtual memory increase


  • Subject: Re: memory allocation and virtual memory increase
  • From: Shawn Erickson <email@hidden>
  • Date: Tue, 28 Nov 2006 07:54:08 -0800


On Nov 28, 2006, at 6:43 AM, John Stiles wrote:



Bill Bumgarner wrote:
On Nov 27, 2006, at 10:22 PM, Bruce Johnson wrote:
My program contantly allocates (via malloc) chunks of memory to hold
computer generated data.  It then writes the data out to disk via
fwrite.  Then the memory is then freed.

As Shawn indicated, it certainly sounds like your application has a memory leak. The other, extremely remote, explanation is that you have a seriously pathological allocaiton/deallocation pattern that is fragmenting the heap so badly that you are exhausted addresses without actually exhausting memory. Could happen, but *extremely* unlikely -- safer to assume that it really is a memory leak.


Leaks can lie because memory isn't always zeroed across allocations. Try setting the MALLOC_SCRIBBLE (and MALLOC_PRE_SCRIBBLE, as it catches other bugs) environment variable. At a very minor cost in allocation performance, it'll vastly reduce the number of false negatives ignored by leaks.

Now, though, a second question is raised:

Why is your app "constantly allocat[ing] .... writing ... then the memory is freed"?

This sounds like a fairly standard situation in which you would typically want to allocate a handful of buffers that are filled with data, emptied of said data, and then recycled.
I'm not sure I completely agree with your recommendation of recycling buffers here. In my experience, unless an app is doing hundreds of allocations and frees per second, there isn't a strong need for pooling buffers. Malloc basically /is/ a buffer pooling system, and it's darn fast on OS X, so unless you have special needs and malloc isn't cutting it for you, why reinvent that wheel?

Well if they are large buffers (OP didn't say) then reallocating them can fragment the processes virtual memory space as the large buffers intermix with other allocations. It could result in not having a large enough contiguous virtual memory range to reallocate one of the buffers after some cycles.


Of course I don't think that is happening (not easy to do... unless dealing with rather large buffers and/or much memory allocation in between)... I think he is hitting some type of memory leak or some other type of crash in his code that he is incorrectly linking with having a large virtual memory space allocated.

-Shawn
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Re: memory allocation and virtual memory increase
      • From: "Bruce Johnson" <email@hidden>
    • Re: memory allocation and virtual memory increase
      • From: Bill Bumgarner <email@hidden>
References: 
 >memory allocation and virtual memory increase (From: "Bruce Johnson" <email@hidden>)
 >Re: memory allocation and virtual memory increase (From: Bill Bumgarner <email@hidden>)
 >Re: memory allocation and virtual memory increase (From: John Stiles <email@hidden>)

  • Prev by Date: NSTableView: scrolling bug??
  • Next by Date: Slightly OT: SIGKILL (force quit) and child process termination
  • Previous by thread: Re: memory allocation and virtual memory increase
  • Next by thread: Re: memory allocation and virtual memory increase
  • Index(es):
    • Date
    • Thread