I am currently importing all the facebook birthdays and inserting them in core data,then i sort them according to the latest bday's(fetching and sorting).
When i use facebook to sync and get all the contacts,my app retrieves all the contacts perfectly,but after it receives the contacts it soon crashes..
i tried using zombie objects.
i tried leaks.
i tried adding an exception in exception navigator.
i synced my ipod with itunes went to library and device logs but couldnt find any file which says low memory issue or something that sorta.
i am confused because the reason for the crash doesnt show up,it simply crashes and when i open my app again i can see all the contacts imported from facebook
there is no lldb in the debugger window,when i change it to gdb,i can see gdb but when i use backtrace(bt) it say "No Stack"
i also noticed there is one thing i.e if there are too many contacts my app crashes and if there are less contacts it works normally.
what can be the problem? does it crash because of a memory issue?
how am i supposed to know what is causing the crash?
thanks
Your app is most likely being terminated due to low memory.
The best thing is to look at the device console using Xcode's Organizer:
If iOS is running out of memory and killing your app, you should see something like this:
<Notice>: jetsam: kernel termination snapshot being created
<Warning>: Application 'UIKitApplication:com.yourapp[0x6337]' exited abnormally with signal 9: Killed: 9
You should use the Activity Monitor in Instruments to see how much memory your application is using.
You can also use the Memory Monitor instrument and enable graphing of "Physical Memory Free". If you see the graph approaching 0 before your crash you can be pretty sure it's a memory issue.
Try to put some code for memory releasing into viewDidUnload. For example, if you create a link between code and xib using mouse then xcode generates code for current element automatically.
Related
Recently I had an issue in my iOS app that caused the app to freeze. The UI was unresponsive and the user had to kill and restart the app to make it work again.
In Google's Play Console I see such issues as ANRs ('Application not responding' errors).
But in Xcode I don't get any reports unfortunately. Crashlytics also didn't show any reports.
Is it possible to somehow get some kind of report with a stacktrace similar to the ANRs in Google's Play Console?
Please note:
I know what caused the app to freeze in this specific issue and also how to debug and fix it. What I
want is an error report in case the issue wasn't found during QA but it is
occurring in a user session.
The freezing version was not published to App Store, only to
TestFlight.
The reason for unresponsive UIs could be due to a number of reasons:
One reason could be because of high load (running out of RAM, Swap Space). For detecting these scenarios (without crashing behavior) you need Application Performance Monitoring, for example with Firebase. The advantage with Firebase is you don't have to prompt for consent, so you get more data to detect hangs. The Xcode Organizer can provide Hang Rate metrics though if you have enough users who have consented to share their data (new in Xcode 11).
Another reason could be due to logical errors in code. For example, a user triggers an unexpected app flow that was missed during manual testing. In these instances, it can be harder to narrow down but could be trackable with manual user testing beforehand e.g TestFlight. You can use In-App Feedback tools (users send you emails) to gather context about the issue or Instabug for screenshots and advanced feedback.
The other reason could be because of deadlocks. If you use DispatchGroup for instance or DispatchSemaphores to queue network requests and the requests time out then that could also lead to suspended UI frames. I would look carefully at where you leave the dispatch group as well - all possible branches should have a dispatch_group_leave statement to avoid hanging on dispatch_group_wait.
You can use the Thread State Trace Instrument to see whether system calls are blocking your main thread to debug this issue. The classic iOS dev advice is to only perform UI updates on the main thread and move all other logic to a background thread. This may not solve the root cause but does prevent hangs. The same logic applies for Core Data fetches, inserts, deletes, and updates. Move Core Data operations to background threads in network request callbacks as well.
If you get crash reports, it's simple to diagnose an OOM error in a Crashlytics crash report for example (comes up in Insights). Heap corruption can also be inferred from crash reports, and while the metadata may not be the same for the same behavior, it could point you to a screen or action when you try and reproduce the bug.
Watchdog Unresponsive App crashes can be intercepted to come up in crash reports if the user doesn't kill the app beforehand, but you mentioned the user killed the app so this may not be available.
There is no direct equivalent ANR error reporting for iOS apps, given that Hang Rates are only aggregated if enough sessions have been detected. You could do screen recording of app sessions (ServiceNow), but I don't advise it because it has privacy implications.
Crashlytics is unable to send abnormal terminations fired by the watchdog. I've researched this for Jetsam terminations. You will see them in the console logs. see this link for the watchdog crash iOS generates: Watchdog Unresponsive App. If there's a way to monitor the main thread for queued operations executing for too long, you could fire a fatal error ie fire a fatal before the watchdog terminates the app.
Do some research on MetricKit. It's new to iOS 13. There's a class called MXHangDiagnostic. You can use it in your app to monitor for hangs and report on them as you see fit.
With the new feature of iOS 13 to report crashes for TestFlight builds, on some apps I have a problem that only feedback.json is reported without actual crash report.
Is there anything to enable?
Worth to mention that crashalitics is enabled and not reporting any of the crash.
Update: so after some investigation, I found that reports without a crash logs are system terminations. In my case when I extracted device logs from the phone and it was 0xbadf000d, one of the meanings is system terminated a long process in the background. Seems it was always there, but with iOS13 Testflight feedback it becomes visible with popups.
By the wat, somehow logs from Xcode "Devices and simulators" are not in sync with logs directly on the phone.
Takeaway: Faced a need to manually simbolicate a crash report, so found super useful stackoferlow post: https://stackoverflow.com/a/45207863/3032917
This happens when the watchdog kills the application due to some reason. we can check the logs in the Analytic & Improvement section
I am facing the same issue, the system terminates the network extension due to some reason. And, many users has downloaded the app from test-flight and they are seeing the default crash alert from OS. since test-flight feedback does't contain crash logs, i am not able to identify the problem.
Encountered the same behaviour when the specific device was on low storage. The device has less than 50 MB remaining from 30GB of storage.
You mixed up the crash log and crash feedback of TestFlight.
What you see in JSON format is Crash Feedback. It is available since iOS 13 devices and can be obtained by App Store Connect > TestFlight.
For Crash Log, it can be found in Xcode > Organizer > Crashes. If you cannot see the logs, it will appear few hours later (but please make sure dSYM is enabled when you're uploading the archive to the App Store Connect).
I'm using Xcode 5.1.1 making a game app in iOS 6+. I am currently not a member of apple development, at least not until i finish the game completely. Sometimes right after i quit the simulator i get a "Terminating in response to SpringBoard's termination" message appear. I know it's a memory management issue but with ARC i don't deal with memory. Also does this have something to do with the size of my app? But i don't know it's size. One minute Xcode shows 40mb and the next it'll show 12mb or 20 mb and other mb's in between so i don't know. Lets say i publish the app in app store and don't fix this rare termination issue, how would that affect the user when using my app? How would i fix this termination message issue?
If you're quitting the simulator via command-Q, then a "Terminating in response to SpringBoard's termination" message is actually proper (the simulating app is terminating before the simulator -- that app known internally to Apple engineers as SpringBoard -- terminates).
As for your memory worries, once you get the hang of Xcode, you should try running your app under Xcode Instruments and with the Activity Monitor template and/or the Allocations template.
I can't determine the cause of a crash.
While running the debug build of an app on an iPad 3.1 from Xcode, the app terminates but the debugger doesn't tell me anything. I have an all-exceptions breakpoint and that has certainly worked in the past to catch errors.
Not that I know how to use a crash dump, but when this happens the "Device Log" in the organizer devices pane shows an entry from process "Unknown" of type "Unknown".
I am also having memory warning problems, but in this case I'm not getting the memory warning method invoked (I have a log message and a breakpoint). Could this be a memory warning that doesn't invoke the method ever? [The memory warnings are a puzzle since Instruments isn't showing me any leaks and my own image objects aren't (obviously) being kept in memory -- but that's another problem].
Any idea what is happening to me and how I could get the debugger to trap the condition?
This sounds like your app is getting killed by the system because you allocate too much memory. Depending on how much memory you are allocating, it could very well happen that you never see the memory warning methods being called.
Check your app with instruments running and also check the crash report again, it should give you some more details. E.g. a list of processes with rpages, recent_max and (state) columns, with Largest process: shown above. I bet your process is named and also shows the state (suspended), which means: iOS killed it because you allocated too much memory.
I know it's a bit weird but I have no code at all to put here, unless I copy all of it.
My project is crashing with no apparent reason. I've read this solution: iPhone application is crashing and not leaving behind a .crash log file
and I'm using Instrument for searching for leaks and other possibilities for those crashes.
Another strange thing is: even when I run my app with debug on XCode, it just stop to work on my IPad but it looks it is still running.
And the last and more strange thing: there's no crash log at all on my device. Before somebody ask, it is enable to record crash logs.
Does anybody have any idea for helping me?
Regards
I've had this happen to me before on various platforms. If its crashing on you, whether its an iPhone app, openGL / DirectX program, try these steps:
Have you tried to undo your last change and get to the point where it last worked?
Have you tried placing a print outputs to the terminal to see how far your program is executing? Start at the beginning and work your way into your program. This is especially useful when there is no crash log.
Also in particular to iPhone apps: Have you checked your xib's? Did you recently re-factor and change the name of a class maybe? You might need to re-link your nib to your classes. This on more than one occasion has caused apps of mine to crash with no error. Hope this helps.
I doubt you are still wondering about this, but my answer is that you were experiencing your app getting killed by the OS due to using too much memory. This will silently fail in the log in my experience when running on the device.
You will have to go into the Organizer to the device console and crash reports that get stored on the device to see the clues.
The reason your crash stopped when you got an iPad 2 is because the iPad 2 has twice the memory of the iPad 1 (which is dramatically under-stocked with RAM)