Diagnosticando erros de execução da VM

Siga estes passos em ordem. Cada um descarta uma causa comum antes que você gaste tempo isolando o código com falha.

1. Testes e CI

Primeiro, descarte as defesas de execução (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduza a falha com um build de testes que use as substituições de Testes e CI. Se o build de testes funcionar, as defesas estão reagindo às suas ferramentas ou ao seu ambiente, e não quebrando o seu código.

2. Compatibilidade de execução

Verifique se o target, o pipeline de build e quaisquer declarações de ambiente correspondem ao lugar onde o código realmente roda.

A proteção VM se aplica às funções elegíveis. No modo root, vmWrapTopLevelInitializers também pode envolver inicializadores elegíveis para virtualização; as predefinições VM atuais a ativam. Revise avisos de cobertura como VMNoFunctionsToVirtualize e use o modo comment para selecionar explicitamente as funções sensíveis.

Reduza o caso com falha à menor função e ao menor ponto de chamada que ainda o reproduzam. Use o modo comment para restringir quais funções são virtualizadas.

Se você usa vmBytecodeArrayEncoding com vmBytecodeArrayEncodingKeyGetter, o getter precisa retornar exatamente a chave usada no momento do build, e essa chave já precisa estar definida quando o código ofuscado roda; caso contrário, o bytecode não pode ser decodificado.

Compatibilidade de execução · Chave do Bytecode Array Encoding

3. Envie um relatório de bug

Envie um e-mail para support@obfuscator.io. Quanto mais dos itens a seguir você incluir, mais rápido conseguimos corrigir:

• O stack trace completo do erro, exatamente como aparece no console - não uma paráfrase.
• As opções do ofuscador em JSON. Copie o objeto de opções inteiro que você usou (ou o nome da predefinição mais quaisquer sobrescritas). Interações sutis entre opções são comuns, então precisamos do conjunto exato.
• Os avisos do build, se houver: o type, a message e o functionName de cada um.
• A versão do ofuscador - exibida no seletor de versão do painel, abaixo do editor. Para builds pela API e pelo pacote npm, é o campo version da mensagem result ou chunk_end da API.
• O ambiente - navegador e versão, versão do Node.js, sistema operacional e qualquer coisa incomum no ambiente de execução (extensões, polyfills, builtins personalizados).
• Uma reprodução mínima - de preferência a função única da seção 2, mais o ponto de chamada necessário para disparar o erro.
• O código-fonte original (antes da ofuscação), sempre que possível. A saída ofuscada também é opaca para nós; sem a entrada, estaríamos fazendo engenharia reversa do nosso próprio bytecode.

Se o código-fonte for proprietário, diga isso no e-mail - podemos assinar um NDA antes que você o compartilhe. Não conseguimos diagnosticar bugs da VM de forma confiável sem ver o padrão de entrada que produziu o bytecode quebrado, então vale a pena essa troca de mensagens.