[TIMOB-5400] NSRecursiveLock dealloced while in use / crash
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | High |
|---|
| Status | Closed |
|---|
| Resolution | Cannot Reproduce |
|---|
| Resolution Date | 2012-02-09T11:25:44.000+0000 |
|---|
| Affected Version/s | Release 1.7.2 |
|---|
| Fix Version/s | n/a |
|---|
| Components | iOS |
|---|
| Labels | branch-5062, crash, tableview |
|---|
| Reporter | Stephen Tramer |
|---|
| Assignee | Stephen Tramer |
|---|
| Created | 2011-10-01T08:27:50.000+0000 |
|---|
| Updated | 2012-02-09T11:25:44.000+0000 |
|---|
Description
While performing rapid insert (and possibly delete) options of a row, the following error occurs, and the application crashes:
bq. Thu Sep 29 17:18:08 unknown tiapp[19156] : *** -[NSRecursiveLock dealloc]: lock ( '(null)') deallocated while still in use
It appears from the crash log as though an imageview is being deallocated at the same time as a cell is being recycled, possibly indicating underprotection.
Attachments
Crash log for the bug report.
This appears to be a very ugly timing issue, where: - A cell goes into reuse, which causes a view detach of the image view, which then locks the destroy lock for the view proxy - While this is occurring on the main thread, garbage collection is occurring on the JS thread. The image view is "forgotten" at exactly a time allowing its JS object to become unprotected, meaning that the proxy is marked for deallocation. - GC just happens to grab up the object associated with the image view, which deallocates it while the lock is still being held onto, and zeroes out whatever value is in r5 (presumably, the address of the destroyLock object, since this is what's released to nil just before the crash). Something tries to access the r5 register, and crash. This is why blocking insert operations on the main thread [a proposed solution] works - it prevents garbage collection from occurring at the same time as cell reuse, through scheduling shenanigans. Also explains why the issue is intermittent and difficult to reproduce outside of these particular crashes. Knowing that this is the likely cause means that a test to (possibly) reliably reproduce the issue through "poor timing" could be written.
Cannot reproduce in 1.8.0.1.0555dcc. Tested in iPad Simulator, iOS 4.3/5.0. Previously this bug did appear on simulator, leading me to believe that it has been resolved.
no way for qe to confirm, closing based on XSteven comments