Random crashes in iOS simulator

Since switching from Ti SDK 1.6.2 to 1.7.x I have been experiencing seemingly random application crashes with the following stack trace.

Thread 4 Crashed:
0   myapp               0x002633cb TiObjectSetProperty + 107 (APICast.h:75)
1   myapp               0x00040685 -[KrollObject noteObject:forTiString:context:] + 357 (KrollObject.m:1304)
2   myapp               0x0003cbbf KrollGetProperty + 833 (KrollObject.m:481)
3   myapp               0x002663bf TI::TiCallbackObject<TI::TiObject>::getOwnPropertySlot(TI::TiExcState*, TI::Identifier const&, TI::PropertySlot&) + 467 (TiCallbackObjectFunctions.h:139)
4   myapp               0x002444ba TI::TiValue::get(TI::TiExcState*, TI::Identifier const&, TI::PropertySlot&) const + 210 (TiObject.h:387)
5   myapp               0x00241ab6 cti_op_get_by_id_generic + 86 (JITStubs.cpp:1094)
6   ???                 0x0b5ec410 0 + 190759952
7   myapp               0x001ff4c2 TI::Interpreter::execute(TI::ProgramExecutable*, TI::TiExcState*, TI::ScopeChainNode*, TI::TiObject*, TI::TiValue*) + 648 (JITCode.h:84)
8   myapp               0x001ceef4 TI::evaluate(TI::TiExcState*, TI::ScopeChain&, TI::SourceCode const&, TI::TiValue) + 388 (Completion.cpp:67)
9   myapp               0x00248cd9 TiEvalScript + 297 (TiBase.cpp:61)
10  myapp               0x000324dc -[KrollBridge evalFileOnThread:context:] + 1470 (KrollBridge.mm:418)
11  myapp               0x000351a2 -[KrollInvocation invoke:] + 118 (KrollContext.mm:97)
12  myapp               0x00034419 -[KrollContext invokeOnThread:method:withObject:callback:selector:] + 187 (KrollContext.mm:896)
13  myapp               0x0002fb59 -[KrollBridge evalFile:callback:selector:] + 97 (KrollBridge.mm:440)
14  myapp               0x00031df4 -[KrollBridge didStartNewContext:] + 1902 (KrollBridge.mm:570)
15  myapp               0x00036a73 -[KrollContext main] + 2445 (KrollContext.mm:1054)
16  Foundation          0x006aad4c -[NSThread main] + 81
17  Foundation          0x006aacd8 __NSThread__main__ + 1387
18  libSystem.B.dylib   0x926c9259 _pthread_start + 345
19  libSystem.B.dylib   0x926c90de thread_start + 34

This is sometimes caused by something as trivial as adding a line of log code (Ti.API.log()). Commenting it out makes the app run again.

Any pointers as to what is causing this?

