App crashes after tns debug android --debug-brk and trying to debug with "Step into/over"

[Natalia-Hristova]

Tell us about the problem

Android app crashes when using --debug-brk and try to debug the app in Dev Chrome tools.
Doesn't happen when tne debug android
Happens only for Android.

ActivityManager: Process org.nativescript.DebugApp (pid 9660) has died: vis +99TOP

Please provide the following version numbers that your issue occurs with:

• CLI: rc - 3.4.0-2017-12-12-10244
• Cross-platform modules: 3.4.0-rc-2017.12.8.2
• Runtime(s): 3.4.0-rc-2017.12.6.2

Please tell us how to recreate the issue in as much detail as possible.

1. tns debug android --debug-brk
2. Open Dev Chrome tools URL
3. Click on Step over/into btn

[petekanev]

@Natalia-Hristova I can confirm that behavior, I also managed to isolate the crash to the v8 inspector 'debug' agent code - it would appear that the runtime pauses too early (in the ts_helpers.js script).

One solution would be to force pause after the runtime has executed the aforementioned script, however at this point the breakpoint will occur in a script irrelevant to the user (see image) - the require override logic as implemented in Javascript.

An alternative to the proposal above would be to not force pausing at all, and rely entirely on user-defined in-code breakpoints - debugger; statements. This won't be much more different to what is being done currently, as you can't place gutter breakpoints (clicking next to the line number in the script source explorer in Chrome DevTools).

@Plamen5kov I'd like to know what you think about the problem, and the proposed solutions.

[Plamen5kov]

I'd really like us to have a --debug-brk flag because it's a command valid for both platforms and it's commonly known. The alternative you provided is also a valid one that provides the functionality users will need, but let's brainstorm before committing to anything.

[petekanev]

@Plamen5kov my second proposal does not eliminate --debug-brk - the application will still pause, and wait for the debugger to be attached, it just wont pause in the first script, but rather on the first encountered program breakpoint (debugger;)

[Plamen5kov]

I understand that, but I still find --debug-brk to have a specific behavior that's common knowledge - stop on the first file. I see no problem for the --debug-brk to stop at the require logic, as it is no more known to the user than ts_helpers file.

[petekanev]

@Plamen5kov I would like us to avoid the situation where users are a bit confused, and would come filing bug reports stating that they've started their debug session, and a yellow (usually indicative of warnings - in the case of Chrome DevTools it's how scripts in the virtual machine show up) window opens up in front of their eyes, and they may not know whether to restart the session or to continue their debugging session - to 'Play (F8)'

[Plamen5kov]

You're right, but better to have the flag and break, than to have the flag and do nothing keeping in mind they don't have any debugger statements in the best scenario. I think it's easier to get you can click continue or F8 than, find in our documentation you need to have a debugger statement.
Maybe we can brainstorm for a way to stop on the first user file, not on the first parsed and loaded script?

[petekanev]

@Plamen5kov the proposal came after I tinkered with the code some - moving the pausing logic after ts_helpers, and right before executing the entry-point script, however V8 runs the require override defined in ModuleInternal.cpp, causing the debugger to pause 'on the first script line'.

[Plamen5kov]

@Pip3r4o maybe we can move the inspector client callbacks after the internal module initialization which executes the require wrap logic. The problem I find here is, we'll lose the ability to debug the wrap require logic, which maybe isn't so bad when I think about it.

[petekanev]

@Plamen5kov that might just work! I'll test it out on Monday and let you know how it went!

[petekanev]

@Plamen5kov that did not fix the behavior with pausing inside the requireOverride, the inspector logic inside the runtime::init only attaches certain callbacks to the global object, events happen asynchronously however :-/