Chẩn đoán lỗi khi chạy của VM

Hãy thực hiện lần lượt các bước sau theo thứ tự. Mỗi bước loại trừ một nguyên nhân phổ biến trước khi bạn dành thời gian khoanh vùng đoạn mã bị lỗi.

1. Loại trừ các cơ chế phòng thủ nâng cao

Một lỗi không hợp lý với mã của bạn, thường gặp nhất là RangeError: Invalid array length, thường có nghĩa là một bản dựng production đang chạy ở nơi bản dựng production không được phép chạy. VM Self Defending và VM Debug Protection cố ý làm hỏng mã trong các trình chạy kiểm thử và công cụ tự động hóa khác, trình duyệt headless, Node.js hoặc jsdom chạy bản dựng dành cho trình duyệt, và trình duyệt đang mở DevTools. Trước hết, hãy kiểm tra xem mã bị lỗi đang chạy ở đâu.

Trước tiên hãy loại trừ các cơ chế phòng thủ nâng cao (VM Self Defending, VM Debug Protection, VM Domain Lock): tái hiện lỗi bằng một bản dựng kiểm thử dùng các giá trị ghi đè từ Kiểm thử và CI. Nếu bản dựng kiểm thử hoạt động, thì các cơ chế phòng thủ đang phản ứng với công cụ hoặc môi trường của bạn chứ không phải làm hỏng mã của bạn.

2. Kiểm tra khả năng tương thích môi trường chạy và khoanh vùng hàm bị lỗi

Hãy kiểm tra rằng target, quy trình build và mọi khai báo môi trường khớp với nơi mã thực sự chạy.

Nếu một bản dựng báo các cảnh báo về phạm vi bao phủ như VMNoFunctionsToVirtualize, hãy xem Làm rối VM để biết bảo vệ VM bao phủ những gì.

Thu gọn trường hợp lỗi về hàm và vị trí gọi nhỏ nhất mà vẫn tái hiện được lỗi. Dùng chế độ comment để thu hẹp những hàm được ảo hóa.

Nếu bạn dùng vmBytecodeArrayEncoding cùng với vmBytecodeArrayEncodingKeyGetter, getter phải trả về đúng chính xác khóa đã dùng lúc build. Một getter đồng bộ cần khóa được đặt trước khi mã đã làm rối chạy. Một getter trả về Promise thì yêu cầu vmAsyncExecutor. Nếu thiếu một trong hai điều này, bytecode sẽ không thể giải mã.

Tương thích môi trường chạy · Khóa Bytecode Array Encoding

3. Gửi báo cáo lỗi

Gửi email tới support@obfuscator.io. Bạn cung cấp càng nhiều thông tin dưới đây, chúng tôi càng sửa lỗi nhanh hơn:

• Toàn bộ stack trace của lỗi, đúng y như hiển thị trong console, không phải diễn giải lại.
• Các tùy chọn của trình làm rối dưới dạng JSON. Sao chép toàn bộ đối tượng tùy chọn bạn đã dùng (hoặc tên preset cùng mọi giá trị ghi đè). Các tương tác tinh vi giữa các tùy chọn rất phổ biến, nên chúng tôi cần đúng bộ tùy chọn đó.
• Cảnh báo khi build, nếu có: type, message và functionName của từng cảnh báo.
• Phiên bản obfuscator - hiển thị trong bộ chọn phiên bản của bảng điều khiển bên dưới trình soạn thảo. Với lệnh gọi API trực tiếp, đó là trường version trong thông điệp result hoặc chunk_end. Với gói javascript-obfuscator, phiên bản xuất hiện trong thông điệp tiến trình (Obfuscating with VM protection (vX.Y.Z)...), được CLI in ra và được obfuscatePro truyền cho callback onProgress của nó.
• Môi trường - trình duyệt và phiên bản, phiên bản Node.js, hệ điều hành, mọi điều bất thường về môi trường chạy (tiện ích mở rộng, polyfill, các đối tượng dựng sẵn tùy chỉnh).
• Bản tái hiện tối giản - lý tưởng nhất là một hàm duy nhất từ mục 2, cùng với vị trí gọi cần thiết để kích hoạt lỗi.
• Mã nguồn gốc (trước khi làm rối), nếu có thể. Đầu ra đã làm rối cũng khó hiểu đối với chúng tôi; không có đầu vào, chúng tôi sẽ phải dịch ngược chính bytecode của mình.

Nếu mã nguồn là độc quyền, hãy nêu rõ trong email; chúng tôi có thể ký NDA trước khi bạn chia sẻ. Chúng tôi không thể chẩn đoán lỗi VM một cách đáng tin cậy nếu không thấy mẫu đầu vào đã tạo ra bytecode hỏng, nên việc trao đổi thêm này là xứng đáng.