Vm2: Adicionar suporte para rastreamentos de pilha "corretos" para erros na sandbox

Criado em 5 ago. 2017  ·  13Comentários  ·  Fonte: patriksimek/vm2

Seria bom se vm2 pudesse exibir rastreamentos de pilha "corretos" quando um erro fosse lançado da sandbox.

Por exemplo, isto é o que é exibido atualmente:

/home/user/box-js/node_modules/vm2/lib/main.js:213
                        throw this._internal.Decontextify.value(e);
                        ^

Error: foobar
    at Object.log (/home/user/box-js/analyze.js:248:10)
    at Object.apply (/home/user/box-js/node_modules/vm2/lib/contextify.js:288:34)
    at vm.js:491:9
    at ContextifyScript.Script.runInContext (vm.js:53:29)
    at VM.run (/home/user/box-js/node_modules/vm2/lib/main.js:207:72)
    at Object.<anonymous> (/home/user/box-js/analyze.js:383:5)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)

Existe uma maneira de descobrir qual linha (no código em área restrita) foi responsável por chamar a função que gerou o erro?

feature request help wanted

Comentários muito úteis

Apenas deixando um comentário para notificar as pessoas que estão inscritas neste assunto - abri um PR, para que você possa acompanhar o andamento lá.

Todos 13 comentários

Isso seria incrível. Estou tentando rastrear um erro de codificação agora e estou tendo uma dificuldade terrivelmente difícil sem o número da linha

Se você estiver executando casos de teste que você sabe que são seguros, pode substituir temporariamente o vm2 pelo vm nativo para rastrear o erro.

Eu também gostaria desse recurso. Fico feliz em contribuir para escrevê-lo se alguém me indicar a direção certa.

Este problema foi automaticamente marcado como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Acontece que não é trivial substituir o vm2 por Native vm, pois há incompatibilidades de api, espero que isso possa permanecer aberto!

@patriksimek , eu desenvolvi uma implementação simples baseada em um analisador /

const StackTracey = require ('stacktracey');
const { VM } = require('vm2');

const sourceCode = `function f() {
    throw Exception('e');
}
f();`;
const scriptName = "hello_world.js";

process.on("uncaughtException",  e => {
    if (!e.stack.includes("/node_modules/vm2/")) {
        // This is not a vm2 error, so print it normally
        console.log(e);
        return;
    }
    const oldStack = new StackTracey(e);
    const newStack = [];
    for (const line of oldStack) {
        // Discard internal code
        if (line.file.includes("/cjs"))
            continue;
        if (line.thirdParty && line.file.includes("/node_modules/vm2/"))
            continue;
        if (line.callee == "Script.runInContext")
            continue;
        // Replace the default filename with the user-provided one
        if (line.fileName == "vm.js")
            line.fileRelative = line.fileShort = line.fileName = scriptName;
        newStack.push(line);
    }
    console.log("[vm2] A clean stack trace follows:");
    console.log(new StackTracey(newStack).pretty);
});

const vm = new VM();
vm.run(sourceCode, scriptName);

O código acima imprimiria:

ReferenceError: Exception is not defined
    at f (vm.js:2:2)
    at vm.js:4:1
    at Script.runInContext (vm.js:135:20)
    at VM.run (/tmp/vm2-test/node_modules/vm2/lib/main.js:210:72)
    at Object.<anonymous> (/tmp/vm2-test/index.js:33:4)
    at Module._compile (internal/modules/cjs/loader.js:805:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:816:10)
    at Module.load (internal/modules/cjs/loader.js:672:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:612:12)
    at Function.Module._load (internal/modules/cjs/loader.js:604:3)
[vm2] A clean stack trace follows:
at f            hello_world.js:2
at              hello_world.js:4
at <anonymous>  index.js:33       vm.run(sourceCode, scriptName);

Não tive a chance de testar esta biblioteca, mas recentemente usei o módulo vm e consegui números de rastreamento de pilha precisos definindo o deslocamento de linha apropriado ao criar um novo vm.Script.

Este problema foi automaticamente marcado como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Achei que gostaria de comentar porque este problema + sugestões ainda são relevantes para mim

Muito relevante para mim também.

@patriksimek pode a implementação do @CapacitorSet ou algo parecido ser integrado no projeto?
Obrigado.

Patrik, o esboço de implementação parece bom no geral? Se for assim, posso fazer um PR e podemos trabalhar a partir daí.

@CapacitorSet Sim, terei todo o gosto em avaliar um PR Algumas notas:

  • O método vm.run não aceita o segundo parâmetro - é por isso que o nome do script é ignorado. Atualmente, você precisa criar um VMScript com o nome especificado primeiro. Mas isso pode ser facilmente melhorado.
  • Existe uma maneira de evitar o uso de lib externa? Seria bom ficar com zero deps.

Apenas deixando um comentário para notificar as pessoas que estão inscritas neste assunto - abri um PR, para que você possa acompanhar o andamento lá.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

unxcepted picture unxcepted  ·  11Comentários

wojpawlik picture wojpawlik  ·  4Comentários

seanc picture seanc  ·  3Comentários

wintertime-inc picture wintertime-inc  ·  5Comentários

keyosk picture keyosk  ·  64Comentários