{ "id": "100909", "key": "AC-2565", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "12217", "key": "AC", "name": "Appcelerator - INBOX", "projectCategory": { "id": "10000", "description": "", "name": "Customer Service" } }, "resolution": { "id": "1", "description": "A fix for this issue is checked into the tree and tested.", "name": "Fixed" }, "resolutiondate": "2012-10-11T21:28:44.000+0000", "created": "2012-09-12T05:25:47.000+0000", "labels": [ "crash", "history", "ios", "navigationGroup" ], "versions": [], "issuelinks": [], "assignee": { "name": "nsharma", "key": "nsharma", "displayName": "Nikhil Sharma", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2016-03-08T07:41:38.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "14548", "name": "Titanium SDK & CLI", "description": "Please enter tickets related to the MobileSDK here." } ], "description": "I am experiencing an extremely annoying and somewhat spontaneous bug.\r\n\r\nI have a navigation group, and in that navgroup a window with 3 tableviews, each with one or two rows with a label inside. They all lead to new windows opened in that navigation group, loaded with normal CommonJS require statements. Let's call the tableviews T1, T2 and T3.\r\n\r\nT1 leads to a window with another tableview, which again leads to yet another tableview. When I click a row here, among other things, the app returns to the initial window. Since the navigation group does not expose its window stack, I have implemented my own history object:\r\n\r\n\r\nvar close = function(win, navGroup) {\r\n\t'use strict';\r\n\tif (win.ascendent) {\r\n\t\tclose(win.ascendent, navGroup);\r\n\t}\r\n\tnavGroup.close(win);\r\n};\r\n\r\nmodule.exports.close = close; \r\n\r\nNow, when I return to the original window, some strange behavior ensues:\r\n\r\n - if I click T2 or T3, the app MAY crash - but NEVER in the simulator or on an iPhone 4S (and not on an iPhone 3GS either, it seems). It often does on an iPad or an iPod Touch, though, although it seems to do so only after trying a few times.\r\n - if I click T1, GO BACK via the navigation group, and THEN click T2 or T3, it apparently NEVER crashes.\r\n - if I remove the call to the history object - meaning that I manually backtrack from T1 to the main window - it apparently NEVER crashes.\r\n\r\nSo, my theory is that it has something to do with manually closing a window by calling navigationgroup.close instead of letting the user press the back button.\r\n\r\nIf I run the project in XCode, the error I get is \"pointer being freed was not allocated\". I have attached a symbolicated log for your pleasure.\r\n\r\nLet me know if you need more info.", "attachment": [ { "id": "31222", "filename": "JustATool_2012-09-12-123458_Jacob-Avlunds-iPad.crash", "author": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "created": "2012-09-12T05:25:47.000+0000", "size": 30252, "mimeType": "application/octet-stream" } ], "flagged": false, "summary": "iOS: Crash with \"pointer being freed was not allocated\" on certain devices when manually closing windows in a navigation group", "creator": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "subtasks": [], "reporter": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "environment": "iPad (1st version)/iPod touch, iOS 5.1, Titanium 2.1.2GA", "comment": { "comments": [ { "id": "218624", "author": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "body": "By the way, I have not been able to replicate the erroneous behavior in Ti 2.0, so it seems to be introduced recently.", "updateAuthor": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "created": "2012-09-12T05:39:13.000+0000", "updated": "2012-09-12T05:39:13.000+0000" }, { "id": "218711", "author": { "name": "nsharma", "key": "nsharma", "displayName": "Nikhil Sharma", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Jacob, \r\nCould you please provide a reproducible sample test code?", "updateAuthor": { "name": "nsharma", "key": "nsharma", "displayName": "Nikhil Sharma", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-09-12T14:09:33.000+0000", "updated": "2012-09-12T14:09:33.000+0000" }, { "id": "223169", "author": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "body": "I've tried, but to no avail, and apparently the behavior seems to be fixed in 2.1.3. I suggest we close this issue.", "updateAuthor": { "name": "avlund", "key": "avlund", "displayName": "Jacob Avlund", "active": true, "timeZone": "Europe/Berlin" }, "created": "2012-10-11T21:19:30.000+0000", "updated": "2012-10-11T21:19:30.000+0000" }, { "id": "223176", "author": { "name": "nsharma", "key": "nsharma", "displayName": "Nikhil Sharma", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Fixed in 2.1.3.GA", "updateAuthor": { "name": "nsharma", "key": "nsharma", "displayName": "Nikhil Sharma", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-10-11T21:28:44.000+0000", "updated": "2012-10-11T21:28:44.000+0000" } ], "maxResults": 4, "total": 4, "startAt": 0 } } }