I am developing a live platform using amazon IVS player SDK.
But I have a little problem.
The ui freezing phenomenon occurs intermittently, but it is difficult to debug because the clear call stack is not visible.
I have doubts, but I can't see it as open source.
mainThread callstack
Suspicious thread
The situation is as follows, but my expectation is that "psync_mutexwait" occurs on the "AVSampleBufferDisplayLayer" side on the open source side and freezes.. I am not sure if this is correct.
So, I'm going to do more debugging, but if there is any reason to think about it or any tips for debugging when the call stack is as follows in the state of ui freezing,
Please let me know that knowledge.
thank you.
Use XCode profiler. Go to Product > Profile and select Game Performance. It should help you to detect UI freezes at runtime. Detailed guide here.
Related
I have sometimes app freezing I do not know what is the source of problem.
It happens rarely but happens. I consider how to track such issue
I have crashlytics from firebase but there is no errors as freezing is I suppose something with threads maybe some deadlocks or infinite loops.
Is there way to track such things?
What maybe reasons of app freezing and being inactive (it is SwiftUI app) ?
Are there possibilities to track/profile apps installed on devices (not connected via Xcode) and send informations such that are available in Instrument to something like firebase console or other 3rd party tools.
Update
I think I do not indicated important fact.
It freezes UI definitely not for a few seconds but app need do be killed and restarted again.
There might be some heavy process that locks your main thread, so it freezes your UI.
You track the problems, performance, leaks and more using Instruments.
There are sample topics:
Instruments Tutorial with Swift: Getting Started
How to find and fix slow code using Instruments
And WWDC videos like
Using Time Profiler in Instruments
Creating Custom Instruments
I have experienced some of these weird behaviours before. And mostly the reason behind it was a task that is blocking the main thread making it unresponsive. Pause the app and check the stack trace. Also make sure all your UI operations are done on the main thread. Hope this helps!
Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138
Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.
I'm working on an iPad application and a recent change I made is causing the app to die with "signal SIGTRAP". The stack trace doesn't help and I can't pinpoint what part of the code is causing this to happen (but I do know which function it starts from).
Without going into details about the application I was wondering if there are some general tips for debugging this kind of thing (SIGTRAP)?
I've managed to narrow down which function call causes this to happen. The weird thing is that if I break and step into the function then it works fine. But if I let it run without a breakpoint then it crashes.
The function calls a bunch of other things which also involve asynchronous network connections. I put logs all over my code and all my logs print fine, so it seems something "under the hood" is causing this failure. I'm also using a 3rd party framework which may be causing this issue?
Is this even a code-related issue? I read somewhere that SIGTRAP is a debugger thing.
What causes this kind of crash and where should I be focusing my efforts to fix it?
Any help you can provide is greatly appreciated.
Thanks!
I have an iOS app with some performance issues. In particular, when the user selects an item in a particular Core Data-backed UITableView there's a delay before the UI updates. Since there's very little multithreading in the app at the moment, I'm guessing I'm making a method call somewhere that's taking too long and blocking the UI thread.
Stepping through the code isn't revealing anything to me. (Perhaps because the problem is on another trip through the run loop? Not sure...I'm a solid iOS developer but a novice when it comes to the debugging and profiling tools.)
What's the best way to tackle a problem like this? Some way to step through or trace what the thread is doing in order and how long each call is taking, or something?
Thanks.
Check out the Time Profiler in Instruments. See WWDC 2012 - Building Concurrent User Interfaces on iOS for a practical demonstration of how you can use profiler to identify candidate methods that you might want to put in a background queue to avoid blocking the main queue.
See the Instruments User Guide for a basic description of the Instruments tool, but I think that WWDC video is a more effective way to gain familiarity with this particular instrument, the Time Profiler. Also, if you've never done concurrent Core Data, you might also want to see the Concurrency with Core Data section of the Core Data Programming Guide.
I will second what's Rob said: you will find more easily what's the bottleneck of your app using Time Profiler in Instruments. All references from Rob are good specially the one from WWDC. I also run into this tut in mobile tuts which covers the basics.