[द न्यू न्यू थिंग] क्या मैं अपने स्टैक का उपयोग कर सकता हूं जैसा मैं चाहता हूं?

विंडोज पर, स्टैक बड़े से छोटे पते पर बढ़ता है। कभी-कभी यह वास्तुशिल्प रूप से निर्धारित होता है, और कभी-कभी यह केवल एक स्वीकृत समझौता होता है। स्टैक पॉइंटर (प्रोसेसर रजिस्टर) का मूल्य स्टैक के शीर्ष पर मूल्य के लिए एक संकेतक है। और क्रमशः स्टैक पर गहरे स्थित मान बड़े पते पर स्थित हैं। लेकिन स्टैक पॉइंटर से छोटे पते पर स्थित डेटा का क्या होता है?

कुछ के लिए कन्वेंशन (लेकिन सभी नहीं) आर्किटेक्चर रेड ज़ोन को परिभाषित करते हैं, जो स्टैक पॉइंटर के तहत मेमोरी क्षेत्र है, लेकिन जो अभी भी एप्लिकेशन द्वारा उपयोग के लिए मान्य है।

विंडोज के लिए, रेड ज़ोन का आकार हार्डवेयर आर्किटेक्चर के आधार पर भिन्न होता है और अक्सर शून्य होता है।

* इटेनियम प्लेटफ़ॉर्म एक विशेषता पर ध्यान देने योग्य है: वहां रेड ज़ोन स्टैक पॉइंटर के ऊपर स्थित है , और इसके नीचे नहीं।
** पावरपीसी के मामले में, रेड ज़ोन कॉल समझौते का एक साइड इफेक्ट है ।

रेड ज़ोन (स्टैक के नीचे) के पीछे की कोई भी मेमोरी अस्थिर मानी जाती है और इसे किसी भी समय ऑपरेटिंग सिस्टम द्वारा बदला जा सकता है।

लेकिन गंभीरता से, ऑपरेटिंग सिस्टम परवाह क्यों करता है कि मैं अपने स्टैक के साथ क्या करूं? मेरा मतलब है, यह मेरा ढेर है! ऑपरेटिंग सिस्टम मुझे यह नहीं बताता है कि मुझे VirtualAlloc माध्यम से आवंटित की गई मेमोरी का क्या करना है। क्या स्टैक किसी अन्य मेमोरी से अलग बनाता है?

X86 प्लेटफ़ॉर्म के लिए निम्न कोड पर विचार करें :

  MOV [esp-4], eax ;  eax    MOV ecx, [esp-4] ;     ecx CMP ecx, eax ;  ? JNZ panic ; N:  -  

क्या यह संभव है कि एक सशर्त संक्रमण लागू किया जाएगा?

चूंकि x86 पर कोई रेड ज़ोन नहीं है, स्टैक पॉइंटर के सापेक्ष नकारात्मक ऑफसेट के साथ मेमोरी किसी भी समय ओवरराइट की जा सकती है। इसलिए, उपरोक्त कोड के लिए, panic लेबल पर संक्रमण संभव है।

डिबगर अपने डेटा को संग्रहीत करने के लिए एक सुविधाजनक स्थान के रूप में लाल क्षेत्र के पीछे मेमोरी का उपयोग कर सकता है। उदाहरण के लिए, यदि आप .call कमांड का उपयोग करते हैं , तो डिबगर समान स्टैक पर नेस्टेड कॉल करेगा और रजिस्टरों को बचाने के लिए संभवतः इस स्टैक स्पेस के हिस्से का उपयोग करेगा ताकि उन्हें कॉल किए गए फ़ंक्शन से लौटने के बाद बहाल किया जा सके। इसलिए, रेड ज़ोन के बाहर संग्रहीत किसी भी डेटा को नष्ट कर दिया जाएगा।

सामान्य ऑपरेशन के दौरान भी, ऑपरेटिंग सिस्टम किसी भी समय रेड ज़ोन के बाहर डेटा को अधिलेखित कर सकता है। यहाँ, उदाहरण के लिए, यह कैसे हो सकता है:

मान लीजिए कि रेड ज़ोन के पीछे डेटा सहेजने के बाद आपका थ्रेड सही समय पर चलता है। जबकि आपका धागा निष्पादन को फिर से शुरू करने की प्रतीक्षा कर रहा है, मेमोरी मैनेजर अस्थायी रूप से आपके कोड से एक भौतिक पृष्ठ लेता है। अंत में, आपका धागा फिर से नियंत्रित हो जाता है और मेमोरी मैनेजर कोड बैक (पेज इन) पेज को स्वैप करने की कोशिश करता है। अरे नहीं, पेजिंग के दौरान I / O त्रुटि होती है! ऑपरेटिंग सिस्टम स्टैक पर STATUS_IN_PAGE_ERROR लिए अपवाद फ़्रेम को धक्का देता है, जो डेटा भ्रष्टाचार की ओर जाता है जिसे आपने लाल ज़ोन के पीछे बचाया था।

ऑपरेटिंग सिस्टम इस अपवाद को भेजता है। यह वेक्टर अपवाद हैंडलर ( VEH ) को एक्सेस करता है, जो आपके प्रोग्राम का एक और हिस्सा है। हैंडलर को विशेष रूप से सीडी-रॉम या एक अविश्वसनीय नेटवर्क एफएस से सीधे आपके प्रोग्राम के संभावित लॉन्च से उत्पन्न होने वाली असाधारण स्थितियों को संभालने के लिए स्थापित किया गया था। कार्यक्रम एक अनुरोध प्रदर्शित करता है जिसमें यह उपयोगकर्ता को फिर से सीडी डालने के लिए कहता है और फिर से प्रयास करने की पेशकश करता है। यदि उपयोगकर्ता कहता है कि क्या दोहराया जाना चाहिए, तो वेक्टर अपवाद हैंडलर EXCEPTION_CONTINUE_EXECUTION लौटाता है, और ऑपरेटिंग सिस्टम उस निर्देश को पुनः आरंभ करेगा, जिस पर अपवाद हुआ था।

इस बार, पुनः आरंभ सफल होता है क्योंकि CD-ROM मौजूद है (और पढ़ें) और कोड को सफलतापूर्वक मेमोरी में पंप किया जा सकता है। निम्न कथन निष्पादित किया जाता है, जो लाल क्षेत्र के बाहर मूल्य को ecx में लोड करता है। लेकिन यह वही मान नहीं है जो पिछले कथन द्वारा सहेजा गया था, क्योंकि STATUS_IN_PAGE_ERROR अपवाद इसे अधिलेखित कर देता है। तुलना कहती है कि डेटा अलग है, और हम panic लेबल पर जाते हैं।

यदि आप स्टैक पर डेटा को सहेजना चाहते हैं, तो इसे सही तरीके से रखें: पहले स्टैक पॉइंटर को कम करें, और फिर स्टैक के मान्य भाग में मान को सहेजें। रेड ज़ोन के पीछे डेटा छिपाएं नहीं, इस मेमोरी को आपकी जानकारी के बिना किसी भी समय बदला जा सकता है।