IOS: A collection of problematic crash issues in projects

A collection of problematic crash issues in the project

　　

　　IOS app run encounter crash situation believe that everyone has encountered, development and test encountered may be very convenient way is to directly take the device connected, and then use the tool that Xcode comes with can parse out the crash address. For the online app runtime crash collection also has a lot of good third-party tools, is representative of Crashlytics, by packaging when uploading dsym files, collected crash can be parsed into a readable format.

Although the Crashlytics function is already very powerful, the statistics of the crash information is enough detailed, there will be some difficult problems, such as the program directly hanging in the main function, the rest is the system call. Here's a chat about some of the toughest crash we've encountered in our app:

1, multiple pop-up alertview problems existed

In our app there are some places because the business will pop up some two confirmation box, when the pop-up alertview switch to the background, and then cut to the foreground, the Quick Click Trigger Two confirmation action, will pop up a alertview, click on the Alertview, The alertview that have been ejected before will be restored, and then the program will crash off. When the iphone uses the same steps to verify the problem and finds it impossible to reproduce, every time the program is cut back to the foreground, the Alertview site recovers quickly, so the problem is that the ipad will only exist.

Normally when the program is back to the background, the system will automatically hide the Alertview, until the next time the program switches to the foreground, if the Alertview before exiting, the system will restore the Alertview display. The problem arises here, when the system recovers Alertview's display with a delay rather than immediate recovery. At this time, if the first shutdown time, pop-up new Alertview, will damage the scene of the interruption, resulting in a program running state anomalies, and then the operation may be crash off.

There were two solutions to this problem:

A, the popup layer to do the default action before the program back to the background

b, the program set the flag, identify whether the current has popped alertview, if it has been ejected, then the operation will not eject Alertview

The first method, there are some problems, because some interface Alertview pop-up, click the default action may affect the view level, so from the back of the background when the field interface changes, will create unnecessary confusion for users.

The second method, add a tag bit inside the base class of the apps, set the popup Alertview to Yes, and turn off Alertview to No. If the current app pops up Alertview, the next action will no longer trigger the popup Alertview, which will prevent the crash problem from quickly clicking when the program is cut back from the background.

2. Crash problems caused by WebView animation

During the execution of the automated testing process, there were several crash, unable to find a fixed repro step, the crash stack is as follows:

Exception type:exc_bad_access (SIGSEGV) Exception codes:kern_invalid_address at 0x00000008crashed thread:0thread 0 nam E:dispatch queue:com.apple.main-threadthread 0 crashed:0 LIBOBJC. A.dylib 0x390b15b0 objc_msgsend + 161 UIKit 0x33289182-[_uiwebviewscrollviewdeleg Ateforwarder forwardinvocation:] + 1382 corefoundation 0x31218616 ___forwarding___ + 6223 CoreFoundatio N 0x3116ff64 _cf_forwarding_prep_0 + 204 UIKit 0x330d40c2-[uiscrollview _getdele Gatezoomview] + 985 UIKit 0x330d3fc0-[uiscrollview _zoomscalefrompresentationlayer:] + 246 UI Kit 0x330d9fec-[uiwebdocumentview _zoomeddocumentscale] + 567 UIKit 0x3 30d6ae8-[uiwebdocumentview _layoutrectforfixedpositionobjects] + 1008 UIKit 0x3327b292-[uiwebd Ocumentview _updatefixedpositionedobjectslayoutrectusingwebthread:synchronizE:] + 389 UIKit 0x330dc6d4-[uiwebdocumentview _updatefixedpositioningobjectslayoutafterscroll] + 2410 UIKit 0x330dc6b0-[uiwebbrowserview _updatefixedpositioningobjectslayoutafterscroll] + 521                         1 UIKit 0x330dc566-[uiwebdocumentview _restorescrollpointforce:] + 50212 UIKit 0X330DC25C-[uiwebdocumentview _resetfornewpage] + 40813 UIKit 0x330a84c4-[uiwebdocument  View Layoutsubviews] + 7214 UIKit 0x330217fe-[uiview (calayerdelegate) Layoutsublayersoflayer:] + 25415 quartzcore 0x32dcbd86-[calayer layoutsublayers] + 21016 Quartzcore 0X32DCB 924 ca::layer::layout_if_needed (ca::transaction*) + 45617 Quartzcore 0x32dcc858 ca::layer::layout_and_ Display_if_needed (ca::transaction*) + 1218 Quartzcore 0x32dcc23e ca::context::commit_transaction (CA::T ransaction*) + 23419 QuArtzcore 0x32dcc04c ca::transaction::commit () + 31220 UIKit 0x330278e6 _afterc Acommithandler + 12221 corefoundation 0x311eb6ca __cfrunloop_is_calling_out_to_an_observer_callback_functi on__ + 1822 corefoundation 0x311e99bc __cfrunloopdoobservers + 27223 corefoundation 0x311e                9d12 __cfrunlooprun + 73824 corefoundation 0x3115ceb8 cfrunlooprunspecific + 35225 corefoundation                         0X3115CD44 Cfrunloopruninmode + 10026 graphicsservices 0x34d262e6 gseventrunmodal + 7027 UIKit   0X330722FC Uiapplicationmain + 111628 MyApp 0x0000fc60 Main (main.m:15) 29 Libdyld.dylib 0x394edb1c start + 0

　　Crash stack at a glance, hanging on the system's API calls, and then a closer look at the report exc_bad_acess error, should be the object is released after the wild pointer call problem. Take a closer look at where the apps are called to WebView, and there's nothing wrong with how to use them. A search on the internet found that the problem may be due to webview in the animation, the holder (VC) has been released caused.

Workaround: The WebView delegate empty operation was added before all objects holding WebView were released.

　　Tableview,scrollview also encountered webview similar problems in automated testing, so protection was done in the relevant areas of the program, and then the problem did not occur in automated tests.

a little feeling: Get crash stack, a look is hanging in the system call, estimated that do not want to spend time to solve. Sometimes hold on, look a little more, think about it, try to search Google on some of the fields of crash information, perhaps others have encountered the same or similar problems, may be inspired to solve a seemingly impossible problem.

Note:smileevday reserves all rights to this article

　　Reprint please the source of the famous source

This article is always updated during the development process, welcome to Exchange

IOS: A collection of problematic crash issues in projects