Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1593] Android Debugger: Some breakpoints not hit if "Resume" is done anytime during debug

GitHub Issuen/a
TypeBug
PriorityNone
StatusResolved
ResolutionFixed
Resolution Date2017-12-07T20:56:23.000+0000
Affected Version/sAlloy 1.10.8
Fix Version/sCLI Release 7.0.0
ComponentsAppcelerator Studio, Titanium SDK
Labelsn/a
ReporterSatyam Sekhri
AssigneeChristopher Williams
Created2017-11-30T10:24:48.000+0000
Updated2017-12-08T15:21:22.000+0000

Description

Comments

  1. Abir Mukherjee 2017-12-06

    We saw this issue during smoke tests. This is the environment: Node Version: 8.9.1 NPM Version: 5.5.1 Mac OS: 10.13.1 Appc CLI: 7.0.0-master.56 Appc CLI NPM: 4.2.11-4 Titanium SDK version: 7.0.0.v20171130091945 Appcelerator Studio RC 5.0.0.201712050945 Android 7.1.2 In my test case, I created a default alloy app, and placed a breakpoint in the doClick function. When the app was launched, it was stopped at the splash screen. When I clicked "Resume", it did not stop at the breakpoint I created.
  2. Christopher Williams 2017-12-06

    So to help further tease out the root cause here. I tested an alloy app using Chrome DevTools (as described here: https://wiki.appcelerator.org/display/DB/Debugging+Android+Apps+with+3rd-party+Tools) And that worked fine. So this is definitely a Studio issue, not an SDK/debugger issue. The next step is to determine if this only affects Alloy apps, or also affects classic apps. If it's Alloy only, then the most likely cause is that Studio is mishandling the source mapping from the original source JS to the generated files from Alloy's compilation process.
  3. Christopher Williams 2017-12-06

    I should also note that I see above that this was found on an Android device. It's possible it may not be a classic app vs alloy app issue, but a device vs simulator issue. Once we can login to production again, we should test alloy vs classic on simulators and see if that's the breaking difference (and if not, try simulator vs device).
  4. Abir Mukherjee 2017-12-07

    I tested on device and found that the breakpoints are hit with a classic app. The app I used is the following.The breakpoint was in the event listener, which was in the same place as was in the Alloy app. 
       var win = Ti.UI.createWindow({
       backgroundColor : 'white'
   });
   
   var myLabel = Ti.UI.createLabel({
       text : 'Hello World',
       top : 250
   });
   win.add(myLabel);
   
   var myButton = Ti.UI.createButton({
       title : 'My Button',
       top : 300,
       width : 300,
       left : 10
   });
   win.add(myButton);
   
   myButton.addEventListener('click', function(e){
       alert('My Button Clicked');     // *** breakpoint is here
   });
   
   win.open();
    It does appear that the issue is with Alloy.
  5. Prashanth Pedduri 2017-12-07

    Production logins seem to work now. I verified Android debugger using both Alloy and Classic apps., here is what I found. || App || Simulator || Device || | Classic | Works | Works | | Alloy | Does't work | Doesn't work | I noticed that, for alloy App, the line numbers for breakpoints being hit are not matching the ones that debugger should hit. Basically, while V8InspectorDebugTarget tries to add a breakpoint, the line numbers are being tweaked to lessen a number (Since JSCore operates on zero based index). *Source*: https://github.com/appcelerator/titanium_studio/blob/development/plugins/com.axway.inspector/src/com/axway/inspector/model/InspectorDebugTarget.java#L250 *What could be a probable fix?* Either within InspectorDebugTarget.java or within V8InspectorDebugTarget.java identify if the app is of type alloy and do not reduce line number. [~cwilliams], Please let me know your thoughts around this. *Edit*: If we have to fix this within InspectorDebugTarget.java, we need to clearly differentiate between android-alloy and ios-alloy apps and not deduct line number by 1 for only the all breakpoints except the one which starts with $.index.open(). This approach seems tricky and I'm not certain if this is correct way of dealing with android-alloy apps. The mapping seems perfect to me, as the same mapping works fine for iOS apps.
  6. Christopher Williams 2017-12-07

    Are you certain they're all just "off by one"? Seems odd to me that we'd be off by one - except for $.index.open(); I suspect that the source mapping is just not right for Alloy apps with Android and that may manifest itself in some cases with being off by one (but is likely off by varying numbers depending on the breakpoint).
  7. Christopher Williams 2017-12-07

    So, I see the exact same behavior for Android and iOS with the same app. Looking at the generated source mapping, it's just mis-mapping the results. My input index.js is: 
       var i = 0;
   function doClick(e) {
   	i++;
       alert($.label.text);
   }
   
   $.index.open();
    I'm setting breakpoints at lines 1, 4, and 7. Lines 1 and 7 map correctly. Line 4 maps to the i++; line in the generated file. I verified that the npm package source-map also reads the map file the same way and gets the same results. So my best guess here is that the generated mappings from Alloy can be incorrect.
  8. Christopher Williams 2017-12-07

    https://github.com/appcelerator/alloy/pull/860
  9. Feon Sua Xin Miao 2017-12-07

    Fixed in alloy@1.10.10, CLI 7.0.0-master.57

JSON Source