Reputation: 13511
I've been stuck on this thing for many hours now and I don't know what else to search for.
There's not much I can provide since the debugger doesn't show any errors but it's reproducible--I tap on a very specific item in a table view, the act of which should dismiss that modal, and then my app freezes. That doesn't happen for the other items in the table view--the modal dismisses perfectly and the app goes on.
I checked this answer suspecting that it's a deadlock, however:
layoutSubviews
method and it keeps getting called. It does not call [super layoutSubviews]
, does not call setNeedsLayout
on anyone, and simply sets the frames of its subviews because I'm not using Autolayout.How can I debug this thing? I've been looking around Xcode Instruments but I can't make sense of the data I'm seeing. The System Trace template, specifically, seems capable of stopping right when the freeze occurs, unlike the others which keep on recording.
Added: What I see in System Trace
Upvotes: 1
Views: 1506
Reputation: 13511
@Paulw11's comment helped--the Time Profiler template is better suited for this task than the System Trace instrument.
I used the Time Profiler and got led to a bunch of traces that point to the UINavigationBar as the suspect repetitive caller to my custom UIControl's layoutSubviews
. To further explain my view hierarchy:
Here's the deal: If I alloc-initWithFrame
my custom UIControl
with a frame of CGRectZero
, the app freezes. If I provide a garbage initial value to the frame (which is disregarded anyway since UINavigationBar reshapes my custom UIControl) like CGRectMake(0, 0, 10, 10)
, the crash doesn't happen.
I'm guessing that UINavigationBar gets confused about how to layout a custom title view that has an initial frame of (0, 0, 0, 0)
. Sounds like an Apple bug.
Note: I'm running on iOS 8.2.
Upvotes: 0
Reputation: 1907
Instruments is the tool you want to diagnose the issue. Try inspecting your app with Time Profiler
, performing the task that you were observing to increase CPU usage and then analyze the results, checking Invert Call Tree
and Hide System Libraries
. You can also set time markers if there is a specific time period you are looking to inspect. From here, you can see what calls are sucking up the CPU.
Upvotes: 2