After running into this issue for the 10 billionth time and nearly whipping my mac air out the window in frustration, I've decided to break down and ask if anyone else has run into this...
Environment: running the latest version of XCode (as of this question: 4.2, build 4C199) for an iOS 4.2+ application (universal app).
It appears that GDB randomly decides to completely hang while stepping through lines of code. This has happened to me now on multiple codebases, and in various locations throughout each codebase. The stepping process hangs on an arbitrary point and requires that the running iOS simulator or on-device process be stopped and restarted. Typically, after restarting my debugging session I am able to get to a different arbitrary point in stepping into/thru -- sometimes even enough to actually debug my code entirely (gasp).
I tried wiping my drive, re-installing a fresh copy of Mac OS X 10.6.8 and the aforementioned XCode... No difference.
I tried switching debuggers to LLDB; this resolved the hanging issue, but I'm not as big a fan of LLDB and prefer to use my environment as close to stock as possible.
Any thoughts?
If GDB is still hanging after reinstalling your OS and your SDK, it may be a design issue with your particular code. Does this happen with other projects?
If it makes you feel any better, Apple is moving to LLDB as the stock debugger for Xcode, probably due to issues like your aforementioned issue.
Related
I am building/running a relatively simple chat application. Every time I run/build the application, the fans on my MacBook get extremely loud and my computer begins to heat up very quickly. Furthermore the builds are taking a ridiculous amount of time to finish, even after editing just a single line of code.
I opened up activity monitor and noticed that "SourceKitService" was using 100% of the CPU.
Earlier today, I deleted the DerivedData folder for my project, and that still doesn't seem to solve this issue.
How can I fix this?
Try doing a deep clean (Command+Shift+K), deleting derived data, closing Xcode, and restart Mac. That usually helps me. However, when I'm running apps on my 8GB memory Mac some cause the same issue while my 16GB Mac runs them just fine.
I am working with my app in test flight now and I have experienced this maybe only one time myself. How can I get to the bottom of a rare crash without it being hooked up to the computer? The only information is that it occasionally will freeze, but other than that it doesn't seem to be happening with a specific action. How do I debug this?
Here are some approaches:
Write log files to the disk, which you can later sync. or send to a server for investigating which operations succeeded before it crashed
Integrate a custom (such as KSCrash, Crashlytics, etc.) crash reporter tool that allows you to see a backtrace (Note though that enabling Bitcode will make things much harder)
Try to reproduce the problem in the simulator (try different builds, debug build, release build, send memory warnings, etc.)
Try to reproduce with a computer connected. Interactive debugging makes things so much easier.
Good luck!
I am using Xcode 5. When I had Mountain Lion installed, doing a build after a clean took less than 10 seconds for my project. It was extremely fast.
After upgrading to Mavericks, doing a build after a clean now takes about 2 minutes for my project. It takes almost one second to compile each source file! The source code is exactly the same as the code before the upgrade, so I know that this problem is definitely caused by the Mavericks upgrade.
Running the top command shows about 15 clang processes during build time. Each clang process keeps switching from the "sleeping" and "stuck" state. So I'm wondering if this issue has something to do with race conditions with the multiple clang processes.
So far I have tried rebooting, and reinstalling XCode.
Edit
Other Info: I'm using the latest macbook pro with retina display with 16GB of ram. I also have file vault enabled. Will try disabling it to see if it changes performance.
I've solved the problem. Turns out it was my virus scanner McAfee. It must have been scanning every source file before letting Xcode compile it. The weird thing is the virus scanner was taking up almost no cpu cycles.
Sometimes I'm trying to track down a really rare bug in an iOS app. I'll hit it in the debugger after hours of trying to repro only to have xcode or lldb crash on me while I'm debugging (usually if I'm stepping through C++ code). This is beyond infuriating.
With gdb you can use generate-core-dump to create a core dump of the file so that I can re-load it in gdb and at least look at all of the memory. What I want is the ability to do something similar in lldb so that when xcode crashes (as it always tends to do at the worst times) I can recover my debugging session without having to reproduce the crash.
The app is running on a non-jailbroken iPhone, so I don't have much access to the OS to do something like dump the memory from there.
One possible answer is to just use gdb instead of lldb, but I think that causes some other problems that I'm not remembering at the moment, plus it doesn't have some of the features that are useful in lldb.
UPDATE: Xcode 6, released fall of 2014, includes a new process save-core command in lldb -- lldb can now generate a coredump of a user process. e.g. (lldb) process save-core /tmp/corefile and wait a little bit.
The original answer for Xcode 5 and earlier lldb's, was:
This feature isn't implemented in lldb yet. This feature isn't implemented in the Apple version of gdb, either, for that matter.
While not a commonly requested feature, it is something other people have said would be useful as well. Hopefully someone will be sufficiently motivated to add that capability to lldb. I'm not sure how well it would work on an iOS device because it's going to involve gigantic amounts of data being transferred up to the Mac over a protocol that isn't very efficient for large data transfers - I expect it would be remarkably slow.
The core file can be opened with lldb -c /tmp/corefile
It's worth noting that the process explorer tool for iOS can generate core dumps of any PID (assuming you have root or it's the same UID as you), without impacting the process.
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator