I'm having trouble finding a bug in my app because it only presents itself after an adhoc installation. I have narrowed it down to [self.mapview removeOverlay:overlay]; and '[self.mapview addOverlay:overlay]. The exact same code with the exact same steps works just minutes before if I install and debug via Xcode (4.6.1). I'm not changing any other settings in between tests. I just Archive and distribute the app, or I press the Run button and it gets pushed to my iPad. One time it works, one time it fails.
Xcode->device = overlays can come and go as I want
Xcode->adhoc->server->device = complete app freeze when I try to remove a visible overlay or add one that is within the area the map can see right now
I've looked at the crash logs on the device and it always within [MKOverlayClusterView didAddSubview:] or [MKOverlayClusterView willRemoveSubview:]
Here's the main thread as shown in the crash log
0 libsystem_kernel.dylib 0x3c4ff27c __psynch_rw_wrlock + 24
1 libsystem_c.dylib 0x3c44fbd6 pthread_rwlock_wrlock + 334
2 MapKit 0x34fb321e -[MKOverlayClusterView willRemoveSubview:] + 50
3 UIKit 0x3614b2d2 __UIViewWillBeRemovedFromSuperview + 126
4 UIKit 0x35f93844 -[UIView(Hierarchy) removeFromSuperview] + 52
5 MapKit 0x34fae5b0 -[MKOverlayContainerView _removeOverlayView:forOverlay:coalesce:] + 24
6 MapKit 0x34fae118 -[MKOverlayContainerView removeOverlays:] + 240
It's worth noting that in both the add/remove variants the last top of the stack is the same so perhaps this is an issue with pthread_rwlock_wrlock meaning I've crossed threads at some point. I have tried to protect against this by using [self performSelectorOnMainThread:#selector(mainThreadRemoveOverlays:) withObject:#[overlay] waitUntilDone:YES]; but the crash keeps happening when the app is installed via the adhoc method and never happens when debugging via Xcode.
I had something similar problem. I was adding a map overlay to a map.
Worked fine when testing but not for Ad hoc deployment. My solution was that I had put the wrong case. I was using map.jpeg when the file name was actually Map.jpeg.
Map.jpeg != map.jpeg
As the map was working on test I just assumed that was the correct name. Took me a while to find out this was the problem. Not sure why my iPhone 5 or simulator did not pick this up.
Also it is good to Clean your project before deploying.
Hope this helps
Related
I've been coding my typical random stuff in Objective-C/iOS for some years.
Today, a customer I'm dealing with came up with this apparently innocent Crashlytics crash:
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x193b0e1c0 \__exceptionPreprocess
1 libobjc.A.dylib 0x19254855c objc_exception_throw
2 CoreFoundation 0x193b15278 \__methodDescriptionForSelector
3 CoreFoundation 0x193b12278 \___forwarding___
4 CoreFoundation 0x193a0c59c _CF_forwarding_prep_0
5 MyProjectTargetName 0x100087518 -[BannerContainer pressed:] (BannerContainer.m:105)
6 UIKit 0x199f3059c -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:]
7 UIKit 0x199f33ca4 _UIGestureRecognizerSendTargetActions
8 UIKit 0x199af52e8 _UIGestureRecognizerSendActions
9 UIKit 0x199993828 -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:]
10 UIKit 0x199f23ce8 _UIGestureEnvironmentUpdate
...
The thing is, in line 105, inside of BannerContainer.m "Bannercontainer pressed:" IBAction, there's an apparently easy assignation:
if(self.banners==nil || [self.banners count]==0)
{
return;
}
NSInteger position=self.currentPosition; // both NSIntegers
if(IS_IPAD) // Macro working perfectly as of today
{
position=((UIButton *)sender).tag; // this is offending line 105
}
According to Crahslytics, the NSInvalidArgumentException is crashing in line 105... But I can't identify any "invalid argument" there. Instead I would say it's just a button and its (NSInteger) tag attribute being assigned onto a NSInteger variable (sender is ALWAYS a button, as this function is linked to 5 UIButtons inside the .xib file). These 5 buttons have 5 different tags (0, 1, 2, 3 and 4 ). if sender is nil, that line doesn't even crash (I manually set sender to nil to check this claim 5 minutes ago).
Whatever, the thing is I've never been able to make my app crash ON THIS line, as apparently crashlytics says some people in-field have been able to do.
I'm somehow clueless. Any hint? Any rubber-duck debugging someone can guide me through? Why Crashlytics is able to find a crash condition I can't find in my development environement?
Greetings.
EDIT: I don't have access to that Crashlytics account. This crash I posted is just a .txt dump my customer sent us via email. I don't have nor access to this app production environment servers neither to my customer itunes connect account. I just deliver my code to my customer, and then he compiles, signs and uploads everything with his accounts.
Problem "solved" (Can't say for sure though!!).
Well, as was expectable from debug, sender seemed not to be an UIButton.
Apparently, when my app crashed under crashlytics it was because sender was actually a "UITapGestureRecognizer" (as some of you have pointed and was deductable from debug).
But more things had happened also: my customer sent me better info about his crashlytics crash.txt dump, that is, he told me additional info appearing in some other lines of his Crashlytics web interface, these lines made me review other code parts of my app (It was some code written by another person in the past) and that lead me to the correct conflicting lines.
Reviewing these new code parts and files I finally discovered someone was registering tap gestures "on top of my buttons" (to say it somehow) somewhere else in the life cycle of that controller. These gestures were assigned the same "pressed button" IBAction function than I had linked for my real buttons in IB.
This makes sense in the iPhone version of my app (where we don't have buttons, but views, so we need to capture gestures on top of them), but overlaps with ipad version of my app (the crashlytics crashing one), which DOES have buttons to capture clicks.
So, to solve this situation I just removed the selector registering lines for tap gestures, and no more tap gestures get registered when this controller initializes (all this in ipad mode).
Starting from today, Crashlytics shouldn't crash anymore because of this, but I will only know it for sure in some weeks, once this version gets published.
And still, I haven't been able to make this piece of faulty code crash with my own hands, so my worry is still not 100% eased. I'm more than sure I've solved it, but I don't feel total victory.
Greetings and thanks for your help and analysis.
Every time I create a new playground in order to test some code, Xcode gets stuck and won't run the code. It simply presents 'Running playground' or 'Launching simulator' statement at the top of the screen with the loading icon promisingly spinning next to it but nothing happens. Sometimes this continues indefinitely and sometimes Xcode halts and prints this to console :
Playground execution failed: error: Couldn't lookup symbols:
__swift_FORCE_LOAD_$_swiftCoreImage
__swift_FORCE_LOAD_$_swiftFoundation
_playground_log_hidden
_playground_logger_initialize
_playground_log_postprint
thread #1: tid = 0xc0cd0, 0x000000010ea7c3c0 MyPlayground`executePlayground, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
frame #0: 0x000000010ea7c3c0 MyPlayground`executePlayground
frame #1: 0x000000010ea7b9c0 MyPlayground`__37-[XCPAppDelegate enqueueRunLoopBlock]_block_invoke + 32
frame #2: 0x000000010f59625c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
frame #3: 0x000000010f57b304 CoreFoundation`__CFRunLoopDoBlocks + 356
frame #4: 0x000000010f57aa75 CoreFoundation`__CFRunLoopRun + 901
frame #5: 0x000000010f57a494 CoreFoundation`CFRunLoopRunSpecific + 420
frame #6: 0x0000000114985a6f GraphicsServices`GSEventRunModal + 161
frame #7: 0x0000000110124f34 UIKit`UIApplicationMain + 159
frame #8: 0x000000010ea7b6e9 MyPlayground`main + 201
frame #9: 0x0000000112ad268d libdyld.dylib`start + 1
frame #10: 0x0000000112ad268d libdyld.dylib`start + 1
I am running Xcode 8.0 (8A218a) on macOS Sierra 10.12.
Hardware:
MacBook Pro (13" Mid-2012)
2,5 GHz Intel Core i5
4 GB 1600 MHz Ram DDR3
I have looked around but at least neither of these threads have provided an answer:
https://forums.developer.apple.com/thread/5902
https://github.com/jas/playground/issues/9
Things I have already tried with zero success:
Restarting Xcode
Reinstalling Xcode (downgraded to 7.3 but since that didn't help I
upgraded back to 8.0)
Restarting the machine
Creating a new playground
Do you have any ideas on how to solve this problem? I am new to programming and eagerly trying to learn Swift but Xcode is making it practically impossible.
Ans. Switch to macOS platform
When you create a Playground, by default it select iOS platform and automatically imports UIKit. It's the UIKit which crashes and stuck all the time. If your (practice) code does not use UIKit then you can switch to MacOS platform. As major (not exact though) difference between iOS and macOS is in APPKit and UIKit.
In the upper right corner of your Xcode Playground, click on show/hide Utilities--> file inspector --> Playground Setting--> Platform--> macOS
See screenShot below:
I have tried the following and it worked for me:
press on the bottom "stop playground" button
remove the first comment line and make import statement the first
line. no space above import.
press execute button
In my case, Xcode 8.3.2, it works when I try as steps below:
File -> Close "Name.playground"
File -> Close Playground
Quit Xcode
Re-open Xcode
Buggy Simulator's main process is still working even after Xcode closing. So here're the steps:
Quit Xcode;
Kill com.apple.CoreSimulator.CoreSimulatorService process in Activity Monitor;
Launch Xcode and run your Playground.
In my experience, you should:
Prevent Swift playground refresh, by holding: the ► arrow at the bottom left part of the Playground and selecting "Manually Run"
Quit Xcode
Restart Xcode
It works very well.
Adding import PlaygroundSupport solved the problem for me :)
I have cancelled the comment on the first line. It solved for me.
Make sure to try it after you have closed and relaunched Xcode and force quit com.apple.coresimulator from Activity Monitor
You can switch to manual processing. It worked for me.
Make sure you kill xcode in the activity monitor before eventually killing
com.apple.CoreSimulator.CoreSimulatorService process in the activity monitor. I tried killing the process a number of times and I realized if xcode is still running in the background activity then the com.apple.CoreSimulator.CoreSimulatorService process would pop up again even when you just killed it.
I had the same problem, all that I did is to open Assistance editor and everything works fine with me even when I closed the Assistance editor! Don't ask why it was trial and error. Hope this will help you
After beating my head on this for a few hours, I realized I had accidentally deleted this, VERY MUCH important line that allows to test UIKit elements before committing my playground onto git:
// Present the view controller in the Live View window
PlaygroundPage.current.liveView = MyViewController()
Facepalm. Hopefully this can help someone from pulling their hair out for a few hours.
I'm using Xcode 10.2 and am getting the same issue. So generally just use Online Swift Playground
This serves my purposes! :-)
In my case the problem was user-induced. I had the assistant editor displayed, but the live view wasn't selected. Make sure it looks like this:
And not like this:
For me, the issue was the fact that MyPlayground was syncing to iCloud.
Xcode saves your files every few seconds, and it leads to "not responding" states.
So there is a simple solution- just go to:
System Preferences - Apple ID - Apps on this Mac using iCloud- iCloud Drive - Options- And then uncheck "Playground"
That little trick helps to solve frozen "Running".
XCode 12.3 and still same issue happens.
Solution for me is Command + Q ( restart the Xcode )
after runnning a while you will see error message then you go to
view>debug area > activate console
and then play again
worked for me
Check for iCloud storage plan!
If you do have one, it constantly syncs the entire computer which includes Desktop and Document folders.
Instead try creating a "Local Files" folder in your Home folder(command+shift+h) and keep your Playground projects there, where it doesn't sync to iCloud.
This worked for me.I hope this works for you as well! :)
Also happens, like in my case, when you've defined a function, but have forgotten to call it?
As if this question didn't have enough answers, I will provide my "solution" to the stuck Swift playgrounds problem:
The one solution I've come across which works nicely for me (so I do not have to restart Xcode):
killall launchd_sim
This will cause the spinning "Running Playground..." to go away and you can trigger a new execution. Be aware: the next execution is going to spin up launchd_sim and all those child processes again. It would probably be best to kill only the relevant child process. But I didn't find it so far.
But I do this only when I'm not using the iOS Simulators in parallel, as the launchd_sim process is a child process of Simulator.
I deleted derived data and clean build folder. This works for me. I was facing with Xcode 11.2.1 and Xcode 10.1 on same machine.
To speed up the build in Xcode Playground and prevent the loading icon to keep spinning forever:
go to the sidebar on the right, and change iOS to macOS in Playground Settings
instead of importing UIKit, import Foundation
(this would work if you're not trying to use specific stuff from tthe UIKit framework)
I got this answer from : Ioannis Diamantidis - How to fix Xcode Playground getting stuck on "Running".
I am using Xcode version 13.2.1 with a Mac Mini M1.
I went to the playground icon on the top right corner - Hide or show the Inspectors, it says Playground Settings ,
I select in Platform macOs.
now my playground is running perfect, I see the results everywhere
I was facing the same issue but after googling and experimenting a bit, I found out that one must always import UIKit before importing any other libs.
Firstly, delete the inbuilt comment line.
Then, even if you put a first line comment back in, it still works.
One last tip that works for me:
Make sure no iOS simulator is running.
They conflict with each other.
Very often crash appears with following stack:
0x000cc1c8 NR_timeElapsedInMilliSeconds in NRTimer.m on Line 54
0x000f70ea +[NewRelic noticeNetworkRequestForURL:withTimer:responseHeaders:statusCode:bytesSent:bytesReceived:responseData:andParams:] in NewRelic.m on Line 93
0x000cfd7a __41-[NRURLProtocol handleDidReceiveResponse]_block_invoke in NRURLProtocol.m on Line 431
Please can you assist
It seems very likely that this issue is resolved by an update of the New Relic for Mobile Apps iOS SDK. We realize this isn't great news, because updating your app is non-trivial. However, this does look like an issue that is fixed in our most recent agent version: https://docs.newrelic.com/docs/releases/ios
The first step would be to verify that you've got the latest version of the New Relic for Mobile Apps iOS SDK. After that, you'll probably need to get in touch at support.newrelic.com. For a crash like this one, New Relic will ask for the following information (I'm happy to let you know what information New Relic will probably need to investigate, but I don't think all this info is necessarily appropriate to post publicly, so do use a support ticket at support.newrelic.com):
1) I'd like to get a sense of the scope of this issue: was it reported for a single user, multiple users, or is this consistent and replicable in your development environment?
2) A crash log with symbols is helpful for initial troubleshooting, and several third party error reporting services (Crashlytics, TestFlight, Airbrake, etc.) will provide useful stack traces. Please paste any stack traces if you have them. If you're using Apple's crash reports service, you can do the following:
Log in to https://itunesconnect.apple.com
Go to "Manage Your Applications"
Choose your application by clicking on its name
Click the "View details" button under the Versions table
Click "Crash Reports" link
If you don't see any reports, press "refresh"
3) If this can be replicated in your dev environment, I'd like to run some logging from the New Relic for Mobile Apps iOS SDK during the crash. Turn up the logging level in the app by adding this method call before calling startWithApplicationToken:
[NRLogger setLogLevels:NRLogLevelALL];
To make this change take effect, hit “Run” in Xcode and let the iOS Simulator launch. Copy and paste the entire contents of the simulator or device console output while running the app. (press Shift-Command-C to show the debug console in Xcode).
4) Also, please attach your AppDelegate.m to this ticket so that we can take a closer look at how you’ve implemented the New Relic agent in your app. You can find the location of the file by selecting it in the application's project in Xcode, then choosing File > Show in Finder.
5) Finally, please include a permalink to the where the app is reporting to the New Relic user interface. To create a permalink to any page within the New Relic user interface, scroll to the bottom and click 'Permalink ∞' all the way on the right next to 'Kiosk Mode.' This will show us the exact page and time period that you are observing.
#Toby_New_Relic, please find answers below
1) It reproduces not just on one device. As I see it is only iPhone 5S.
2) Stack:
2 libsystem_platform.dylib 0x38284722 _sigtramp
3 libsystem_pthread.dylib 0x38289a52 pthread_kill
4 libsystem_c.dylib 0x381d302c abort
5 libsystem_c.dylib 0x381b2c6a __assert_rtn
6 MyApp 0x000bd760 NR_timeElapsedInMilliSeconds in NRTimer.m on Line 54
7 MyApp 0x000e8682 +[NewRelic noticeNetworkRequestForURL:withTimer:responseHeaders:statusCode:bytesSent:bytesReceived:responseData:andParams:] in NewRelic.m on Line 93
8 MyApp 0x000c1312 __41-[NRURLProtocol handleDidReceiveResponse]_block_invoke in NRURLProtocol.m on Line 431
9 MyApp 0x000e0c78 __NR__dispatch_async_block_invoke in NRGCDOverride.m on Line 38
10 libdispatch.dylib 0x381570c2 _dispatch_call_block_and_release
11 libdispatch.dylib 0x3815c7d8 _dispatch_root_queue_drain
12 libdispatch.dylib 0x3815c9c4 _dispatch_worker_thread2
13 libsystem_pthread.dylib 0x38286dfe _pthread_wqthread
14 libsystem_pthread.dylib 0x38286cc3 start_wqthread
3) I can't replicate this issue on dev env
4)
I just added to pch
#import <NewRelicAgent/NewRelic.h>
and to application:didFinishLaunchingWithOptions:
[ NewRelicAgent startWithApplicationToken: <APPLICATION_TOKEN> ];
5) Permalink
https://rpm.newrelic.com/accounts/47982
First time I launch the app, everything seems to run fine. I'll hit the stop button, do some work and when I go to launch it again, it seems to crash before it can even load anything.
Press stop, hit Run again, and it works fine. Until I repeat the process.
This is where xcode is highlighting the error with "Thread 1:signal SIGABRT".
Obviously nothing useful here.
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([PokerAppDelegate class]));
}
}
The debug console shows nothing besides (lldb) (So I suppose its stopping, not crashing at this point)
So, when I perform a BT this is what I get:
(lldb) bt
* thread #1: tid = 0x1c03, 0x9a258a6a libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x9a258a6a libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x99ea1b2f libsystem_c.dylib`pthread_kill + 101
frame #2: 0x04a7057b libsystem_sim_c.dylib`abort + 140
frame #3: 0x01dc0b4e GraphicsServices`GSRegisterPurpleNamedPort + 348
frame #4: 0x01dc069f GraphicsServices`_GSEventInitialize + 123
frame #5: 0x01dc0c1f GraphicsServices`GSEventInitialize + 36
frame #6: 0x000163f9 UIKit`UIApplicationMain + 600
frame #7: 0x00001d0d Guitar Chord Poker HD`main(argc=1, argv=0xbffff32c) + 141 at main.m:16
frame #8: 0x00001c35 Guitar Chord Poker HD`start + 53
(lldb)
Here's what I have done so far:
Performed a 'Clean'
I've reset the simulators and reset my computer
I've commented out all the code in the view controller, still crashes
I've commented out all the code in the app delegate, still crashes
BUT....I've run the app on a device outside of Xcode, and it seems
to work perfectly fine.
(EDIT) I've deleted/reinstalled xcode, and all content(Simulators, Docs) from the various cache folders (This stops xcode from automatically reinstalling the old ones after a new download). Still can't find where command line tools is kept though. Still crashes.
Despite all this, apps still crash every second/other launch.
Thing is I had no issues until the most recent Xcode update.
Could it be an Xcode bug?
(EDIT) I am also running the latest developer releases of OSX. Could that be interfering?
Seems to be a combination of OS X 10.8.4 and LLDB. As kenster says, switching to GDB makes the problem go away.
Edit:
It's caused by a race condition in the debug server (I hear).
Here's a fix if you want to keep using LLDB: Instead of clicking Run while the app is already running in the simulator, kill it in Xcode (⌘-.), say "I love Xcode" 5 times and Run it again (⌘-R). It won't crash, I tested it.
Fixed in Xcode 4.6.3.
I was having this issue as well. Take a look at this post. Xcode 4.6.2 app crashes on every second run
Basically change your debugger from LLDB to GDB. I can't believe this was due to LLDB being buggy.
Switching to GDB or rebooting device/host does not solve the issue in my environment.
However, modifying the Run target in the associated XCode scheme to no longer launch automatically but instead to "Wait for HelloWorld.app to launch" did.
Only drawback is that this implies to manually start the application on the device. The debugger will then get connected.
I'm a Project Manager trying to help out with my developers;
We had a build that was ready for submission; crash free and testing was done on an iPad. The following day when we began testing it on iPod and iPhone 3G, we noticed a boatload of crashes. We reinstalled the build on the iPad and low and behold a boatload of crashes showed there too.
We noticed that when you reboot the device and reinstalled the app, crashes didn’t seem to happen at all, everything would look ok for the first couple of minutes and then you get a crash. Oddly enough, the app crashes easily afterwards.
Crashes happen mostly on one specific screen of the application, the crashes doesn’t seem to be specific to an action that we can tell. We are connecting to a third party API to populate data in the screen and we are using Restkit. Crashes sometimes appear to originate from Restkit. Below is an example of an error log we got:
0 libobjc.A.dylib 0x34f70ca4 objc_msgSend + 28
1 CoreFoundation 0x325ae0b8 __CFBasicHashStandardRetainValue + 8
2 CoreFoundation 0x325abb30 __CFBasicHashReplaceValue + 44
3 CoreFoundation 0x32505f98 CFDictionarySetValue + 68
4 CoreFoundation 0x3250c94e -[__NSCFDictionary setObject:forKey:] + 54
5 Foundation 0x34d8a31a -[NSMutableDictionary(NSKeyValueCoding) setValue:forKey:] + 10
6 nameofapp 0x000ae958 -[RKClient setValue:forHTTPHeaderField:] (RKClient.m:173)
7 nameofapp 0x000086ae -[WebServer addCustomHeaders:] (WebServer.m:140)
8 nameofapp 0x000088ea -[WebServer getDoD:objectTarget:] (WebServer.m:197)
and
WebServer.m:140 [[objectManager client] setValue:#"text/json"
forHTTPHeaderField:#"X-ZFWS-Accept"];
Two things - First, we need more information. What's the rest of that crash log say? Second, and equally important, if you're running RestKit (or anything else for that matter) on an iPhone 3G then you must make absolutely certain that "Compile for Thumb" is turned off for the ARMv6 architecture. I noticed that a lot of my various mysterious crashes went away simply by ensuring that "Compile for Thumb" is turned on for ARMv7, but off for ARMv6. The iPhone 3G (and possibly your iPod) uses the ARMv6 architecture which does not have Thumb support. When Thumb is turned on for the v6, there's no telling how it's going to work (or not) because the chip is getting bad instructions. However, don't simply turn off Thumb, because you get a big speed bump on newer devices like the iPhone 4 and the iPad.
In your Xcode projects, open up your build settings and click on the title for "Compile for Thumb" then select from the gear menu down the option to "Add Build Setting Condition". Change the "Any SDK" to "Any iOS" and change "Any Architecture" to "ARMv6", then make sure the "Value" is unchecked. Now do the same thing, creating another Build Condition for ARMv7, and select/check the Value to be on.
In the RestKit library, you may have to do this for each of the various targets that it has.