Diagnostiquer les erreurs d'exécution de la VM

Suivez ces étapes dans l'ordre. Chacune écarte une cause fréquente avant que vous ne passiez du temps à isoler le code en échec.

1. Écartez les défenses avancées

Une erreur qui n'a aucun sens pour votre code, le plus souvent RangeError: Invalid array length, signifie généralement qu'un build de production s'exécute là où les builds de production ne doivent pas s'exécuter. VM Self Defending et VM Debug Protection cassent volontairement le code dans les lanceurs de tests et autres outils d'automatisation, les navigateurs headless, Node.js ou jsdom exécutant un build pour navigateur, et les navigateurs dont les DevTools sont ouverts. Avant toute chose, vérifiez où s'exécute le code qui échoue.

Écartez d'abord les défenses avancées (VM Self Defending, VM Debug Protection, VM Domain Lock) : reproduisez l'échec avec un build de test qui applique les surcharges décrites dans Tests et CI. Si le build de test fonctionne, ce sont les défenses qui réagissent à vos outils ou à votre environnement, et non votre code qui est cassé.

2. Vérifiez la compatibilité d'exécution et isolez la fonction en échec

Vérifiez que le target, la chaîne de build et les éventuelles déclarations d'environnement correspondent à l'endroit où le code s'exécute réellement.

Si un build signale des avertissements de couverture comme VMNoFunctionsToVirtualize, consultez Obfuscation VM pour savoir ce que couvre la protection VM.

Réduisez le cas en échec à la plus petite fonction et au plus petit site d'appel qui reproduisent encore le problème. Utilisez le mode comment pour restreindre les fonctions virtualisées.

Si vous utilisez vmBytecodeArrayEncoding avec vmBytecodeArrayEncodingKeyGetter, le getter doit renvoyer exactement la clé utilisée au moment du build. Un getter synchrone exige que la clé soit définie avant l'exécution du code obfusqué. Un getter qui renvoie une Promise nécessite vmAsyncExecutor. Si l'une de ces conditions manque, le bytecode ne peut pas être décodé.

Compatibilité d'exécution · Clé de Bytecode Array Encoding

3. Envoyer un rapport de bug

Écrivez à support@obfuscator.io. Plus vous incluez d'éléments parmi les suivants, plus nous pourrons corriger rapidement :

• La trace d'appels complète de l'erreur, exactement telle qu'elle apparaît dans la console - pas une paraphrase.
• Les options de l'obfuscateur au format JSON. Copiez l'objet d'options complet que vous avez utilisé (ou le nom du préréglage et les éventuelles surcharges). Les interactions subtiles entre options sont fréquentes : nous avons besoin de l'ensemble exact.
• Les avertissements du build, le cas échéant : le type, le message et le functionName de chacun.
• La version de l'obfuscateur - affichée dans le sélecteur de version du tableau de bord, sous l'éditeur. Pour les appels directs à l'API, c'est le champ version du message result ou chunk_end. Avec le paquet javascript-obfuscator, elle apparaît dans le message de progression (Obfuscating with VM protection (vX.Y.Z)...), que la CLI affiche et que obfuscatePro transmet à son callback onProgress.
• L'environnement - navigateur et version, version de Node.js, système d'exploitation, et toute particularité de l'environnement d'exécution (extensions, polyfills, objets natifs personnalisés).
• Une reproduction minimale - idéalement la fonction isolée à la section 2, ainsi que le site d'appel nécessaire pour déclencher l'erreur.
• Le source d'origine (avant obfuscation), si possible. La sortie obfusquée est opaque pour nous aussi ; sans l'entrée, nous en sommes réduits à faire la rétro-ingénierie de notre propre bytecode.

Si le source est propriétaire, précisez-le dans l'e-mail - nous pouvons signer un accord de confidentialité (NDA) avant que vous ne le partagiez. Nous ne pouvons pas diagnostiquer de façon fiable les bugs de la VM sans voir le motif d'entrée qui a produit le bytecode défectueux : l'échange en vaut donc la peine.