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.
Related
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.
Well, while running my iPhone game on my iPhone 4 through Xcode, my app crashed (sometimes does, sometimes doesn't), and when it crashed, Xcode didn't throw me any info. In the log, I could see (gdb) written, but nothing else that could help me find the problem.
What could cause such an error? At least it should tell me something, no?
Crashes without explanation on the device itself are often due to using up too much memory; the device simply terminates the app when it has requested more memory than available. This is easy to do in game development, with all those images.
Use Instruments to track memory usage, and/or put some good memory management code in the App Delegate methods for memory warnings and always release as much as you can.
After reading:
iphone: submit app with iOS 5 and XCode 4.2?
I realize that using ARC and expecting to release an app to the app store with this technology might have been a bit short-sighted of me. What is the best course of action for me?
Use Xcode 4 and redo the memory management
Wait for Xcode 4.2 to be released
Some other magical way that will solve all my issues and make my dreams come true
Thanks for the advice.
Update: Just in case anyone wandered on to this, it was while Xcode 4.2 was still in beta. End result: don't use beta features unless you're ok with waiting for the final release.
So, first, there is no Santa Claus. That leaves us with:
How urgently do you want to ship?
Xcode 4.2 is going to ship with iOS 5. iOS 5 is likely to ship around September. It could be later. So can you sit on your app for that long? If so, eh, keep polishing, maybe work on some additional features, do an exhaustive run of QA, then when the GM is ready you'll be all set.
If you want to be the master of your own destiny and ship on your terms, install Xcode 4.1 and run the static analyzer to get the full measure of your missing memory management, spend a few hours fixing things up, then profile and test the hell out of it just to be sure. Read up on the Leaks instrument, along with NSZombieEnabled, should you run into unexpected memory issues (dunno how big your project is, but I'm sure they can build up with the luxury of ARC snatched away).
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 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.