Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-16924] iOS: TiViewProxy - An intermittent crash with "Segmentation fault: 11" exception being thrown when launching a Titanium app on iOS 7

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionNot Our Bug
Resolution Date2016-08-04T03:14:57.000+0000
Affected Version/sRelease 3.2.3
Fix Version/sn/a
ComponentsiOS
Labelsqe-3.3.0
ReporterWilson Luu
AssigneeChee Kiat Ng
Created2014-05-06T18:01:57.000+0000
Updated2016-08-04T03:14:57.000+0000

Description

*Details:* From this [QA thread](http://developer.appcelerator.com/question/173862/ios-crash---segmentation-fault-11), the user is experiencing an intermittent crash with "Segmentation fault: 11" exception being thrown when launching a Titanium app on iOS 7 device (see crash.log). According to the user, the bug is occurring in the TiViewProxy.m file (specifically, on the line \[self parentForBubbling\]). Hence, he fixed the issue by applying the fix to the following methods in the TiViewProxy.m file:
-(void)setParent:(TiViewProxy*)parent_
{
    [parent_ retain];
    RELEASE_TO_NIL(parent);
    parent = parent_;
 
    if (parent_!=nil && [parent windowHasOpened])
    {
        [self windowWillOpen];
    }
}
and
-(void)dealloc
{
    RELEASE_TO_NIL(pendingAdds);
    RELEASE_TO_NIL(destroyLock);
    RELEASE_TO_NIL(parent);
    pthread_rwlock_destroy(&childrenLock);
 
    //Dealing with children is in _destroy, which is called by super dealloc.
 
    [super dealloc];
}
*Note:* No Titanium sample code was provided.

Attachments

FileDateSize
crash.log2014-05-06T18:01:57.000+00002466

Comments

  1. Ingo Muschenetz 2014-05-06

    Seems like this might be an easy fix for 3.3.0
  2. Christian Brousseau 2014-09-26

    I can reproduce the issue with 3.3 100% of the time. But the code base on which I am experiencing the issue is too convoluted to isolate one use case to replicate it. But I would be more than willing to test a continuous build that have this fix and (if possible) add as much info as I can.
  3. Christian Brousseau 2014-09-26

    It seems the bug comes from bad practices on the JS side. Here is basically what the defective code does: Say you have a window containing a text field that you want to update the value from another window. (you click on the field, a new window opens with a list of choices, you select an item from the list, the window closes and the field is now updated with the value you selected from the list) The "recommended" way to do it would be to pass a callback function to the popup window so it can be triggered when the user selects an element from the list. But in this case (the one where it crashes) the original developer passed the *actual field* object to the other window. (stored in a local variable for greater readability I guess)) And then, when the user would select the value from the list, it would just set the value from the text field directly from the popup window. Now we close the popup window, it invalidates and frees the memory. *But*, when it tries to free the local variable containing the textfield from the original window, it should technically fail. (I am speculating here) So the code would look something like this (keep in mind that I'm doing this by head)
       var textField = Ti.UI.createTextField();
       
       var popup = require('popup')(textField);
       
       popup.open();
       
       
       function popup(_fieldFromOtherWin) {
         var localVar = _fieldFromOtherWin;
         
         var newWin = Ti.UI.createWindow();
         
         newWin.addEventListener('click', function() {
           // We update the field through the local var
           localVal.text = 'Changed from another window';
           
           // We close the window, and all its children, but what happens to localVar 
           // since it references to the textfield from the other window?
           newWin.close();
         });
       
         return newWin;
       }
       module.exports = popup;
       
       

JSON Source