Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-19884] iOS: Debug crash when setting breakpoint in alloy model response

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2015-12-14T03:23:47.000+0000
Affected Version/sn/a
Fix Version/sRelease 5.2.0
ComponentsiOS
LabelsTCSupportTriage, alloy, debugger-ios, user_experience, validate
ReporterJason Kotchoff
AssigneeChee Kiat Ng
Created2015-02-03T21:19:44.000+0000
Updated2016-02-16T23:22:22.000+0000

Description

When setting a titanium studio breakpoint in an alloy model response from a sync adapter that fetches remote content, titanium 3.5.0 crashes in iOS. Here is an example alloy project that fetches remote content using a custom alloy model adapter: https://github.com/jkotchoff/alloytest When run in 'debug mode' in Titanium Studio, setting a breakpoint in the alloy model response will crash the app with SDK 3.5.0 and iOS ie. https://github.com/jkotchoff/alloytest/blob/master/app/controllers/index.js#L7 A debug point here works fine in SDK 3.4.1 on iOS and it works fine in Android (SDK 3.4.1 or 3.5.0). This makes debugging titanium apps that render content from a remote server impossible in 3.5.0 on iOS.

Attachments

FileDateSize
iosdebugger_notworking_4.0GA.log2015-07-27T14:15:53.000+000015476
iosdebugger_working_3.4.1GA.log2015-07-27T14:15:53.000+000015853
wluu_chuck_norris.crash2015-11-30T23:00:31.000+0000329454
wluu_circular.crash2015-11-30T23:00:31.000+0000328931

Comments

  1. Jason Kotchoff 2015-02-04

    Note, just before running this test project, you may want to make a single web browser request to: http://sinatra-api-demo.herokuapp.com/endpoint.json in order to spin up the server because heroku will spin it down if it hasn't been hit in awhile and then the http request from titanium may time out.
  2. Praveen Innamuri 2015-07-23

    [~kkolipaka] Can you take a look into this ?
  3. Kondal Kolipaka 2015-07-27

    Please find the attached logs.
  4. Johnson Joseph 2015-08-20

    Any news on this?
  5. Manny Parasirakis 2015-10-07

    This looks like the same thing reported in AC-297. That bug has info as to how to reproduce this issue in 2 lines of code.
  6. Praveen Innamuri 2015-11-06

    The titanium debugger crashes whenever it tries to send message through debugger connection: 
       Thread 5 Crashed:: KrollContext<kroll$1>
   0   com.geoplus.alloytest         	0x0000000104c983ba WTI::StringImpl::utf8ForRange(unsigned int, unsigned int, WTI::ConversionMode) const + 90
   1   com.geoplus.alloytest         	0x0000000104c98568 WTI::StringImpl::utf8(WTI::ConversionMode) const + 24
   2   com.geoplus.alloytest         	0x0000000104c9c579 WTI::String::utf8(WTI::ConversionMode) const + 25
   3   com.geoplus.alloytest         	0x00000001049aa81b TiDebuggerUtils::wtf_string_to_string(WTI::String const&) + 27
   4   com.geoplus.alloytest         	0x00000001049abb80 TiDebuggerUtils::generate_variables(TI::ExecState*, TI::JSObject*, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, TiDebuggerVariableStruct, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, TiDebuggerVariableStruct> > >&, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 272
   5   com.geoplus.alloytest         	0x00000001049ab99e TiDebuggerUtils::generate_variable(TI::ExecState*, TI::TiValue&, TiDebuggerVariableStruct&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 2014
   6   com.geoplus.alloytest         	0x00000001049abd67 TiDebuggerUtils::generate_variables(TI::ExecState*, TI::JSObject*, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, TiDebuggerVariableStruct, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, TiDebuggerVariableStruct> > >&, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 759
  7. Praveen Innamuri 2015-11-10

    [~sdavenport] This ticket doesn't duplicates any other ticket. We still need to investigate the root cause causing the crash of debugging.
  8. Manny Parasirakis 2015-11-10

    The core of the issue as we discovered is that the debugger cannot seem to handle circular references in object graphs. If you create a new Appcelerator mobile project and inside the index.js add these two lines of code before $.index.open() you can reproduce the issue easily: var a = {b:{c:1}}; a.b.d=a; Set a breakpoint on the second line above and then when you hit it, step over and the app being debugged will crash.
  9. Gerald Gurevich 2015-11-11

    I have a contractor working on a time sensitive application and he is completely stopped by this issue. I'm not getting very good information from Appcelerator on this issue. We have 10 minutes of work to do but are unable to use Appcelerator studio to do this work. Hours and hours of time have been lost already. We chose this platform for its flexibility of deployment. We are not seeing that advantage anymore. Can we please get some traction on this issue? We are about 1 week from being forced to move to another platform. If we leave, we won't ever be back. Please be sure to reference back to the AC-297 which is the ticket that we had been watching.
  10. Wilson Luu 2015-11-30

    I am still able to reproduce this issue with the current GA stack. I was able to reproduce with [~mannyp] test case and the original reported bug, which both generated similar crash reports seen by [~pinnamuri]; see [^wluu_circular.crash] for [~mannyp] test case and see [^wluu_chuck_norris.crash] for the original reported bug. Tested on: Appcelerator Studio, build: 4.4.0.201511241829 Appc CLI NPM: 4.2.2 Appc CLI Core: 5.1.0 Arrow: 1.3.22 SDK: 5.1.1.GA Node: v4.2.2 OS: El Capitan (10.11.1) Xcode: 7.1.1 Devices: iphone simulator (9.1)
  11. Wilson Luu 2015-12-01

    Possible valid data point: from what I'm gathering so far, it looks like the debugger cannot handle relatively large JSON objects. In TIMOB-20017 and this original reported bug, the requested JSON do not have any circular reference, but are relatively large if you were to print them out. And in [~mannyp]'s test case, I think that a circular reference JSON is inherently large.
  12. Chee Kiat Ng 2015-12-09

  13. Wilson Luu 2016-02-16

    Closing ticket as fixed. Verified that [~mannyp]'s test case and the original reported test case does not crash if you set a breakpoint on the specified lines. Tested on: Appcelerator Studio, build: 4.5.0.201602132419 Appc CLI NPM: 4.2.3-2 Appc CLI Core: 5.2.0-265 Arrow: 1.7.27 SDK: 5.2.0.v20160216091337 Node: v4.2.4 OS: El Capitan (10.11.3)

JSON Source