Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1627] Breakpoints not working on alloy apps

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2018-11-01T18:59:11.000+0000
Affected Version/sAlloy 1.13.2
Fix Version/sCLI Release 7.0.8
ComponentsTooling
Labelsuser_experience
ReporterSeth Toda
AssigneeFeon Sua Xin Miao
Created2015-08-25T22:40:33.000+0000
Updated2018-11-01T18:59:14.000+0000

Description

Sprint noticed their their break points aren't working on conditions in their alloy apps. I've been able to verify this with my own testing on a fresh application. To clarify (➜ == break point): 
// This will not pause and the inner block runs
➜ if(true){ 
     console.log("hello Jay!"); 
} 

// This will pause 
if(true){ 
     ➜ console.log("hello Jay!"); 
}

Steps to reproduce

1. Create a new alloy app within Appcelerator Studio 2. Add the above if statement with a breakpoint on the conditoin 3. Run in debugging mode

Expected

The code pauses on the if statement and doesn't call console.log()

Actual

The code is ran as if the breakpoint isn't there.

Attachments

FileDateSize
breakpoint2.gif2015-08-26T19:28:33.000+0000203315
native_android.png2015-12-02T00:37:48.000+0000109137
native_android2.png2015-12-02T00:37:48.000+0000109213
Screen Shot 2015-08-25 at 1.18.45 PM.png2015-08-25T22:38:19.000+0000414594

Comments

  1. Seth Toda 2015-08-25

    [~pinnamuri], feel free to let me know if you need anything else from me.
  2. Seth Toda 2015-08-26

    Just found that the breakpoint fails totally on the first build. But the second build works.
  3. Seth Toda 2015-08-31

    [~pinnamuri], any ballpark I could get this scheduled?
  4. Praveen Innamuri 2015-11-03

    [~kkolipaka] Can you take a look into this ?
  5. Kondal Kolipaka 2015-11-03

    Looks like we are ignoring the break points for if conditions where condition value is already known at build time. Please find the snippet below for better understanding. And this happens only for alloy projects for iOS applications. It has to be fixed from iOS SDK end. 
       function doClick(e) {
   	if (OS_IOS && Ti.Platform.model === "Simulator") //break point will hit here
   	{
   		alert("Simulator does not support sending emails. Use a device instead");
   
   		if (true)//break point doesn't hit here
   		{
   			alert("True Condition");
   		}
   		
   		if (false)//break point doesn't hit here
   		{
   			alert("False condition ");
   		}
   		
   		var x = 1;
   		var y = 2;
   		if ((x + y) == 3) //breakpoint will hit here
   		{
   			alert("x+y calc");
   		}
   		
   		var status = true;
   		if (status == true) //breakpoint will hit here
   		{
   			alert("status alert");
   		}
   		return;
   	}
   }
   
   $.index.open();
  6. Chee Kiat Ng 2015-11-25

    Hi. The test sample is *not valid*. 1. There's no sensible reason why anyone would do if(true) 2. I just tested this natively on Xcode. if I write the below native code 
       if (YES) {
       NSLog(@"hello Jay!"); 
   }
    and set the breakpoint at if(YES). The behavior is the same, it *does not pause*, and goes to NSLog(@"hello Jay"); Our debugger actually relies on Xcode Objective C behavior, so there's nothing we can do. But as Kondal has explained above, it makes sense that Xcode ignores the break points for if conditions where condition value is already known at build time. The below native code is valid and the breakpoint will pause on the if statement: 
           int x = 1;
       int y = 1;
       if (x + y == 2)
       {
           NSLog(@"it's working");
       }
    I'm not sure why in this ticket only alloy sees this behavior, but i think the bigger question is, are we seeing problems hitting breakpoints on if blocks that does not do if (true) or if(false). If so, please provide a valid reproducible case here.
  7. Wilson Luu 2015-12-02

    I was able to reproduce this issue i.e: * If I add a breakpoint to if(true) or if(false) in an Alloy app, then the debugger will not hit those breakpoints. * If I add a breakpoint to if(true) or if(false) in a *Titanium classic app*, then the debugger *will hit* those breakpoints. * The two stated above behaviors occur with both iOS simulator *and* Android emulator. Given that the bug behavior appears on Android, I tried setting a breakpoint at if(true) in a native Android project and observed the same behavior that [~cng] saw when debugging in native iOS; see native_android.png and native_android2.png attachments. And to go off of [~cng]'s last comment:

    Is there a legitimate bug when using debugger with Titanium Classic apps?

    Are Alloy apps being debugged properly?

    *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), genymotion emulator (4.4.4)
  8. Angel Petkov 2016-03-30

    Hello [~stoda] , the reason the breakpoint is not hit when placed on the 
    if (true) {
    statement is because if true will always be true. When alloy is ran it generates separate files , so when you're putting a breakpoint studio actually ties it to the equivalent line on the generated files. If something will always be true it won't get added to the files same with any variables that are created but not used. If you put the breakpoint on line underneath on the print statement it will get hit.
  9. Feon Sua Xin Miao 2018-08-29

    PR: https://github.com/appcelerator/alloy/pull/904 Looks like white space between the lines cause source map mismatch. 
       function doClick(e) {
   	alert($.label.text);
   }
   
   
   $.index.open();
   
   
   for (var i = 0; i < 4; i++) {
   	console.log("Hello: " + i); // add breakpoint here
   }
  10. Lokesh Choudhary 2018-09-14

    FR Passed. PR Merged.
  11. Lokesh Choudhary 2018-10-11

    Verified the fix in 7.0.7-master.9. Closing.

JSON Source