Mendiagnosis Error Runtime VM

Ikuti langkah-langkah ini secara berurutan. Setiap langkah menyingkirkan satu penyebab umum sebelum Anda menghabiskan waktu untuk mempersempit kode yang gagal.

1. Singkirkan kemungkinan pertahanan lanjutan

Error yang tidak masuk akal untuk kode Anda, paling sering RangeError: Invalid array length, biasanya berarti build produksi berjalan di tempat yang tidak boleh menjalankan build produksi. VM Self Defending dan VM Debug Protection sengaja merusak kode di test runner dan otomatisasi lainnya, browser headless, Node.js atau jsdom yang menjalankan build browser, dan browser dengan DevTools terbuka. Sebelum hal lain, periksa di mana kode yang gagal itu berjalan.

Pertama, singkirkan kemungkinan pertahanan lanjutan (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduksi kegagalan dengan build pengujian yang memakai penimpaan dari Pengujian dan CI. Jika build pengujian berfungsi, berarti pertahanan tersebut bereaksi terhadap alat atau lingkungan Anda, bukan merusak kode Anda.

2. Periksa kompatibilitas runtime dan persempit fungsi yang gagal

Periksa bahwa target, pipeline build, dan deklarasi lingkungan apa pun sesuai dengan tempat kode benar-benar berjalan.

Jika sebuah build melaporkan peringatan cakupan seperti VMNoFunctionsToVirtualize, lihat Obfuskasi VM untuk mengetahui apa saja yang dicakup oleh proteksi VM.

Perkecil kasus yang gagal hingga fungsi dan titik pemanggilan terkecil yang masih mereproduksinya. Gunakan mode komentar untuk mempersempit fungsi mana yang divirtualisasi.

Jika Anda menggunakan vmBytecodeArrayEncoding dengan vmBytecodeArrayEncodingKeyGetter, getter harus mengembalikan kunci yang persis sama dengan yang digunakan saat build. Getter sinkron memerlukan kunci yang sudah disetel sebelum kode hasil obfuskasi dijalankan. Getter yang mengembalikan Promise memerlukan vmAsyncExecutor. Jika salah satunya tidak terpenuhi, bytecode tidak dapat didekode.

Kompatibilitas Runtime · Kunci Bytecode Array Encoding

3. Kirim laporan bug

Kirim email ke support@obfuscator.io. Semakin banyak hal berikut yang Anda sertakan, semakin cepat kami dapat memperbaikinya:

• Stack trace error lengkap, persis seperti yang muncul di konsol, bukan parafrase.
• Opsi obfuscator dalam format JSON. Salin seluruh objek opsi yang Anda gunakan (atau nama preset beserta penimpaannya). Interaksi halus antaropsi sering terjadi, jadi kami membutuhkan kumpulan opsi yang persis.
• Peringatan build, jika ada: type, message, dan functionName dari masing-masing peringatan.
• Versi obfuscator - ditampilkan di pemilih versi dasbor di bawah editor. Untuk pemanggilan API langsung, versi ini adalah field version dari pesan result atau chunk_end. Dengan paket javascript-obfuscator, versi ini muncul di pesan progres (Obfuscating with VM protection (vX.Y.Z)...), yang dicetak oleh CLI dan diteruskan oleh obfuscatePro ke callback onProgress-nya.
• Lingkungan - peramban beserta versinya, versi Node.js, OS, dan apa pun yang tidak biasa pada runtime (ekstensi, polyfill, built-in kustom).
• Reproduksi minimal - idealnya satu fungsi dari bagian 2, ditambah titik pemanggilan yang diperlukan untuk memicu error.
• Kode sumber asli (sebelum obfuskasi), jika memungkinkan. Keluaran hasil obfuskasi juga buram bagi kami; tanpa masukan, kami harus merekayasa balik bytecode kami sendiri.

Jika kode sumber tersebut bersifat tertutup, sebutkan di email; kami dapat menandatangani NDA sebelum Anda membagikannya. Kami tidak dapat mendiagnosis bug VM secara andal tanpa melihat pola masukan yang menghasilkan bytecode yang rusak, jadi upaya bolak-balik itu sepadan.