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. Tests et CI

Écartez d'abord les défenses à l'exécution (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. Compatibilité d'exécution

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.

La protection VM s'applique aux fonctions éligibles. En mode root, vmWrapTopLevelInitializers peut aussi envelopper les initialiseurs éligibles pour les virtualiser ; les préréglages VM actuels l'activent. Examinez les avertissements de couverture comme VMNoFunctionsToVirtualize, et utilisez le mode commentaire pour sélectionner explicitement les fonctions sensibles.

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 commentaire 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, et cette clé doit déjà être définie lorsque le code obfusqué s'exécute ; sinon, 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 builds via l'API ou le paquet npm, c'est le champ version du message result ou chunk_end de l'API.
• 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.