Summary:
`getStackTracesTreeNodeForAlloc` only works for memory that was tracked with `newAlloc`.
For now, that is only memory that goes through GC APIs.
Various places were calling this function on native memory which was allocated
with `malloc`, not GC memory. This led to SIGSEGV on nullptr when trying to take heap profiles
of these objects.
`newAlloc` could, in theory, work with native memory as well. But building out support for that
is outside the scope of this fix.
Changelog: [Internal]
Reviewed By: jbower-fb
Differential Revision: D21667842
fbshipit-source-id: 8403a6668e5ec607972ce6819f78fedb89da3f37
Summary:
This call is used to continue execution when the app has just been
started in a "wait for debugger" mode. This is the only case
in which it has an effect.
Notably, it should do nothing in the following cases, which a layperson
may be tempted to classify as "WaitingForDebugger":
* The app was running detached and hit a 'debugger;' statement
* The app is paused because of a breakpoint or hitting the Pause button
* The app stopped on an instrumentation breakpoint, and expects
the debugger to collect data and potentially auto-resume.
Changelog: [Internal] Add Hermes support for Debugger.runIfWaitingForDebugger
Reviewed By: mhorowitz
Differential Revision: D21557446
fbshipit-source-id: 790cec7444ddc61908d2ef9d92e4649b535d678f
Summary:
This diff adds support for the "beforeScriptWithSourceMapExecution" instrumentation
breakpoint via "Debugger.setInstrumentationBreakpoint".
CDP describes it as a breakpoint, but we just set a flag in the inspector. A
fake breakpoint ID is synthesized for optional removal later.
Changelog: [Internal] Add Debugger.setInstrumentationBreakpoint to Hermes Inspector
Reviewed By: mhorowitz
Differential Revision: D21418218
fbshipit-source-id: 90fa49c0954980993815322d3a7effee416ed5db
Summary:
This removes the Hermes.setPauseOnLoad. It will be replaced by the more standard
Debugger.setInstrumentationBreakpoint's "beforeScriptExecution" event.
ChangeLog: [Internal] Remove Hermes.setPauseOnLoad message (to be replaced)
Reviewed By: mhorowitz
Differential Revision: D21418219
fbshipit-source-id: 93c53801c23487f9336b322c2bd737663ec21b97
Summary:
We are currently very strict about breakpoint location matching. This
diff allows some fuzz in the column, but not in the line.
Changelog: [Internal] Setting Hermes breakpoints no longer requires exact column match
Reviewed By: avp
Differential Revision: D21343198
fbshipit-source-id: a59786a9d63f9fe1ed576835ed660ba3343affe1
Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.
The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.
Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call
Reviewed By: bestander
Differential Revision: D20754604
fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909
Summary:
This diff implements the instruction pointer save/restore trick Tzvetan came up with; allowing us to observe and modify the IP from outside the interpreter loop with negligible overhead.
From Tzvetan's internal post on the subject:
> [Today] the interpreter IP is just a local variable in the interpreter function, so there is no way to get to its value from outside the function. It lives in a register and we don't want to make it a Runtime field since the overhead [of accessing it via memory in the interpeter loop] would kill us.
> However, if you really think about it, it only lives in a register while the interpreter function is running. For the rest of the time, it is spilled by the C++ compiler onto the stack.
So, precisely when we need it, it is actually stored in memory. The only problem is, we don't know where! Admittedly, that is an annoying problem, but it feels like it should be solvable.
> What if, instead of relying on the compiler to spill the IP register, we manually spill it ourselves, to a known location? It works. Example: https://godbolt.org/z/ftSDnp
This diff implements this approach across the whole interpreter loop: whenever we call out of the loop we capture/publish the IP and restore it again immediately after the external call returns. This means we can now see the IP outside the interpret loop and even change it. This is effectively "for free" as the compiler now skips spilling/restoring the IP behind the scenes.
The immediate benefit of this is knowing the current IP allows us to have more accurate stack-traces during execution. In future this may enabled tricks like changing the IP before returning to the interpreter loop, allowing things outside the interpreter to affect program flow without adding logic to the interpreter loop.
Reviewed By: tmikov
Differential Revision: D20151091
fbshipit-source-id: 3814382639800208d8985a32ede31ba8f7ff7c80
Summary:
Changelog: [Internal]
Hermes inspector includes pthreads, arpa and sys headers on all OSes that would break vanilla Windows builds. This diff adds a check for posix-compliance before inclusion
(Note: this ignores all push blocking failures!)
Reviewed By: dulinriley
Differential Revision: D20564449
fbshipit-source-id: 8e264bc3104065dc4315bb291e8560609fe65184
Summary:
This adds support for 'returnByValue' in Runtime.evaluate invocations.
If the result of the evaluation can't be serialized to JSON, the results
are undefined.
ChangeLog: [Internal] - Hermes Inspector now supports 'returnByValue' in CDP Runtime.evaluate calls
[Facebook]
This is change was made to support debug completion in VSCode for ReactVR.
Reviewed By: ArchDev
Differential Revision: D19961115
fbshipit-source-id: d20af82b35d6bde88ab74b5c5a4c07415122c142
Summary:
Changelog: [Internal]
The inspector API doesn't really need a `HermesRuntime`, all it needs is a `jsi::Runtime` and a `Debugger &`.
Change the return type of `RuntimeAdapter::getRuntime` to be `jsi::Runtime`.
This will allow the inspector to use the tracing runtime instead of the direct hermes runtime.
Reviewed By: willholen
Differential Revision: D18973867
fbshipit-source-id: 6809e52452a35e62be9ca8143aeaba8964c98eaa
Summary:
Changelog: [Internal] Upgrade Chrome devtools protocol for Hermes
Update to the most recent version of the devtools protocol, r730699.
This just adds a few parameters to the stable API.
They have reasonable defaults that shouldn't break the existing functionality.
Reviewed By: willholen
Differential Revision: D19387559
fbshipit-source-id: 49d9ebf4a1a20f349ea6e46be6d5f36184ba8afb
Summary:
Changelog: [Internal]
Before, we were relying on checking out the `devtools-protocol` Github repo at a specific commit and
making special changes to the JSON file.
In order to make it easier to update, use the officially published npm package.
I found the closest package version that was published, but it had two differences:
* `Runtime.getHeapUsage` was either missing (in earlier versions) or experimental (in later versions)
* `isDefault` and `isPageContext` were removed. I'm not sure what these were used for anyway, the comment leads me to believe they're probably not necessary anymore
There were some customizations made previously to annotate `recursive` on some properties. The npm package doesn't set these,
so I wrote some checks to add it back in if it can be detected. This was mostly to handle one special case: `Runtime.StackTrace`.
The workaround seems to be fine for that case.
Reviewed By: willholen
Differential Revision: D19386890
fbshipit-source-id: db0d85f6bc71cba77ee67d85efe2f38376d7cc87
Summary:
Our current lazy compilation parent scope issue caused us to only have a
single lexical scope, which was taken to be the global scope. This
effectively hid all local variables. Additionally, the variables were
not marked as enumerable, so Chrome didn't show them.
As further improvements, 'this' is now included, and we more correctly
tag parent scopes as closures.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D18671527
fbshipit-source-id: cbbf9fbd319e433b9f681bd23e4ad7b4bb4a3d74
Summary:
Currently, if you try to inspect globals in the debugger and they have
properties that throw exceptions, the app redscreens. In particular,
inspecting any function triggers the bug because of `arguments` and
`caller`.
This diff catches the exception and shows a placeholder instead.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D18664765
fbshipit-source-id: 0c662f3d97b21a29c57a1dd724e63d17a3b4e263
Summary:
setBreakpoint differs from the existing setBreakpointByUrl in that you
can specify a scriptId directly. This was not really possible before
now, since scriptIds were mapped via filenames rather than to
RuntimeModules.
When (re)loading files with the same name, this call can be used to set
breakpoints in a specific one, rather than just the latest version.
Changelog: [Internal]
Reviewed By: bestander
Differential Revision: D18362054
fbshipit-source-id: 6ff1e736c79a4e75dc424316675d426ce9902f5f
Summary:
We were calling `sendErrorToClient` on error, but this function only
returns a closure that we threw away. Change to actually send an error
response.
Changelog: [Internal]
Reviewed By: bestander
Differential Revision: D18362055
fbshipit-source-id: 2ff1750ffd2c32a9291d3ed74fa0aaecd76c64c6
Summary:
When a filename (potentially with changes) is loaded multiple times, we keep
multiple instances around but fail to alert the attached debugger about this.
By coupling ScriptIDs to RuntimeModules rather than filenames, we can track
multiple instances of the same name instead.
Changelog: [Internal]
Reviewed By: bestander
Differential Revision: D18362052
fbshipit-source-id: 2147af32bc48c5fd2a2b080ea09dfa4133de7cf5
Summary:
Yesterday we shipped hermesengine.dev as part of the current 0.60 release. This PR brings those changes to master.
## Changelog
[General] [Added] - Added support for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/25613
Test Plan:
* CI is green both on GitHub and at FB
* Creating a new app from source can use Hermes on Android
Reviewed By: cpojer
Differential Revision: D16221777
Pulled By: willholen
fbshipit-source-id: aa6be10537863039cb666292465ba2e1d44b64ef