0

I coded a simple picture viewer which just slides randomly through pictures in ~/Pictures.

For each new transition, I am creating and loading the NSImage, then create a new NSImageView and set it as a new subview and the old subview is removed.

This is basically all. The memory is constantly raising with every new picture and I wonder why. I would have expected that it would stay very low and always mostly constant.

I tried to debug it and the profiler tool doesn't find any leaked memory, so I guess it is still referenced or more complicated. Most memory is taken from the function ImageIO_malloc, though.

The full (relevant) code can be seen here (much simplified already -- most of the functionality removed, however the leak remains).

ARC is disabled.

The interesting bit: When I disable the ObjC GC, it is as expected. It stays (relatively) low.

Albert
  • 65,406
  • 61
  • 242
  • 386
  • ARC *and* GC? What, specifically, is your GC setting set to? And what mode is your screensaver module running under when you run it? – Peter Hosey Dec 13 '11 at 14:30
  • @PeterHosey: GC is set to supported. I run this code for testing purpose in an application bundle and not as a screensaver at all. But in both cases, I get the same behavior. But also, with my last edit to the question and a much more simplified test case, this might be irrelevant now. – Albert Dec 13 '11 at 14:32
  • You can run the code in ScreenSaverEngine itself from Xcode: http://www.mactech.com/articles/mactech/Vol.21/21.06/SaveOurScreens/index.html See under “Debugging Tips”. The exact steps are different now, but the procedure overall is similar; the biggest difference is, in Xcode 4, you edit the scheme. Besides removing any possibility of a bug in your custom harness, this also will enable you to tell whether SSE still runs under GC or not. – Peter Hosey Dec 13 '11 at 14:41
  • @PeterHosey: Wether it runs as screensaver or not is not really related to my question. For testing purpose, I anyway have coded a standalone app around it. And for now, I would like to have the memory problem fixed in there. – Albert Dec 13 '11 at 14:45
  • Determining whether the screensaver is being run under reference-counting or GC is vital to doing that. It affects the set of tools available to you and the sets of possible problems and solutions. – Peter Hosey Dec 13 '11 at 14:48
  • @PeterHosey: In my app, I can just enable or disable the GC and/or ARC. It doesn't really matter. The leak is always there. – Albert Dec 13 '11 at 14:52
  • You can't be building that code with ARC as-is, because ARC won't let you call "release". It doesn't look like you're releasing the NSString in "fn" to me... – Andrew Hodgkinson Dec 13 '11 at 15:21
  • @AndrewHodgkinson: He removed the `release` message in a later version of the code on GitHub. As for releasing `fn`: Either ARC or GC should take care of that for him. – Peter Hosey Dec 13 '11 at 20:57

1 Answers1

0

did you try to set newImageView to autorelease?

holographix
  • 2,497
  • 2
  • 32
  • 46
  • Yea, just tried that, no difference. (And btw., shouldn't that anyway not really matter at all with ARC?) – Albert Dec 13 '11 at 14:16
  • yes but you never know, obj-c does always surprise you with mem leaks and undocumented issues/bugs :( – holographix Dec 13 '11 at 14:19
  • aahh, do you have NSZombie enabled? that could be the blame – holographix Dec 13 '11 at 14:27
  • What's NSZombie? You mean the memory debug option for ObjC zombie objects? That's disabled. – Albert Dec 13 '11 at 14:53
  • yes NSZombieEnabled is that option. That gave me kind of a headache once. because it collects all the objects and never release em, btw the ARC shall take care of releasing items when needed. – holographix Dec 13 '11 at 15:27
  • did you also try yo set nextImage = nil in your load function? maybe the release is not working b/c of ARC so setting it to nil will ensure the drop of the obj from the memory – holographix Dec 13 '11 at 15:34
  • I completely disabled ARC now. – Albert Dec 13 '11 at 15:57