Closed dustinbyrne closed 2 years ago
For the first issue, it might be because of C++ binding of https://github.com/lachrist/posix-socket. Could you try with socket: net
in appmap.yml
instead?
For the second issue, I think the infinite recursion happens because of async_hooks
. You can turn them off with ordering: chronological
in appmap.yml
.
After I merge the nextjs branch, I can try to replicate these myself.
@dustinbyrne
First of all, do you mean that node built/cli.js scan --watch
exits immediately on its own or do you have to kill it first? Because I have to ctrl-c
it.
Here are my findings.
I recorded the command and killed it like after 1min. Then, I have an invalid string length error when trying to JSON.stringify
the trace. I'm thinking that it is too big to be handled by JSON
?
I tried to kill it sooner like after 10s. An appmap gets generated. But it is 50MB and makes the viewer very slow. There are only a bunch of functions that have been recorded. And function-53::desc::get#()
at built/cli/scan/watchScan.js:6
gets called 61256 times >_<.
"use strict";
var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
if (k2 === undefined) k2 = k;
var desc = Object.getOwnPropertyDescriptor(m, k);
if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
desc = { enumerable: true, get: function() { return m[k]; } };
}
Object.defineProperty(o, k2, desc);
}) : (function(o, m, k, k2) {
I logged the callstack at that function:
YO Error: BOUM
at Object.get [as FSWatcher] (/Users/soft/Desktop/workspace/appmap-js/packages/scanner/built/cli/scan/watchScan.js:18:35)
at entries (<anonymous>)
at toEntriesSafe (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/serialization/default/index.mjs:31:14)
at getSpecific (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/serialization/default/index.mjs:186:23)
at serializeNonEmpty (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/serialization/default/index.mjs:229:19)
at serialize (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/serialization/default/index.mjs:263:24)
at formatApplyPayload (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/frontend/default/payload.mjs:25:13)
at file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/agent/default/index.mjs:43:7
at Object.runtime.recordApply (file:///Users/soft/Desktop/workspace/appmap-js/node_modules/@appland/appmap-agent-js/components/hook-apply/default/index.mjs:61:13)
at Object.get [as FSWatcher] (/Users/soft/Desktop/workspace/appmap-js/packages/scanner/built/cli/scan/watchScan.js:15:28)
So acquiring the property of this object triggered the getter which gets recorded. This is done to populate the properties
field of the parameter object format. This can be toggled off with:
serialization:
impure-hash-inspection: false
Other serialization options here.
Now, the appmap recorded more functions and has a normal size:
TLDR: unsafe object inspection for serialization was at the origin of the error. It can be toggled off with config.serialization["impure-hash-inspection"] = false
.
I knew that unsafe serialization would be a problem at some point. But some information required by the appmap spec are best retrieved using unsafe methods. I could try to render some serialization operations less invasive but I'm sure it is impossible to provide the level of detail required by the spec with only safe operations. Should we consider to toggle off unsafe serialization by default?
@dustinbyrne fixed by 7a23367254de55a8c4d2e1d0a1eef28e247c55bc
I'm trying to get a recording of the @appland/scanner CLI. The process crashes is panicking due to OOM. From my observations, my best guess is that it's running out of memory during the initialization process. Without the agent the command I'm trying to record exits almost immediately, so I can't imagine it's due to the size of the recording itself.
My
appmap.yml
:I tried interrupting the agent while it was in the process of consuming memory to see where it was occurring, but this would crash the agent: