Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-5400] NSRecursiveLock dealloced while in use / crash

GitHub Issuen/a
ResolutionCannot Reproduce
Resolution Date2012-02-09T11:25:44.000+0000
Affected Version/sRelease 1.7.2
Fix Version/sn/a
Labelsbranch-5062, crash, tableview
ReporterStephen Tramer
AssigneeStephen Tramer


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.


devlog recursive lock.txt2011-10-01T08:38:31.000+000027888


  1. Stephen Tramer 2011-10-01

    Crash log for the bug report.
  2. Stephen Tramer 2011-10-01

    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.
  3. Stephen Tramer 2011-11-10

    Cannot reproduce in 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.
  4. Thomas Huelbert 2012-02-09

    no way for qe to confirm, closing based on XSteven comments

JSON Source