stack traces from xs-worker vats lack filenames, line numbers #2578
Comments
The connection to the debugger is established on launch of the VM, not on an exception. If you don't want to use the debugger, disable it in xssnap.
How? |
|
Instrumentation would be handy but |
|
FWIW - instrumentation is a host feature, not strictly an xs feature. That means it needs to be implemented in the host for xsnap to be available there. I just did a quick scan of the XS sources and didn't see any intersection between |
ah. good point. I set |
|
In #3039 (comment) @warner writes:
I was going to suggest getting a bytecode trace using That reminded me of the circular buffer idea from logging discussion. Perhaps we should...
I wonder how to access it externally and how that would interact with plans for a seccomp jail #2386 . Perhaps...
|
|
The stacks I'm seeing under xs-worker look like this: I've gotten used to stack traces that show much more context. Here's an example (notice full path file names and line numbers): |
dckc
changed the title
dckc
added
bug
eval interferes with source positions in XSXS seems to provide file and line numbers normally, but not in This code: const e = () => { throw Error('lose'); };
const d = () => e();
const c = () => d();
const b = () => c();
const a = () => b();
try {
a();
} catch (err) {
print(err.stack);
}when fed to but wrapped in eval... const code = `
const e = () => { throw Error('lose'); };
const d = () => e();
const c = () => d();
const b = () => c();
const a = () => b();
a
`;
const a = eval(code);
try {
a();
} catch (err) {
print(err.stack);
}gives |
|
What about |
|
The challenge for XS for either eval or compartment.evaluate is that there is no vessel to carry the file name. Line numbers are simpler, but meaningless without that file name. Browsers have dealt with this for aeons by looking at a sourceURL comment if they need to present a name. We prepare such comments in our bundles. If that is not palatable, we could find another vessel for the file name. compartment.evaluate could take an options bag argument. The same treatment on eval would be weird but I assume possible. |
|
Attn @phoddie , have we talked about this much? |
Native compartments seem to lose even more info. const code = `
const e = () => { throw Error('lose'); };
const d = () => e();
const c = () => d();
const b = () => c();
const a = () => b();
let result;
try {
a();
} catch (err) {
result = err.stack;
}
`;
const c = new Compartment();
const r = c.evaluate(code);
print(r);gives const code = `
const e = () => { throw Error('lose'); };
const d = () => e();
const c = () => d();
const b = () => c();
const a = () => b();
a
`;
const c = new Compartment();
const a = c.evaluate(code);
try {
a();
} catch (err) {
print(err.stack);
}gives |
|
@kriskowal describes the problem well. XS ignores the sourceURL. When we looked at doing that, it was ugly. Maybe we should look again. I did expect The file name is given as |
|
Before we get too focused on Getting there involves addressing most / all of the issues below, so an expedient update to
|
Agreed. That topic is already queued up for a call next week. Maybe best to wait for that to get in deeper than these (helpful!) notes. |
What is the Problem Being Solved?
The moddable SDK supports 2 build modes, debug and production. xsnap uses production by default with an option for debug, which means we don't, by default, get things like line numbers in stack traces.
Description of the Design
no, we don't want TCP connections to the debugger on exceptionsSecurity Considerations
The TCP connection to the debugger is certainly excess authority.
Test Plan
???
cc @phoddie @dtribble @erights @warner @kriskowal
The text was updated successfully, but these errors were encountered: