VM रनटाइम एरर का निदान

इन चरणों को क्रम से पूरा करें। हर चरण किसी आम कारण को खारिज करता है, इससे पहले कि आप विफल होने वाले कोड को सीमित करने में समय लगाएँ।

1. उन्नत सुरक्षा को खारिज करें

ऐसी त्रुटि जिसका आपके कोड से कोई मेल नहीं बैठता, सबसे अधिक RangeError: Invalid array length, आमतौर पर बताती है कि प्रोडक्शन बिल्ड ऐसी जगह चल रहा है जहाँ प्रोडक्शन बिल्ड नहीं चलने चाहिए। VM Self Defending और VM Debug Protection टेस्ट रनर और अन्य ऑटोमेशन, हेडलेस ब्राउज़र, ब्राउज़र बिल्ड चलाने वाले Node.js या jsdom, और DevTools खुले ब्राउज़र में कोड को जानबूझकर तोड़ देते हैं। सबसे पहले जाँचें कि विफल होने वाला कोड कहाँ चल रहा है।

पहले उन्नत सुरक्षा (VM Self Defending, VM Debug Protection, VM Domain Lock) को खारिज करें: विफलता को ऐसे टेस्टिंग बिल्ड से दोहराएँ जो टेस्टिंग और CI के ओवरराइड इस्तेमाल करता हो। अगर टेस्टिंग बिल्ड काम करता है, तो रक्षा उपाय आपके कोड को तोड़ने के बजाय आपके टूल्स या वातावरण पर प्रतिक्रिया दे रहे हैं।

2. रनटाइम संगतता जाँचें और विफल होने वाले फ़ंक्शन को सीमित करें

जाँचें कि target, बिल्ड पाइपलाइन और वातावरण से जुड़ी कोई भी घोषणा उस जगह से मेल खाती हो जहाँ कोड वास्तव में चलता है।

अगर कोई बिल्ड VMNoFunctionsToVirtualize जैसी कवरेज चेतावनियाँ रिपोर्ट करता है, तो VM सुरक्षा किन चीज़ों को कवर करती है, यह जानने के लिए VM ऑब्फ़स्केशन देखें।

विफल मामले को सबसे छोटे फ़ंक्शन और कॉल साइट तक घटाएँ जो अब भी समस्या दोहराता हो। कौन-से फ़ंक्शन्स वर्चुअलाइज़ हों, इसे सीमित करने के लिए comment मोड इस्तेमाल करें।

अगर आप vmBytecodeArrayEncoding को vmBytecodeArrayEncodingKeyGetter के साथ इस्तेमाल करते हैं, तो गेटर को ठीक वही कुंजी लौटानी चाहिए जो बिल्ड के समय इस्तेमाल हुई थी। सिंक्रोनस गेटर के लिए ज़रूरी है कि ऑब्फ़स्केटेड कोड चलने से पहले कुंजी सेट हो चुकी हो। Promise लौटाने वाले गेटर के लिए vmAsyncExecutor आवश्यक है। इनमें से कोई भी शर्त पूरी न होने पर बाइटकोड डिकोड नहीं हो सकता।

रनटाइम संगतता · Bytecode Array Encoding कुंजी

3. बग रिपोर्ट भेजें

support@obfuscator.io पर ईमेल करें। आप नीचे दी गई जितनी ज़्यादा जानकारी शामिल करेंगे, हम उतनी जल्दी इसे ठीक कर पाएँगे:

• पूरा एरर स्टैक ट्रेस, ठीक वैसा ही जैसा कंसोल में दिखता है, अपने शब्दों में लिखा हुआ नहीं।
• JSON के रूप में ऑब्फ़स्केटर विकल्प। आपने जो पूरा options ऑब्जेक्ट इस्तेमाल किया, उसे कॉपी करें (या प्रीसेट का नाम और सभी ओवरराइड)। विकल्पों के बीच सूक्ष्म पारस्परिक प्रभाव आम हैं, इसलिए हमें ठीक-ठीक वही सेट चाहिए।
• बिल्ड चेतावनियाँ, अगर हों: हर चेतावनी का type, message और functionName।
• ऑब्फ़स्केटर संस्करण, जो एडिटर के नीचे डैशबोर्ड के संस्करण सिलेक्टर में दिखता है। सीधे API कॉल के लिए, यह result या chunk_end संदेश का version फ़ील्ड है। javascript-obfuscator पैकेज के साथ, यह प्रोग्रेस संदेश (Obfuscating with VM protection (vX.Y.Z)...) में दिखता है, जिसे CLI प्रिंट करता है और obfuscatePro अपने onProgress कॉलबैक को भेजता है।
• वातावरण: ब्राउज़र और उसका संस्करण, Node.js संस्करण, OS, और रनटाइम की कोई भी असामान्य बात (एक्सटेंशन, पॉलीफ़िल, कस्टम बिल्ट-इन)।
• न्यूनतम पुनरुत्पादन: आदर्श रूप से सेक्शन 2 वाला वह एक फ़ंक्शन, और एरर पैदा करने के लिए ज़रूरी कॉल साइट।
• मूल (ऑब्फ़स्केशन से पहले का) सोर्स, जहाँ संभव हो। ऑब्फ़स्केटेड आउटपुट हमारे लिए भी अपारदर्शी है; इनपुट के बिना हमें अपने ही बाइटकोड की रिवर्स-इंजीनियरिंग करनी पड़ती है।

अगर सोर्स मालिकाना है, तो ईमेल में बता दें; साझा करने से पहले हम NDA पर हस्ताक्षर कर सकते हैं। टूटा हुआ बाइटकोड बनाने वाले इनपुट पैटर्न को देखे बिना हम VM बग का भरोसेमंद निदान नहीं कर सकते, इसलिए यह अतिरिक्त कदम उठाना सार्थक है।