I need to be able analyzing Performance/memory issues which occurs on customer site for a OSX production application written with Objective-C.
As for now I found:
OSXPmem – it’s main drawback is that I need to dump all memory space to in to a single file(it’s not possible for me to transfer ~4GB or more from customer site - I can zip it but the bigger problem is that it not support 10.10 Yosemite.
Valgrind – Does not support 10.10 Yosemite.
Is there a good tool out there ? (such as WinDBG for windows)
BTW at development I use Instruments but in this case it does not help.
thanks for the help
Apparently valgrind will build, install, and work on osx 10.10 from the head of the development branch in the source repository, e.g. as per yosemite-and-valgrind and http://kalapun.com/posts/checking-c-code-with-valgrind-on-yosemite/
However depending on how the application works you may have more luck with the leaks command-line tool or the full-fledged Instruments tool, from Xcode. I haven't upgraded to 10.10 yet to try it there, but it should obviously still work in the latest Xcode for 10.10. leaks attaches to the running process, so is better for long-running processes that you can't shut down (cleanly), or for capturing usage metrics during specific operations.
Related
I'm in charge of developing an in-house enterprise app for the company I'm working for. I've hit a huge roadblock that I can't figure out.
The app use's audio units, I have 3 iPhones:
3gs - iOS 5.1.1
4 - iOS 5.1.1
5 - iOS 6
using a provisioning profile I can run a test build on these devices and everything works fine, using my own developer account and an ad hoc profile, they all work fine. Build it for wireless distribution with enterprise and all the iOS 5.1.1 devices don't work.
There is no install issue, the apps load correctly but the audio units + a circular buffer I made go to hell. It seems like I'm getting massive buffer overrun, but I can't figure why, its only with the enterprise account that this happens. I'm getting all the correct data, the data is feeding into the audio correctly and if I increase the circular buffer size very high I can here the correct audio for a very short time and then it goes hazy and will come back briefly and go hazy again.
I'm wondering if anybody knows any of the underlying differences between a testing build and an enterprise build. Is it possible there are some best practices that I'm not following, as I can't understand why I'm seeing such huge differences between the two.
Note:
Only settings change I'm making between the 2 builds is code signing, nothing else
Without you posting code I can only speculate. The Enterprise build most likely compiles with optimizations while your test builds will not. You may have introduced some undefined behavior that causes your application behave irregularly when optimized. I recommend running the analyzer over your code and fixing any issues, as well as running the profiler. An example of compiler optimizations causing issues can be found here: Compiler optimization causing program to run slower
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.
At our company we use Hudson for our CI, we use a lot of different languages and they all work well on linux.
We don't do this for our iOS projects. I know we can, using a mac with OSX and build projects using the terminal (command line). But can this be done using for instance Debian? Can one also run the unit tests xCode 4 creates?
The reason I am asking this is because I need to know that ordering a new mac mini (or any other mac) is necessary in order to comply with CI.
it sure can be done (i've tried it some time ago) - however, it is questionable whether is it worth the hassle. It is (was) far from straightforward process and from the business point of view the acquisition of a mac mini is way more feasible (i think). However, if you seek challenges you might give it a try, there is a project on google code called iphone-dev that should get you started.
Why can't Xcode be hacked to be able to run on Windows?
Does Xcode have another programming methods?
Also, I heard that iPhone apps are made with Objective-C, so why is this not available in Windows?
Thanks
Xcode is written in Objective-C and takes advantage of a number of OS X frameworks, so porting it to Windows would require porting all the frameworks on which Xcode relies. Furthermore, Xcode also uses a number of programming tools that would have to be ported to Windows as well (some of them already are, of course).
There are several reasons that Objective-C isn't readily available on Windows:
Most development of Objective-C frameworks takes place on OS X, and a lot of the frameworks aren't open-source and thus can't be ported to Windows (they'd have to be rewritten).
There are some open-source frameworks that could be used on Windows -- for example, OS X's AppKit and Foundation frameworks are (mostly) available as part of the GNUstep project -- but these frameworks aren't widely used or supported on Windows, and sometimes lack capabilities found in their OS X counterparts.
That said, GCC is available on Windows, and since GCC is an Objective-C compiler, you could compile Objective-C code on Windows if you had the right libraries available (or didn't use any third-party libraries). But Objective-C isn't terribly useful without supporting frameworks, and those are rare or nonexistent on Windows.
Same can be said why isn't there Visual Studio 2008 for OSX.
Xcode is a big application written to set of APIs not present on Windows. Porting it would be an enormous job, maintaining it would be a big job, and there are already popular IDEs on the Windows platform.
The same reason you can't install Mac OS X on your PC: Apple chooses to make it available only to people who own their own brand of computers.
I guess that porting XCode would be close to very hard (if not impossible) but even if you were able to have a running XCode version under Windows, I guess that it won’t do what you really want it to do. I assume you want a complete iPhone SDK environment which is reliant on XCode and Interface Builder in a very tight way. That’d require the port of Cocoa Frameworks (among other things) that would be, now for real, impossible to port.
Truth is, as much as you will surely need Windows for Windows Phone development, you need a Macintosh computer for iPhone development.
On the other hand, Xcode as an IDE, is not the best in the world, so even if you managed to get Xcode and make it use, .NET (for example), I’d much rather use visual studio for that.
Actually you can install Mac OS X on any Intel CPU based machine. It is legal as you own the orginal install DVD for the OS X system. After aquiring a copy of Virtualbox or VMWare (either is great, personally I prefer Virtualbox because the display settings are more customizable). Virtualbox allows setup on initial setup while VMWare requires an extra step to ensure compatibility. You can then find the steps online to setup a virtual copy of MacOS X.
After going through the steps to install the OS in the Virtual Machine, you can then go through the process to find XCode in the Apple App Store. From there, have at it. Start programming in XCode and have a good time. Since XCode has its own device emulator you have a built in platform for iOS testing. There may be times where it is a bit buggy but that is to be expected with ANY emulator for ANY system you run.
After you get everything installed and going, sit back and enjoy the programming ride. The only catch is if you want to post anything on the Apple App store and then you will have to deal with getting an Apple Dev License. Objective C can be a bit difficult at times but, at the same time, it can be very satisfying when you solve those programming problems (as with any programming language right ;-) )
Enjoy
PS... this VM install keeps up with all updates from the Apple App Store so keeping the system updated won't be a problem.
PSS... I will not condone anyone for where their source of software is but do keep in mind, setting up a VM with VMWare or Virtualbox and an install DVD is only legal IF you personally OWN the install DVD you created the install image from yourself!
Does iPhone SDK 3.0 or 3.1 support Power PC machines having Leopard 10.5 or above? If not then what's the solution for the same results, I have a Mac with Power PC and Panther. I will upgrade to Leopard and install iPhone SDK.
Okay. The answers so far are NOT correct. For some reason, the iPhone SDK has been shipping as a Universal Binary for ages. So, yes, you CAN use a Power PC mac for iPhone development. I've done it and it's verrry dirty.
It's involved and a serious pain. It doesn't work all of the time and there are numerous bugs. It works well enough if you're ABSOLUTELY dedicated and ABSOLUTELY cannot afford a new computer.
Basically, you need to hack up the install XML properties in the installation package. Get rid of the "Intel" check javascript-ish code and/or make it always return true. This will enable the "iPhone SDK" checkbox in the installer.
Once you install it, you can use the SDK and cross-compile to ARM (iPhone processor). The simulator even works, but your milage may vary. My experience was so awful that I simply purchased an Intel Power Mac.
You'll need to hack up the install script for every update. This will involve converting the DMG to read/write beforehand. Editing some Javascript embedded in the XML installation package. Then, hacking up your build properties to get rid of "Native System" selections. It's actually very very painful.
You can Google "how" to do it in more detail. I do not suggest EVER releasing to the Apple store with this method. If you just want to play and get accustomed to the platform, then it might work for you.
Again, I MUST stress, this is very very unstable and totally unsupported. Please know what you are doing before you even consider attempting it.
Yes, it's possible. No, it's not fun.
The iPhone SDK only works on Macs with Intel processors. If you want to save money, you might be able to get the iPhone SDK working on a Hackintosh, but building a Hackintosh may be illegal and applying software updates will be annoying.
I suggest looking for a cheap second-hand Intel-based Mac Mini.
As noted by Will, since the SDK only supports the Intel processors, you are limited to a newer Mac unless you build a Hackintosh which may or may not be legal. However, you also don't need the latest and greatest machine to write software with, although better hardware does help! So you have a couple of options if you are looking to save money in that you could get a refurbished Mac from Apple or check around on eBay or Craigslist to see if you could get one.