Why does NSColorPanel accumulate memory usage? Try it:
Create a brand new cocoa-based application in Xcode
add a sinlge NSColorWell to the main window
Run app and open a memory monitor (ex. Activity Monitor)
Click the colour well to bring up the NSColourPanel
Click and drag your mouse on the colour wheel, twirling it around and around for a while, watching the app's memory usage
Result: Memory keeps climbing, slowly but surely (4-5Mb's in about a minute). In my tests, it seems to hit some sort of barrier after climbing about 4 megs, after which it stays somewhat steady, or climbs more slowly. And this is with garbage collection turned on. With it turned off, there seems to be no barrier; memory usage keeps climbing steadily.
This isn't a huge deal, practically-speaking. But it bothers me. I want to know what is going on with the memory, if such "leaks" (?) occur in other standard gui objects the developer may have no fine control over, and if this is just a gap in my understanding of how things work.
The only thing I can think of is perhaps the app is storing a history of selected colours for whatever reason (and this history keeps growing), but this seems unlikely to me.
File it at bugreport.apple.com.
Related
I'm working on a Mac app. Initially monitoring Xcode's memory report while I ran my app showed showed the memory was just ramping up crazy. I used Instruments and profiled my app for allocations and leaks. Turned out there wasn't much leaked memory as you would expect due to strong reference cycles etc. However there was a lot of abandoned memory. By following the stack trace that lead to my code I have fixed by 70% using autorelease pools etc. Still the remaining 30% of abandoned memory seems to point system calls.
Now I have two questions based on that I have two questions
1) I want to fix the remaining 30%. How can I get rid of abandoned memory? I have already used Instruments and know exactly where those system calls are spawned but still dont know what to do to have that memory be cleaned up. (using ARC no manual retain/ release and autorelease doesn't seem to make a diff.)
2) After I know whatever my application was doing has completed and there is no need for any memory to be there (just like the application first started) I want to get rid of all memory that my app has used up. This I plan to use as a brute force approach to clean up all memory just like the system would if the user closes the app or turns off the system.
Basically if I know where my apps memory is in the file system I'll just programmatically call purge command on that or something similar. Because at this point I'm 100% sure nothing needs to be in memory for the app except for the first screen that you would expect the first time you launch the app.
I read this, this, this and this but they weren't helpful.
Hey, im running cocos2d, box2d and several particle systems on the iPhone 4.
I've completed my first level which has numerous sprites allocated as well.
I have set my FPS limit to 30fps.
When the game first runs, it runs well, at a solid 30fps. This continues for about 3-4 minutes of smooth gameplay.
But after a while the fps starts to drop, and it turns into a gradual decline until it hits around the 12fps mark.
I remember I had this problem with a previous game that I abandoned.
Is this caused by a memory leak, possibly from not deallocating items??
In my (void)dealloc methods, I am inputting all my allocated releases, could I have missed one? Or is there some other possibility i'm not considering?
Thanks!
Sounds like you're running out of resources. I'd try Instruments as suggested by SB. Instruments can check for leaks using the Allocation instrument. You could also try the OpenGL profiling suite.
I have the same problem and I cannot get the resolution. When I unload the entire scene and reload it again, everything is back to normal. So it definitely seems to be a leak somewhere, but even with instruments I cannot find the source of it.
The total memory usage is not growing, no leaks reported, so I have the feeling that something in Cocos2d or in Chipmunk increasing the load.
I am using sprites which are moving in and out from the screen in a random manner and creating nd destroying them every time. Can it be that something is not released properly and Cocos or Chipmunk is still calculating with those items?
Leopard 10.5.8, XCode 3.1.1; using runModalForWindow to implement (what is intended to be) a high performance mouse tracking mechanism where I have to do real-time complex bitmap modifications.
The modal loop runs, the timer fires, the mouse tracks... but the performance is abysmal, and it gets worse and worse the longer the runloop goes on. Instead of catching mouse messages every pixel or so, I get them every 5... 10.... 20 seconds.
Instruments shows that the majority of the time during this growing response bottleneck is being spent in mach_msg_trap (and yes, I have the perspective set to the running app), so the impression I am under is that it "thinks" it doesn't have any work to do, despite the fact that I'm dragging the mouse around with the button held down like a crazy person. There are no memory leaks showing up, and in my 8-core 2.8 GHZ machine, there's almost no CPU activity going on.
Again, the app is not spending much time in my code... so it's not a performance problem of mine. I've probably configured something wrong, or failed to configure it at all, or am simply approaching the whole idea wrong -- but I sure would appreciate some insight here. As it stands now, the dispatch of mouse messages and timer messages is absolutely unacceptable. You couldn't implement a crayon drawing program for someone immersed in cold molasses with the response times I'm getting.
EDIT: Some additional info: doesn't happen on my 10.5.8 macbook pro. Just the 8--core, 6-display Mac Pro. I tried taking the display code for the croprect in drawrect out, replaced it with an NSLog()... still drags on issuing mouse updates. Also tried rebooting and running without the usual complement of apps running. And with mirrored displays. No difference.
Imagine dragging a brush across the screen; at first, is paints smoothly, then gaps appear between brush placements, then they get larger, and this goes on until you're only getting one brush placement every 10 seconds. That's how this acts. Using NSlog() and various other tracking methods, I've determined that it is at least at the highest level occurring because the mouseDragged events slow down to a trickle. The question in a nutshell is, why would that happen?
Anyone?
OK, isolated it -- the problem comes from my Wacom Tablet mouse. Plug in a regular optical mouse, and everything runs great. Same thing on my Macbook pro, using the trackpad. Works fine.
The tablet is a Wacom Intuos 4 with the stock drivers as of January 2011. I'm going over to the Wacom site and reporting this next.
What a nightmare that was. I have spent over 100 hours on this, thinking I'd hosed some subtlety in the app handling, drawing, etc. Sheesh.
I'm having strange effects with my app. I implemented my own PDF viewer. It shows ONE page at a time. Using Instruments Activity Monitor I see that my real memory is constantly at around 50MB.
After switching pages forth and back a couple of times I receive a memory warning level 0.
I do my best to react on it and sacrifice the low-res background image I'm rendering first to show something until CATiledLayer catches up.
Does not help. A few pages later I get memory warning level 1 and level 2 and after a few more pages my app gets killed with reason "9". Memory NEVER goes above 50MB!
Why do I get those warnings in the first place? There IS enough memory available.
This is happening on on iPad running iOS 4.3.
I don't think there's anything mysterious going on here -- which I'm sure is not what you wanted to hear. There are no absolute figures of "safe" amounts of memory to use. The rule is: when the OS tells you you're using too much, use less. It will jettison background processes first and in preference to your foreground app but there are still limits.
In the "olden days," you used to be lucky to get 20Mb. I'm sure you can safely get more than that on an iPad but, apparently, it's less than 50Mb.
You don't say how much memory you free by releasing the background image, but it seems that you need to be caching less data. You might also want to check Leaks (also in Instruments) to make sure you're releasing the objects you think you are.
I have a VB.NET application that crashes on a client's computer with a BSOD error... KERNEL_DATA_INPAGE_ERROR.
This error occurs at a point where my program does two things:
Locks the computer
Plays a sound in BackgroundLoop mode
For locking the work station, I am just using this:
<DllImport("user32")> _
Public Shared Sub LockWorkStation()
End Sub
For playing the sound, I am doing this:
My.Computer.Audio.Play(My.Resources.ResourceManager.GetStream("somesound"), AudioPlayMode.BackgroundLoop)
Now, this sound loops until the user logs back in. My software detects the session state switch and stops playing the sound. Sometimes when I log back in, the sound card plays garbage data for a split second, instead of the rest of the audio buffer. I get the impression that this has something to do with session switching.
Could my client be having an issue where there is memory corruption occurring at the point of locking the computer?
I apologize for the vagueness of this post... I am not sure where to begin as I cannot reproduce the problem myself.
Edit: If the sound is left to play on its own, even without locking the computer, eventually the computer will lock up and then bluescreen. Playing the sound while locking at the same causes it to happen sooner.
Edit #2: So I've seen it fail now. The sound loop starts playing correctly but quickly switches to looping of garbage data. It's as if it is just reading a random location in memory and looping that. Very strange behavior!
Solved!: It was hardware all along afterall. Apparently this particular model of laptop has a problem where the speaker is installed right on top of the hard drive. When playing sounds loudly, it creates all sorts of problems.
A blue screen is almost certainly related to defective hardware or drivers. Softwarewise, there's really not much you can do about this apart from putting together a workaround.
You can perform a memory dump and try to determine what specifically went wrong, or with some clever debugging see where it bombs out in order to try to avoid it.
Otherwise, you're probably talking about doing some maintenance work on the machine in question.