I have a question which seems like it should be a fairly common occurrence. I am trying to test code which only runs the first time an ios application is installed. While in principle this is very easy, I'm having trouble with it behaving properly the second time the app runs (note, this is not crash related).
I have been force running the app for a second time using the "Application does not run in background" flag in the plist, and then just hitting the home button. This works great, except i stop getting log data after the first run.
Does anyone know how to test for this situation in a way where you can continue seeing the log information after the app closes? For example, if there is a way to attach the xcode logger to the new process id? Or just another way to force an app reboot without losing the logging feature?
Thanks in advance!
Use the debugger menu:
Product>Attach To Process
(Results may vary with different versions of Xcode).
Also, you might need to insert a sleep at the very start of your launch to catch the very early log messages.
EDIT: If you're on a device then you can use the Device Organizer (cmd+shift+2) to watch all logs on a device.
Related
Im facing an issue that i am unable to debug.
If i open the app, it opens normally and works. But if i launch the app and close the app within 1 second and then launch the app again, it crashes without error message.
How do i debug this as Xcode loses debug connection if i close the app?
I tried putting exception break point but since xcode loses debug connection, it wont trigger.
This ONLY happens when a user does the above mentioned steps (open, close within 2 seconds and open again).
Is there anyway to find out why the app is closing and why there is no error / crash message?
Clarification : The crash happens when user opens the app, within 1 sec terminates the app by manually by swiping up from recents menu and tries to open the app again within 1 or 2 seconds. (Open -> terminate -> open)
Let us imagine that you run the app and quickly force-quit. Then, if you start your second run of the app from the Xcode debugger, hopefully, you should see your crash in Xcode at that point.
If that does not work, you might consider a crash reporting tool (e.g., Crashlytics, etc.). That will help you monitor and track crash reports that happen (for both you and your users) in the wild. If you do this, make sure you test the crash reporting system with some forced crash/report because an absence of a report could just be a result of a misconfiguration, which is easy to do because the setup of these tools takes a little work the first time you do it. Just make sure you have the crash report system working with a positive crash report before you draw any conclusions from an absence of a crash report generated by this particular bug.
That having been said, the way these crash reporting systems often work is they capture the crash and send it the next time you start up the app. It seems like there might be a chance that your particular crash (firing it up after having quickly force-quit it the first time) is happening so fast that the crash reporting system may not have a chance to send off its report of the past crash. (That having been said, these are still invaluable for capturing information about user crashes that happen during the normal use of the app, so I would consider them even if it does not help in this particular scenario.)
So, let’s imagine that you are still unsuccessful in catching your crash for some reason. The last resort is to consider sprinkling your code with Logger/OSLog statements. The nice thing about these logging statements is that you can watch these logging statements on your macOS Console app. See WWDC 2020 Explore logging in Swift.
I'm working on trying to launch an automated testing solution for some iOS applications. I'm using fruitstrap to transfer and install a compiled app over to the connected iPhone, but I'm struggling to find a way to automatically launch the application after the installation is complete.
Fruitstrap has an option to run the app in the GDB debugger, which works. Unfortunately there are some test cases which will require the app to be run without the debugger attached (special crash handling). I've spent a good amount of time muddling through the resources available on MobileDevice Library which is what Fruitstrap uses, but I haven't been able to turn anything up on launching an App.
Any ideas?
You can do what you want by using fruitstrap or Xcode to start a "bootstrap" program that causes your target application to run via a custom URL as described by Michael.
While the bootstrap program would be running under the debugger the URL-invoked program would be running normally.
Creating a bootstrap program and using URL Schemes may be an option for some people, and certainly should be considered, but it doesn't fit into my requirements.
What I ended up doing was to launch the app with the debugger through fruitstrap. I re-compiled fruitstrap to include the following prep commands (In the GDB_PREP_CMDS define):
handle all noprint pass nostop
continue
The handle will pass the signal on to the program so the custom signal handler (crash handler in this case) will handle the signal. The continue was something I needed so that the app would actually run once the debugger started.
There is one unfortunate flaw in this, which unfortunately I do not know a workaround for. The ARM7 version of GDB does not have the 'set dont_handle_bad_access' command like the darwin version does. For some reason passing EXC_BAD_ACCESS signals to the program does not work and the app hangs. This is significant since this is the signal for most crashes. But as it stands now, its the best I can do, and at least its handling uncaught exceptions.
I believe you may be looking for some sort of Custom URL Scheme.
Have a look at the following document and scroll down to: Implementing Custom URL Schemes
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/AdvancedAppTricks/AdvancedAppTricks.html
You can also google URL Schemes in iOS to see if you come across something similar to what you are trying to do.
Let me know if this helped you out. Would be interesting to hear if you had any success.
Cheers.
I have a question,
i carefully went through and thoroughly understood the tutorial for iOS Core Data.
The issue was that when i coded everything and run on iOS 4 with multitasking.. the program crashed when i re-opened it (kill task from fast app switching and relaunch)
Then i went curious and recode it on iPad (since it hasn't support multitasking) and it works fine...
I went to explore abit, and some says that the fast app switching kill app is like the OSX kill app and there is applicationTerminate method in the delegate file which maybe need some changes (based on the comment).
Could someone enlighten me on that issue? Is there anything additional that i need to do in order to have Core Data to support the Multitasking feature..
Thank you!
Update
Ok but the thing i am not getting is that.. once i killed the app.. go Fast App Switch, kill it... and when i re-run the app.. it crashed.. Do i need to add some stuff to the multitasking methods? It crashes even if its a basic app with 1 button... What are the states that i have to save?
Update
The app just freeze on its own
Update
Alright my bad, trying my best, for the one button app... I sticked a button in there, and for each click, it prints an NSLog and a label. When i build and run it, it works fine, clicking it prints them normally. After going to background and close the app.. it sends SIGKILL Then when i relaunch the app, it no longer prints to NSLog and crash there 0x98a450f0 <+0000> mov $0xffffffe1,%eax 0x98a450f5 <+0005> call 0x98a453d8 <_sysenter_trap> 0x98a450fa <+0010> ret 0x98a450fb <+0011> nop
Update
However when i open the Iphone simulator and run the program directly... without building it from xcode.. It works just fine and it was able to print that value. Same is true for the Core Data.. if i just run it from the Simulator. Kill it and re-run, it works fine.. Not sure what's going on
With iOS 4.0, your app may not receive a -applicationWillTerminate call. It may only receive a call to go into the background and then be killed.
When you get the call to go into the background you should dump as much memory as possible to avoid being killed, that includes saving your context and perhaps calling reset on the context to get it to drop its cache.
Other than that, no changes need to be made.
What crash are you seeing, a stack trace would be helpful to explore this further.
Update
Again What crash are you seeing?
Update
Freezes where? Where does it stop when you look at it in Shark or the debugger? You are not giving me a lot of information to go on here :)
I'm trying everything i can to get instruments to profile my app on the actual iphone device, but it won't work no matter what i do. I tried the solution from Does Instruments (ObjectAlloc/Leaks) require the simulator? but that didn't work. Most of the time i get nothing of use from the console, but one time i did receive this error:
Mon Aug 31 11:27:48 unknown
lockdownd[14] : (0x83d400)
handle_connection: Could not receive
USB message #13 from Instruments.
Killing connection
I'm not sure what could be causing this; has anyone else seen this and know a solution?
Same problem - it worked the first two times, then after that never again (even after restarting Xcode, deleiting the device, etc).
Eventually I resorted to:
Set XCode to display the Console
Run with Performance Tool
(instruments starts, and goes "BEEP"
with no error - Apple "forgot" to
include the error message, I think.
ARGH!)
Build&Run on device
Once the (gdb) appears in console,
go to Instruments and select "Attach
to Process" from the drop-down at
top
If you cannot see the name of your
debugging app, wait a second, and
try again
Eventually your app appears in the
list of alread-running stuff, so
select it
Hit the Record button
On subsequent runs, Instruments will remember the name of your app, but will show an error if you hit "record" too soon. So you just keep hitting record and doing "OK" on the process it tries to connect to until it stops messing around and does what it's supposed to.
So far (20 odd runs) this works everytime. Obviously, it would be nicer if it just worked properly, without this manual hackery, but Apple is reporting zero error messages even to system console, so there's nothing we can do!
I have some users testing my app on Windows and Mac platforms. The app crashes at some points but the Windows users cannot get any crash logs. Here's what they do
Run the app and play around till it crashes
Sync their device with iTunes
Look for logs here (on a Vista) C:\Users\\AppData\Roaming\Apple computer\Logs\CrashReporter\MobileDevice\
But there is nothing inside the Apple Computer folder.
Any ideas? Thanks.
Aside from you omitting parts of the path in that it should correctly be containing the login username - ow, now noticed you possibly did try to embed it, hence the double backspace after Users....
Ask your user if he possibly is using multiple computers for syncing his device. In case he does, he should check the machine he used first as those Logs are only synced with the "main"-machine, I believe. Bit of a shot in the dark but worth the attempt, I think.
Ow, and there may be another possible reason I just saw within another thread - credits to Kendall:
If there is not crash log, it could mean the app was shut down for using too much memory - in that case you should see a message come up in the device console indicating your application is being shut down.