John Porto
c81a3c5242
Summary: The RN Hermes Inspector keeps a mapping of pageId to Connection. This mapping is created in the call to enableDebugging. Later, when disableDebugging is invoked, the inspector will iterate over the pageId to Connection map to find which page to is being disabled. The DecoratedRuntime enables debugging on construction, and disables on destruction. When disabling debugging, the DecoratedRuntime then passes the "naked" hermesRuntime, which in turn gets checked against all connections' runtimes. It turns our that ```HermesExecutorRuntimeAdapter::getRuntime``` returns the runtime **wrapped** by the DecoratedRuntime, and not hermesRuntime itself. This means that no connections match the request for disabling debugging. Which means the Connection never gets deleted, which in turns keep its underlying adapter (in this case, the ```HermesRuntimeExecutorAdapter```) alive, which has a shared_ptr to the runtime wrapped by the DecoratedRuntime. Other than effectively leaking this connection (and thus the runtime), this also causes an issue when the app tries to re-load the page -- at which point the inspector will remove the old entry from the page to connection mapping, thus initiating the destruction of the (leaked) Runtime in a thread other than the thread that created the runtime. Changelog: [Internal] Reviewed By: javache Differential Revision: D37809467 fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24
hermes-inspector provides a bridge between the low-level debugging API exposed by Hermes and higher-level debugging protocols such as the Chrome DevTools protocol.
Targets
- chrome: classes that implement the Chrome DevTools Protocol adapter. Sits on top of classes provided by the inspector target.
- detail: utility classes and functions
- inspector: protocol-independent classes that sit on top of the low-level Hermes debugging API.
Testing
Tests are implemented using gtest. Debug logging is enabled for tests, and you can get debug logs to show even when tests are passing by running the test executable directly:
$ buck build //xplat/js/react-native-github/ReactCommon/hermes/inspector:chrome-tests
$ buck-out/gen/js/react-native-github/ReactCommon/hermes/inspector/chrome-tests
[...]
You can use standard gtest filters to only execute a particular set of tests:
$ buck-out/gen/js/react-native-github/ReactCommon/hermes/inspector/chrome-tests \
--gtest_filter='ConnectionTests.testSetBreakpoint'
You can debug the tests using lldb or gdb:
$ lldb buck-out/gen/js/react-native-github/ReactCommon/hermes/inspector/chrome-tests
$ gdb buck-out/gen/js/react-native-github/ReactCommon/hermes/inspector/chrome-tests
Formatting
Make sure the code is formatted using the hermes clang-format rules before committing:
$ xplat/js/react-native-github/ReactCommon/hermes/inspector/tools/format
We follow the clang format rules used by the rest of the Hermes project.
Adding Support For New Message Types
To add support for a new Chrome DevTools protocol message, add the message you want to add to tools/message_types.txt, and re-run the message types generator:
$ xplat/js/react-native-github/ReactCommon/hermes/inspector/tools/run_msggen
This will generate C++ structs for the new message type in
chrome/MessageTypes.{h,cpp}.
You'll then need to:
- Implement a message handler for the new message type in
chrome::Connection. - Implement a public API for the new message type in
Inspector. This will most likely return afolly::Futurethat the message handler in (1) can use for chaining. - Implement a private API for the new message type in
Inspectorthat performs the logic in Inspector's executor. (Inspector.cpp contains a comment explaining why the executor is necessary.) - Optionally, implement a method for the new message type in
InspectorState. In most cases this is probably not necessary--one of the existing methods inInspectorStatewill work.
For a diff that illustrates these steps, take a look at D6601459.
Testing Integration With Nuclide and Apps
For now, the quickest way to use hermes-inspector in an app is with Eats. First, make sure the packager is running:
$ js1 run
Then, on Android, build the fbeats target:
$ buck install --run fbeats
On iOS, build the //Apps/Internal/Eats:Eats target:
$ buck install --run //Apps/Internal/Eats:Eats
You can also build Eats in Xcode using arc focus if you prefer an
IDE:
$ arc focus --force-build \
-b //Apps/Internal/Eats:Eats \
cxxreact //xplat/hermes/API:HermesAPI //xplat/hermes/lib/VM:VM jsi \
jsinspector hermes-inspector FBReactKit FBReactModule FBCatalystWrapper \
//xplat/js:React //xplat/js/react-native-github:ReactInternal
For all the above commands, if you want to build the inspector -O0 for better
debug info, add the argument --config hermes.build_mode=dbg.
You should then be able to launch the app and see it listed in the list of Mobile JS contexts in the Nuclide debugger.