[TIMOB-23726] iOS: Debugger for Alloy project hangs on Device with run-on-main-thread enabled
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | Critical |
|---|
| Status | Closed |
|---|
| Resolution | Invalid |
|---|
| Resolution Date | 2016-08-25T02:13:20.000+0000 |
|---|
| Affected Version/s | Release 5.4.0 |
|---|
| Fix Version/s | n/a |
|---|
| Components | iOS |
|---|
| Labels | needs-5_5_X-Backport, qe-5.4.0, regression |
|---|
| Reporter | Harry Bryant |
|---|
| Assignee | Angel Petkov |
|---|
| Created | 2016-08-04T00:19:53.000+0000 |
|---|
| Updated | 2017-03-20T21:26:43.000+0000 |
|---|
Description
Running an Alloy project in Debug mode to Device causes the app to hang on "The Debugger is waiting for you to launch the app on your device".
*This is a Regression from 5.3.0.GA*
The hang does not occur on simulator.
The hang does not occur for a classic titanium mobile project.
The hang does not occur with run-on-main-thread disabled.
Steps to Reproduce
1. Create a new Default Alloy Project.
2. Add breakpoints to the project, preferably in the index.js file.
3. Ensure that your iOS device and Computer are connected to the same WiFi Network.
4. Run the app to an iOS device in Debug mode.
Actual Result
Device and Studio hangs on "Waiting for Debugger to Connect"
Expected Result
Device and Studio should not hang.
Attachments
[~htbryant] Is this with run-on-main-thread enabled or disabled? And I need to know if this is a regression.
[~cng] Edited the above description, it only occurs when run-on-main-thread is enabled. Checked for regression, 5.3.1.GA is affected but 5.3.0.GA works fine.
Additionally, tested with run-on-main-thread enabled with 5.3.0.GA and was able to reproduce the same behaviour as that of 5.4.0
Additional findings: This only happens specifically in one scenario. Hangs on device with run-on-main-thread enabled. Doesn't matter if it's alloy or classic. And it doesn't happen on simulator.
[~htbryant] I can't reproduce it. with this environment: APPC CLI 5.4.0-31 Titanium SDK 5.4.0.v20160802165655 iPhone 6S Plus device Alloy project run-on-main-thread true I did get it stuck once, on a classic project on device. But when i came back to revisit it, it worked again.I'm suspecting that this 'hanging' issue is unrelated to run-on-main-thread. Even when i visit the debugger code, there seems to be at no point it makes any distinguishing between device and simulator code for run-on-main-thread. Can you retry a few more times? And probably come up with an accurate matrix of combination of environments that can reproduce it consistently?
[~cng] After reinvestigating this issue, I've found a consistent pattern with the Debugger hang: !screenshot-2.png! It seems that with run-on-main-thread set to
TRUEin a 5.4.0 SDK built app, the debugger will function correctly upon a fresh build, but will hang on subsequent builds. when run-on-main-thread is set toFALSEin a 5.4.0 SDK built app, clean and subsequent builds will not hang. Tested On: iPhone 6S (9.3.4) Device Mac OSX El Capitan 10.11.6 Ti SDK: 5.4.0.GA Appc Studio: 4.7.0.201607250649 Appc NPM: 4.2.7 App CLI: 5.4.0-31 Xcode 8.0 beta 6 (8S193k) Node v4.4.7GRRRRR. I can't reproduce this. APPC CLI 5.5.0-1 Titanium SDK 5.4.0.v20160802165655 iPhone 6S Plus device APpc NPM: 4.2.7 Xcode 7.3.1 Node v4.2.2 Studio 4.7.0.201607250649 BUT. one thing i did realise was, i was able to reproduce consistently using Node 0.12.7, or was it 0.10.40. because i forgot to set it back to 4.2.2 when testing some other PRs.
GRRRR. I tried again with an environment much more similar to yours: iPhone 6S Plus (9.3.4) Device Mac OSX El Capitan 10.11.6 Ti SDK: 5.4.0.v20160802165655 Appc Studio: 4.7.0.201607250649 Appc NPM: 4.2.7 App CLI: 5.4.0-31 Xcode 7.3.1 Node v4.4.7 And i run a 2nd a 3rd and it's still wooooorking.
So after a full investigation of this issue using 5_5_X components, it was found that the debugger will hang on device with the "Waiting for Debugger to Connect" alert when setting a breakpoint at $.index.open(). _(or win.open() for classic)_ However once you press the "resume" button the alert is dismissed and debugging can continue as normal. It was determined that due to the implementation of main thread (5.4.0), there was an issue with the alert being dismissed correctly, as it was being run on an another thread.
Since debugger works as per normal, stopping at the breakpoints, I'll be resolving this ticket as invalid. the "Waiting for Debugger to Connect" only stays there if the breakpoint is set at $index.open().
Closing ticket as invalid.