Anybody having trouble using AVFoundation with GC ON???
What I am experiencing is that when accessing the tracks property of an asset, the file stays open by Core Media. Why is this an issue, well because after a long while and opening up many other media files eventually AVFoundation will report too many open files.
I have tried everything, using Instruments to debug, weak references, #autoreleasepool you name it. In the end this is a bug within Core Media with GC.
So I guess the ultimate question is this:
An app with GC ON, is there a way to run some section of code asynchronously without GC?
Please someone help.
Ok, I am answering my own question.
Basically in short GC is dead!
Yep, the way to go is ARC. So for all those out there coding Mac OS X, use ARC versus GC.
Related
I have a project from 2 years ago that I'd like to bring back into action in xcode.
Is there a simple way to do away with the old style memory management I have in there with retain/releases and use the new .. ARM?
And this is a 32bit app using the QTKit and QuickTime frameworks - can this become a 64bit app that I can put on the App Store one day if it works well?
Also I realise that my app is one enormous .h and .m file - i'd like to break it into smaller files to make it easier to read and find what i am doing - any tips on how to do that?
Thanks guys!
Adam
Use the Xcode menu item Edit->Refactor->Convert To Objective-C ARC which can automatically convert everything to ARC.
You can also use Edit->Refactor->Convert to Modern Objective-C syntax to update the code to use the new array/dictionary/number literal syntax.
For breaking out one file into many, Xcode's built-in refacting support is pretty terrible. You can try out Jetbrains Appcode which has much better support for this kind of thing.
I'm put together a CoreMIDI iOS app where I'm testing MIDINetSessionBrowser and MIDINetworkSession. I've been looking at this for a while now, and it appears that CoreMIDI has memory leaks.
Also, I just tried Pete Goodliffe's CoreMIDI objective-c demo and it also generates memory leaks when I run through profiler!
Thus, I think the chances that I'm missing something are smaller :)
Has anyone else profiled CoreMIDI and found the same?
Note: I'm using latest XCode and latest iOS and profiling by running on iPod touch 4 device.
I've some memory leaks due to CoreMIDI too.
It appears that the same issue still remains on iOS 5.0.
By the way, I'm not using PGMidi classes, but only the CoreMIDI API.
I'm currently migrating the Fragaria framework from a GC-only environment to GC being supported. After the work was done (or what I thought had to be done to make it work) I was able to run the examples that come with the framework without any problems and Instruments didn't show any major memory leaks.
I included non-GC Fragaria in my non-GC application and it crashes as soon as I place the cursor on it. To be honest the usage pattern is different from the examples as I'm embedding it in an instance of NSViewController instead of NSDocument.
Can you give me some tips on how to debug this? I'm a bit lost on where to proceed now.
First thing to do is Build and Analyze the code, then fix any problems it finds.
Next, try running with Zombie detection enabled (google NSZombie).
Finally, each crash's stacktrace should give you a pretty good idea where things have gone off the rails.
I have the same project, that at the beginning, it worked also on ipad, but now it works only on iphone devices, not ipad ones. It's a project iphone/ipad compatibile.
Probably i edit something but i don't know how!
The returned error in DEBUG || RELEASE mode on ipad DEVICE was the classic:
*** -[CFString release]: message sent to deallocated instance 0x110500
...but on iphone, it's all ok.
I can't able to debugging because it show me only assembly code and i don't know where is the issue...
Is this problem appened around? It's my problem or ipad issue?
What could be different on these devices?
thanks, alberto.
It's possible that you're linking against an older version of the frameworks on the iPhone and a newer version on the iPad. If the older version was inadvertently leaking a string, it's likely that the leak was fixed in a newer version of the framework.
At any case, it ultimately means that you're not managing your memory correctly. Any time you see "message sent to deallocated instance", it means you've under-retained or over-released an object. Search this site for how to use NSZombieEnabled (or the Zombies tool in Instruments). Those answers will give you the best information on how to track down the source of the bug. :)
Resolved.
It was a stupid NSString release.
Now is fixed, but this problem occurs only on ipad! :) don't know why!
thanks.
I am getting close to finishing the release of my application and are trying to use Instruments to fix any memory leaks.
How come that I can spot one memory leak when using Instruments and my device but not when I am using the iPhone simulator? I understand that this is a high-level question, but I don't think posting any code would help anyways (quite a bit of code...).
And is it possible to get instruments to point to the source code where it think the leak is? I can do it when using the simulator, but it seems like it doesn't work when using it for the device (objects are represented by the address (I assume) while running it for the simulator it sees what object it is, setup issues?)
Thanks in advance!
Regards,
Niklas
Update: Could it have something to do with that OSX is having automatic garbage collection but iOS doesn't?
Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.
If you haven't already take a look at the handy "Build and Analyze" option in the build menu. It will run the static analyzer which generally does a great job. If nothing turns up with that you should could some time reviewing the WWDC session videos on Instruments.
There is no substitute for profiling on hardware and with the debugger and instruments connected you can get everything you would in a simulator context.