[TIMOB-23628] (6_0_X) Android: Unable to debug an application with run-on-main-thread set to true #8429
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…due to messy reading code. Simplified reading of debugger messages.
…debugger client connects it can set breakpoints and options and then resume (so we can actually hit breakpoints as early as the first line of app.js)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #8428
JIRA: https://jira.appcelerator.org/browse/TIMOB-23628
Description:
These are bug fixes for the debugger agent I had to add to our Android SDK wen we updated V8. Please note that merging this does not mean we should resolve the ticket above
The notable changes are:
I fixed up how we parse the incoming messages from Studio (or other client) debuggers. We could end up in a state where we mangled the messages and caused an OutOfMemoryException.
I forced a debug breakpoint at the very beginning of the app's lifecycle. This is so that we can wait until the debugger connects and does it's setup (like sending over all the breakpoints) before we launch into app.js - otherwise we couldn't ever hit "early" breakpoints in the app's execution. Now we can hit a breakpoint as early as the first line of app.js (or technically even in our own bootstrapping code).