डोपामाइन जेलब्रेक डेवलपर मायावी स्पिनलॉक टाइमआउट पैनिक मुद्दे पर चर्चा करता है
डोपामाइन iOS और iPadOS 15.0-15.4.1 पर चलने वाले A12-A15 उपकरणों के लिए जेलब्रेक टूल इस समय iPhone X से नए किसी भी डिवाइस के लिए उपलब्ध एकमात्र नवीनतम जेलब्रेक है। ऐसा कहने के बाद, इसमें कोई आश्चर्य की बात नहीं है कि यह एक लोकप्रिय विकल्प है जेल तोड़ने वाले आज।
लेकिन यदि आप डोपामाइन का उपयोग कर रहे हैं या प्रोजेक्ट की शुरुआत से ही उसका अनुसरण कर रहे हैं, तो संभवतः आपने प्रोजेक्ट लीड डेवलपर लार्स फ्रोडर द्वारा कही गई एक बात को कई बार सुना होगा ( @opa334dev ) और उपयोगकर्ता समान: स्पिनलॉक।
दरअसल, एक ज्ञात समस्या है जो डोपामाइन जेलब्रेक को प्रभावित करती है जिसे स्पिनलॉक टाइमआउट पैनिक कहा जाता है, और इसके परिणामस्वरूप अंततः उपयोगकर्ता का डिवाइस गुलाबी स्क्रीन दिखाता है और फिर बिना किसी उकसावे के रीबूट होता है। इस मुद्दे को तकनीकी शब्दों में इस प्रकार वर्णित किया गया है:
dyld_shared_cache निष्पादन योग्य पृष्ठों के शीर्ष पर मैपिंग पीपीएल में एक एज केस व्यवहार को ट्रिगर करती प्रतीत होती है जो कभी-कभी मेमोरी पेज के स्पिनलॉक पर टाइमआउट का कारण बनती है, जिसके परिणामस्वरूप कर्नेल पैनिक होता है।
हुक सी फ़ंक्शंस में जितने अधिक बदलाव स्थापित किए जाते हैं और जितनी अधिक प्रक्रियाएँ उनमें डाली जाती हैं, उतनी ही अधिक बार यह व्यवहार ट्रिगर होता प्रतीत होता है।
ऐसा प्रतीत होता है कि इस समस्या को हुक किए गए सभी पृष्ठों को वायरिंग करके ठीक किया जा सकता है, लेकिन उपयोगकर्ता स्थान ऐसा लॉक नहीं ले सकता है और वायर्ड बिट को सीधे फ़्लिप करने के लिए कर्नेल मेमोरी में vm_page ऑब्जेक्ट ढूंढना मुश्किल साबित हो रहा है।
चूँकि मैंने व्यक्तिगत रूप से अपने डोपामाइन डिवाइस पर कभी भी इनमें से किसी भी समस्या का अनुभव नहीं किया है, इसलिए यह समझाना मुश्किल है कि यह कैसा दिखता है या कब होता है, लेकिन मैंने फ्रोडर से बात की और पूछा कि उन्हें क्या लगता है कि इसके कारण क्या हो सकते हैं, इस बारे में और अधिक जानने के लिए कि यह कैसे होता है वे इसे संबोधित करने का प्रयास कर रहे हैं।
फ्रोडर की प्रतिक्रिया मेरे जैसे गैर-तकनीकी लोगों और संभवतः जेलब्रेक समुदाय के कई अन्य लोगों के लिए व्यावहारिक थी और तब से यह है GitHub अंक पृष्ठ पर प्रकाशित जनता के देखने के लिए. नीचे उद्धृत पूर्ण प्रतिक्रिया से स्पिनलॉक टाइमआउट पैनिक मुद्दे के बारे में फ्रोडर की समझ का पता चलता है:
यहां इस मुद्दे की मेरी सर्वोत्तम वर्तमान समझ के अनुसार, इसकी अधिक गहराई से व्याख्या करने का प्रयास किया गया है। ध्यान रखें कि यह उन धारणाओं पर आधारित है जिन्हें सत्यापित करना मूल रूप से असंभव है।
इसलिए मल्टी-थ्रेडेड सिस्टम में दो थ्रेड्स को एक-दूसरे के साथ हस्तक्षेप करने से रोकने के लिए 'लॉक' का उपयोग किया जाता है। इसके द्वारा एक थ्रेड लॉक प्राप्त कर सकता है, संशोधन कर सकता है और उसे अनलॉक कर सकता है। लॉक होने पर, लॉक प्राप्त करने का प्रयास करने वाला एक अन्य थ्रेड तब तक प्रतीक्षा करेगा जब तक कि ऑब्जेक्ट फिर से अनलॉक न हो जाए।
स्पिनलॉक अनिवार्य रूप से एक ही चीज़ है, केवल प्रदर्शन से संबंधित सामग्री के लिए उपयोग किया जाता है और मुख्य अंतर यह है कि यदि कोई चीज़ लॉक को बहुत अधिक समय लेती है तो स्पिनलॉक टाइम आउट हो सकता है जबकि कोई अन्य थ्रेड लॉक प्राप्त करने का प्रयास कर रहा है। इसलिए जब लॉक प्राप्त किया जाता है और ऑब्जेक्ट पहले से ही लॉक है, तो यह कुछ टिकों की प्रतीक्षा करेगा और यदि ऑब्जेक्ट उस समय सीमा में अनलॉक नहीं होता है, तो इसका समय समाप्त हो जाएगा।
यह तंत्र अपने आप में कोई मुद्दा नहीं है, मुद्दे का संबंध इससे है याद पन्ने. प्रत्येक मेमोरी पेज (जो 16kB RAM के क्षेत्र का वर्णन करता है) में एक स्पिनलॉक होता है ताकि जब कई प्रक्रियाएं एक ही समय में एक ही पेज प्राप्त करने का प्रयास करें तो कोई समस्या न हो।
विशिष्ट पृष्ठों को कई प्रक्रियाओं में मैप किया जा सकता है (उदाहरण के लिए यदि दोनों एक ही लाइब्रेरी को लोड करते हैं), तो वे मेमोरी को बचाने के लिए एक ही पृष्ठ का पुन: उपयोग करते हैं। ट्विक्स ऐसी मेमोरी को प्रति-प्रक्रिया के आधार पर अधिलेखित करना चाहते हैं, इसलिए उन्हें पहले मौजूदा मैपिंग की एक प्रक्रिया-विशिष्ट प्रतिलिपि बनानी होगी और उसके ऊपर इसे मैप करना होगा, ताकि उदा. एक पृष्ठ को एक प्रक्रिया में संशोधित किया जा सकता है जबकि शेष स्टॉक को अन्य प्रक्रियाओं में संशोधित किया जा सकता है। समस्या विशेष रूप से dyld_shared_cache के अंदर मौजूद किसी पृष्ठ के शीर्ष पर मैप करते समय होती है।
अब समस्या यह है कि Apple ने संभवतः इस प्रकार की हुकिंग का परीक्षण कभी नहीं किया है और जाहिर तौर पर जब आप इसे कई प्रक्रियाओं में करते हैं, तो यह मूल पृष्ठ (साझा मैपिंग में से एक) को पेज आउट कर सकता है, क्योंकि इसका सक्रिय रूप से उपयोग नहीं किया जा रहा है . किसी पेज को पेज आउट करना अनिवार्य रूप से उसे रैम से हटा देता है और जब इसे दोबारा एक्सेस किया जाता है तो इसे फिर से लोड किया जाएगा। स्टॉक सिस्टम पर ऐसा नहीं होगा क्योंकि कुछ भी हुक नहीं किया गया है।
अब मूल कारण कुछ ऐसा प्रतीत होता है जो पहले से पृष्ठांकित साझा/निष्पादन योग्य पृष्ठ को वापस पेज में डालने का प्रयास कर रहा है, यह एक प्रीएम्प्शन समस्या को ट्रिगर करता है जहां एक थ्रेड स्पिनलॉक लेता है और जबकि उसके पास ऐसा होता है, यह एक अलग संदर्भ में प्रीएम्प्ट हो जाता है जो भी लेता है वही स्पिनलॉक (प्रीएम्पशन अनिवार्य रूप से एक तंत्र है जो एक थ्रेड को किसी अन्य चीज़ के लिए उपयोग करने की अनुमति देता है भले ही वह वर्तमान में व्यस्त हो, कोड को स्पष्ट रूप से अक्षम करना होगा और यदि कोड का एक टुकड़ा है जिसे हमेशा एक बार में निष्पादित किया जाना चाहिए तो इसे फिर से सक्षम करना होगा) . तो ऐसा लगता है कि एक कोड पथ है जो केवल इस विशेष व्यवहार से लागू होता है जहां ऐप्पल प्रीएम्प्शन को सही ढंग से अक्षम नहीं करता है, जिसके कारण एक थ्रेड दो बार एक ही स्पिनलॉक लेता है, जिससे यह समय समाप्त हो जाता है क्योंकि पुराना संदर्भ अब निष्पादित नहीं हो रहा है और स्पिनलॉक को दोबारा अनलॉक नहीं किया जा सकता.
जहां तक इसे कम करने की बात है, मैंने स्पिनलॉक से संबंधित वेरिएबल्स के साथ खिलवाड़ करने की कोशिश की ताकि समय सीमा को ऊंचा किया जा सके, दुर्भाग्य से ऐप्पल ने हमसे पंगा ले लिया क्योंकि उससे संबंधित हर चीज केटीआरआर संरक्षित है, जिसके लिए हमारे पास बाईपास नहीं है। मुझे लगता है कि उचित समाधान यह होगा कि प्रत्येक हुक किए जाने वाले पेज को ओवरराइट करने से पहले 'वायर डाउन' किया जाए (किसी पेज को डाउन करना उसे पेज आउट होने से रोकता है) ताकि सुनिश्चित किया जा सके कि पेज आउट कभी न हो और इसलिए इसमें कोड पथ शामिल हो। समस्या ट्रिगर नहीं हो रही है, मैंने अब तक बहुत सारी चीज़ें आज़माई हैं लेकिन ऐसा लगता है कि यूज़रस्पेस से ऐसी वायरिंग हासिल करना सीधे तौर पर असंभव है, इसलिए इसे कर्नेल के अंदर करना होगा। दुर्भाग्य से, इस विशिष्ट साझा मैपिंग में शामिल संरचनाएं जो समस्या का कारण बनती हैं, बहुत जटिल हैं और मुझे अभी तक वायरिंग लागू करने के लिए सही पेज ऑब्जेक्ट प्राप्त करने का कोई तरीका नहीं मिला है।
स्पिनलॉक टाइमआउट पैनिक समस्या डोपामाइन के पहली बार उपलब्ध होने के बाद से ही मौजूद है और आज भी बनी हुई है कई कोशिशों के बावजूद समस्या को ठीक करने के लिए. ऐसा कहने के बाद, अधिक लोगों के देखने और योगदान देने के लिए संवाद खोलना सही कदम है, क्योंकि इससे अधिक लोगों के लिए मुद्दे पर विचार-मंथन करना और संभावित समाधान निकालना आसान हो जाता है।
फ्रोडर ने एक अनुवर्ती टिप्पणी में समस्या को विफल करने के प्रयास के लिए अपने अगले विचार की व्याख्या की:
इसलिए इसे ठीक करने का प्रयास करने का अगला कदम कर्नेल मेमोरी में DSC पेज की vm_page संरचना को ढूंढना होगा, अब तक ऐसी संरचना को खोजने के मेरे सभी प्रयास विफल रहे हैं।
हालाँकि इसने अभी तक मुझे सीधे तौर पर प्रभावित नहीं किया है, लेकिन यह देखना वाकई दिलचस्प होगा कि क्या फ्रोडर स्पिनलॉक टाइमआउट पैनिक मुद्दे को हल करने में सक्षम है। ऐसा लगता है कि यह उन उपयोगकर्ताओं के लिए अधिक प्रचलित है जो हुक सी फ़ंक्शन के लिए अधिक जेलब्रेक ट्विक्स इंस्टॉल करते हैं। यह बस हो सकता है कि मेरे परीक्षण उपकरण में समस्या को ट्रिगर करने के लिए बहुत सारे ट्विक्स इंस्टॉल न हों, लेकिन मुझे पता है कि वहां कई जेलब्रेकर हैं जो बहुत सारे इंस्टॉल करते हैं जेलब्रेक में बदलाव - जितना मैं कभी करूंगा उससे भी अधिक।
यह भी देखें: डोपामाइन के साथ iOS और iPadOS 15.0-15.4.1 पर चलने वाले A12-A15 उपकरणों को जेलब्रेक कैसे करें
क्या आप कभी डोपामाइन जेलब्रेक का उपयोग करते समय अचानक रीबूट होने से पहले गुलाबी स्क्रीन के रूप में वर्णित स्पिनलॉक टाइमआउट पैनिक से प्रभावित हुए हैं? हमें नीचे टिप्पणी अनुभाग में बताएं।