My environment (this also happened with Xcode 3.2.5 and iOS SDK 4.x:

Xcode 4.2
iOS SDK 5
Ti SDK 1.7.3
OSX 1.6.8

3 Answers

To give some sort of answer here …. There was another post on this yesterday, where nothing was resolved but the random code breaking occurred.

I have come across exactly the same and I think it is down to the javascript interpreter getting slightly confused. No evidence of this.

It is really random and sometimes just putting a blank line in resolves the issue.

What I think needs to happen is Appcelerator made aware, which I can do I will get the two Q&A's and send them to the support team and see what they make of it.

If ou could post a little code which works and fails randomly that would be great.

T.
— answered October 27th 2011 by Trevor Ward
permalink

4 Comments
- Email sent to appcelerator about this now, will see what they say
  
  — commented October 27th 2011 by Trevor Ward
- We encountered this major problem before when converting from 1.6.2 to 1.7.X. We ended up having to rewrite about 50% of the coding for better stability and less random crashes.
  
  You can always try one of the continuous builds to see if they help with the random crashes.
  
  — commented October 27th 2011 by Vinh Bui
- @Trevor, thanks! The discussion you saw yesterday was probably one with a comment by me. I posted that here as well.
  
  @Vinh, could you please elaborate on rewrite 50% of the code. I am following the single context model presented in Twitanium. I thought that is the currently recommended approach.
  
  — commented October 27th 2011 by Henning Glatter-Gotz
- I am starting to wonder if this this is a race condition of some sort. As I mentioned earlier, adding a single call to something like
```
Ti.API.log('');
```
  will make the app work again. The only thing I can guess is that it is changing the timing of what executes in the underlying native code.
  
  The following snippet is what I am dealing with at the moment.
  - Read object from Ti.App.Properties (via wrapper)
  - Fetch data from a local database
  - Add properties to existing objects
  - Read boolean value from Ti.App.Properties
  - There is NO XHR in this code
  Having the code in exactly this form results in an application crash in the simulator.
```
// Ti.API.log('1');
            prefs = clg.preferences.read(clg.appVersion, 'main');
            searchFilters = {};
// Ti.API.log('2');

            if (!prefs.basicSearch.showMan) {
                searchFilters.includeRecordType = [clg.db.recType.X, clg.db.recType.Y];
            }
// Ti.API.log('3');

            data = clg.db.getSearchResults(searchFilters);
            tableRows = {
                rows:[],
                index:[]
            };
// Ti.API.log('4');

            if (prefs.basicSearch.showSlots) {
                lensLayout = {
                    slots:{
                        slot1:{label:'AA:', key:'aa'},
                        slot2:{label:'BB:', key:'bb'},
                        slot3:{label:'CC:', key:'cc'}
                    }
                };
            } else {
                lensLayout = {slots:false};
            }
// Ti.API.log('5');

            manufacturerLayout = {slots:false};
            useGradient = Ti.App.Properties.getBool(clg.props.useSearchRowGradient);
// Ti.API.log('6');
```
  Uncommenting ANY ONE of the
```
Ti.API.log('#');
```
  lines causes the app to run fine.
  
  [Insert Profanity of your choice here]!?!?!??!
  
  — commented October 27th 2011 by Henning Glatter-Gotz
0 Votes
This is a really critical bug that I also have very often and randomly.

Simulator seems to crash more frequently with this stack error than real device.

Uncommting Ti.API.log('xxx') and Ti.API.info('xxx') seems to help a little bit, but this can't be the solution.
— answered October 29th 2011 by Danny Pham
permalink

13 Comments
- Danny,
  
  The commenting and uncommenting of log code is definitely not a solution. I simply mentioned this as an illustration of what I think is some sort of timing issue with the underlying native app that gets built by Ti.
  
  The fact that I can never reproduce this in the debugger, adding seemingly irrelevant code stops/causes the crashes and Appcelerator staff cannot reproduce things like this even with code that is provided, for me points to a problem that can be observed with multi-threaded apps that have some kind of bug (race condition, resource starvation, deadlock). These are unfortunately very hard to find.
  
  Adding a line of logging code, changes the timing of when certain things get executed. The same goes for the debugger. Running something in the debugger changes the timing and is probably the reason that it cannot be reproduced.
  
  Now, why others don't see the same behavior even when they run the same code in the "same" development environment is a bit tricky to answer.
  
  Anyway, I have spent too much time trying to debug this when it happens (several times over the last few months) and every time it leads nowhere.
  
  From past experience with multi threaded systems, this looks like a timing issue to me.
  
  Just my two cents.
  
  Since I did not see any of this in 1.6.2 I am about to through out 1.7.x.
  I did try a 1.7.4 nightly build as well as a 1.8 build and have not seen the problem yet.
  
  Would be nice to get a comment from the Appcelerator folks on this. I opened this (TC-342) issue on the 27th, but have not seen any action on it yet.
  
  — commented October 31st 2011 by Henning Glatter-Gotz
- So 1.7.4 beta works for you with less crahs?
  
  — commented October 31st 2011 by Danny Pham
- At the moment yes. But I do not read too much into this at this point. Switching from 1.7.2 to 1.7.3 also "fixed" the problem at hand only to have it show up later in some other place.
  
  — commented October 31st 2011 by Henning Glatter-Gotz
- I am currently switching to a single context tabbed application. Hope that this approach will run more stable. Do you use multiple contexts?
  
  — commented October 31st 2011 by Danny Pham
- I am following the Tweetanium single context model, which solved a lot of problems (but not this one). I can also recommend taking a look at the TitanTricks app. There are some really good things in there as well.
  
  — commented October 31st 2011 by Henning Glatter-Gotz
- Thanks for this link.
  
  In my multi context app I am using in app.js:
```
Ti.App.appData = {
    dbName: 'myApp',
    dbVersion: 'v0_38',
    dbInitFile: 'myApp.db'
};

Ti.App.dbConn = Ti.Database.install(Ti.App.appData.dbInitFile, Ti.App.appData.dbName + '_' + Ti.App.appData.dbVersion);
```
  Now I have read that is a no-go to set global stuff using Ti.App.*
  
  I leave the database open and execute sql statement in other windows with Ti.App.dbConn.execute('…').
  
  Maybe this is the main problem with random crashes?
  
  — commented October 31st 2011 by Danny Pham
- I initially tried the Ti.App.mystuff route too, but the model in Tweetanium is better.
  
  For database access take a look at this ORM. Xavier also gave a talk at Code Strong. The video is available here.
  
  Saw your comment on the 1.7.4 announcement … bummer!! Seems like there need to be a few more bug fix iterations without adding new features. Would be nice to finally get something stable.
  
  — commented October 31st 2011 by Henning Glatter-Gotz
- Tweetainium doesn't seem to avoid memory leaks as it loads everything in memory on startup right? The Commonjs approach seems better, above all I still want to use tabgroups.
  
  — commented November 1st 2011 by Danny Pham
- SDK 1.7.5 doesn't seem to solve this problem :-(
  
  @Henning: dou you found any workaround yet?
  
  — commented November 3rd 2011 by Danny Pham
- Danny,
  
  Unfortunately not. I have been working on the backend of my app and am hoping that there will be some sort of response from Appcelerator. But the ticket I opened has had no movement in a week now.
  
  — commented November 3rd 2011 by Henning Glatter-Gotz
- Seems like I have to downgrade to SDK 1.6.2 until this bug is resolved. With this SDK everything works fine in your app? So what are the major disadvantages of SDK 1.6.2?
  
  — commented November 3rd 2011 by Danny Pham
- @Danny, I never experienced this problem with 1.6.2. If I recall 1.6.2 had XHR issues. Something really nice in 1.7 is also the ability to catch database exceptions.
  
  — commented November 5th 2011 by Henning Glatter-Gotz
- How do you catch database exceptions? With try and catch?
  
  I think I have found a workaround to solve this bug. I have noticed that in a for-loop while processing arrays or objects that inherits TI proxy elements, the used memory seems to freeze / block other processes and so the app crash with bus signal error 10.
  
  What I have done is a looping with delayed sequences (each setTimeout 10ms) and thus seems to allow other memory processes to get released or unblocked. Not an ideal solution, but it works for me. My app doesn't crash anymore (as far as I have noticed) and the delay is only slightly.
  
  — commented November 6th 2011 by Danny Pham
0 Votes
1.6.x has also serious memory problems. Seems like 1.8.0 solves the crashes, but unfortunately it is not stable enough to publish a public app with this SDK.
— answered November 5th 2011 by Danny Pham
permalink

1 Comment
- sorry, should be a follow-up to a comment and not a new answer. I can't delete posts here?
  
  — commented November 5th 2011 by Danny Pham
0 Votes

Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Random crashes in iOS simulator

3 Answers