Intel® इंस्पेक्टर XE 2013: वास्तविक समय ऑटो सत्यापन और डीबगिंग

परीक्षण और समस्या निवारण एक अभिन्न और सॉफ्टवेयर विकास प्रक्रिया का सबसे दिलचस्प हिस्सा नहीं है। खुद की दिनचर्या से छुटकारा पाने के लिए, हर कोई इस प्रक्रिया को स्वचालित करने की कोशिश कर रहा है। और यदि आवेदन की कार्यक्षमता का परीक्षण करने के लिए विशेष घर-निर्मित परीक्षण बनाए जाते हैं, तो एक सामान्य प्रकार की त्रुटियों की खोज हमेशा उनके लिए कवर होती है। क्या आपके एप्लिकेशन की जाँच की जाती है, उदाहरण के लिए, मेमोरी लीक या डेटा रेस के लिए? इस लेख में, हम अपडेटेड इंस्पेक्टर XE 2013 को दो तरीकों से उपयोग करने का तरीका देखेंगे:

• नियमित स्वचालित परीक्षण (प्रतिगमन परीक्षण) के लिए
• डिबगर के साथ युग्मित समस्या के कारणों को मैन्युअल रूप से खोजने के लिए

इंस्पेक्टर XE की आवश्यकता क्यों है?

इंस्पेक्टर एक्सई इंटेल समानांतर स्टूडियो एक्सई से एक कोड शुद्धता विश्लेषण उपकरण है, लेकिन इसे एक अलग उत्पाद के रूप में भी आपूर्ति की जाती है। इसका उद्देश्य मेमोरी एरर (लीक, अनकंफर्टेबल मेमोरी तक पहुंच आदि) और स्ट्रीम (डेटा रेस, डेडलॉक आदि) के इंटरेक्शन के कारण होने वाली समस्याओं को खोजना है। इसी समय, समस्या को स्वयं प्रकट करने की आवश्यकता नहीं है - यदि कोई संभावित गतिरोध (गतिरोध) है, तो निरीक्षक XE इसे तब भी पाएगा जब प्रोग्राम "हैंग" नहीं होता (लेकिन कोड शाखा जिसमें यह हो सकता है) निष्पादित होता है।



निरीक्षक गतिशील विश्लेषण का उपयोग करता है, अर्थात स्रोत कोड का विश्लेषण नहीं किया गया है, लेकिन निष्पादन योग्य प्रक्रिया है। निष्पादन के दौरान, निरीक्षक विश्लेषण करता है कि आवेदन में क्या हो रहा है, यह कैसे मेमोरी आवंटित करता है और मुक्त करता है, थ्रेड बनाता है, सिंक्रनाइज़ेशन ऑब्जेक्ट्स का उपयोग करता है, आदि, जिसके बाद यह प्रोग्रामर को पाई गई समस्याओं की एक सूची देता है:



स्रोत दृश्य में एक अलग समस्या का अधिक विस्तार से अध्ययन किया जा सकता है:



स्रोतों का स्थैतिक विश्लेषण भी है, लेकिन यह इंटेल कंपाइलर द्वारा किया जाता है। और इंस्पेक्टर एक्सई प्रदर्शित करता है, विश्लेषण परिणामों की कल्पना करता है, आपको उन्हें फ़िल्टर करने, समस्याओं की स्थिति का प्रबंधन करने, आदि की अनुमति देता है। इस पोस्ट में हम इस विषय पर स्पर्श नहीं करेंगे।

वैसे, इंस्पेक्टर XE C / C ++, C #, और फोरट्रान कोड के साथ काम करता है। दो ऑपरेटिंग सिस्टम के लिए उपलब्ध: विंडोज * और लिनक्स *। दोनों में दो इंटरफेस हैं: एक जीयूआई और एक कमांड लाइन। इसके अलावा, विंडोज पर यह माइक्रोसॉफ्ट विजुअल स्टूडियो * में भी एकीकृत हो जाता है।

सिद्धांत रूप में, किसी भी निष्पादन योग्य फ़ाइल का निरीक्षण किया जा सकता है। हालांकि, समस्याओं का पता लगाने की संभावना बढ़ाने के लिए कई सिफारिशें हैं, उन्हें स्रोत कोड में देखें और इसके लिए बहुत अधिक समय न दें:

• / MDd, / ZI, / Od के साथ संकलित करें और / DEBUG और / FIXED के साथ लिंक: NO (एक उदाहरण के रूप में Microsoft कंपाइलर और लिंकर का उपयोग करके)। बायनेरिज़ और सोर्स कोड के एक समूह को प्रतीकात्मक जानकारी की आवश्यकता होती है, और अनुकूलन को बंद कर देना चाहिए ताकि इंस्पेक्टर XE कंपाइलर द्वारा भ्रमित न हो।
• मल्टीथ्रेडिंग त्रुटियों को खोजने के लिए, यदि संभव हो तो आवेदन पर भार कम करें। उदाहरण के लिए, इनपुट का आकार कम से कम करें। इससे समय की बचत होगी इंस्पेक्टर XE कार्यक्रम को धीमा कर देता है - गतिशील विश्लेषण और बाइनरी इंस्ट्रूमेंटेशन की लागत। लोड कम करने से परिणाम प्रभावित नहीं होगा, क्योंकि निरीक्षक प्रवाह की बातचीत में संभावित समस्याओं की तलाश कर रहा है।
• मेमोरी त्रुटियों की खोज करने के लिए, इसके विपरीत, पूर्ण डेटा सेट का उपयोग करना बेहतर है, क्योंकि इस प्रकार की त्रुटि के लिए, वास्तविक समस्याओं का पता लगाया जाता है।
• ऐसे परीक्षण चुनें जो कोड की विभिन्न शाखाओं को सक्रिय करते हैं। यदि कोड शाखा निष्पादित नहीं होती है, तो इसे पार्स नहीं किया जाएगा।

स्वचालित परीक्षण

इंस्पेक्टर XE - सत्यापन उपकरण। और सॉफ्टवेयर की गुणवत्ता और स्थिरता को उच्च स्तर पर बनाए रखने के लिए, नियमित रूप से सत्यापन किया जाना चाहिए। उदाहरण के लिए, आप रातोंरात प्रतिगमन परीक्षण के दौरान निरीक्षक को चला सकते हैं। ऐसा करने के लिए, टूल के कमांड इंटरफ़ेस का उपयोग करें। लिनक्स * और विंडोज * के लिए इंस्पेक्टर XE कमांड का सिंटैक्स समान है। विंडोज पर टेस्ट एप्लिकेशन विश्लेषण शुरू करने का एक उदाहरण:

inspxe-cl -collect mi3 -knob resources=true -knob still-allocated-memory=true -knob stack-depth=16 -knob analyze-stack=true -- D:\tests\testapps\mem_error.exe 

कमांड लाइन हमेशा इंस्पेक्टर के साथ ही शुरू होती है - "इंस्पेक्टर-सीएल"। "-कल्ट" कुंजी इंगित करती है कि आपको विश्लेषण चलाने की आवश्यकता है, "-mi3" - विश्लेषण का प्रकार (मेमोरी त्रुटियों की खोज, या "मेमोरी समस्याओं का पता लगाएँ")। इसके अलावा विश्लेषण के अन्य पैरामीटर और विश्लेषण किए गए अनुप्रयोग के लिए मार्ग हैं। पूर्ण सिंटैक्स और पैरामीटर सहायता को "इंस्पेक्-क्ल-फ़ेल्प" कमांड के साथ मुद्रित किया जा सकता है। इसके अलावा, यदि आप पहले से ही जीयूआई में काम कर रहे हैं और कमांड लाइन पर एक ही विश्लेषण चलाना चाहते हैं, तो एक "कमांड लाइन" बटन है जो जीयूआई में कॉन्फ़िगर किए गए विश्लेषण के लिए तैयार कमांड लाइन बनाएगा।

विश्लेषण पूरा होने के बाद, इंस्पेक्टर XE परिणाम फ़ाइलों के साथ एक फ़ोल्डर बनाएगा। उन्हें जीयूआई में देखा जा सकता है, और लिनक्स पर एकत्र किए गए परिणामों को किसी अन्य विंडोज मशीन (और इसके विपरीत) पर देखा जा सकता है। हालांकि, बस एक स्क्रिप्ट से विश्लेषण शुरू करना और फिर मैन्युअल रूप से परिणाम देखना पूर्ण स्वचालन नहीं है। इसलिए, निरीक्षक को सीएलआई में पाई गई समस्याओं के बारे में जानकारी प्रिंट करने की क्षमता है:

 inspxe-cl -report problems -r D:\tests\testapps\r002mi3 

 P1: Error: Mismatched allocation/deallocation New Problem P1.1: Mismatched allocation/deallocation D:\tests\testapps\mem_error.cpp(48): Error X10: Allocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp(49): Error X9: Mismatched deallocation site: Function start: Module D:\tests\testapps\mem_error.exe P3: Error: Invalid memory access New Problem P3.1: Invalid memory access D:\tests\testapps\mem_error.cpp (40): Error X4: Allocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp (42): Error X5: Deallocation site: Function start: Module D:\tests\testapps\mem_error.exe D:\tests\testapps\mem_error.cpp (44): Error X3: Read: Function start: Module D:\tests\testapps\mem_error.exe 

यदि सादा पाठ अच्छा नहीं है, तो आप इसे csv पर निर्यात कर सकते हैं, या इसे XML प्रारूप में प्रिंट कर सकते हैं ताकि सभी प्रकार के पर्ल और पायथन के साथ पार्स किया जा सके:

 inspxe-cl -report problems –format=xml -r D:\tests\r002mi3\ 

 <?xml version="1.0" encoding="UTF-8"?> <pset id="P1" type="Mismatched allocation/deallocation" state="New" severity="Error"> <obs id="X1" type="Allocation site" state="New" severity="Error"> <stack id="10"> <frame id="" module=" D:\tests\testapps\mem_error.exe" file="D:\tests\testapps\mem_error.cpp“ func="start" line="48"/> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start1" line="84"/> <frame id="" module="C:\Windows\syswow64\kernel32.dll“ func="BaseThreadInitThunk" line="78792"/> </stack> </obs> <obs id="X2" type="Mismatched deallocation site" state="New" severity="Error"> <stack id="9"> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start" line="49"/> <frame id="" module=" D:\tests\testapps\mem_error.exe " file="D:\tests\testapps\mem_error.cpp“ func="start1" line="84"/> </stack> </obs> </pset> 

विभिन्न प्रकार की समस्याओं में से, जिनमें से काफी कुछ एक बड़ी परियोजना पर पाया जा सकता है, नए और उल्लेखनीय लोगों को फ़िल्टर करना अभी भी आवश्यक है। इंस्पेक्टर एक्सई में समस्याओं (नए, पुष्टि, फिक्स्ड, आदि) को स्थिति निर्दिष्ट करने की क्षमता है। यदि परियोजना का नियमित रूप से निरीक्षण किया जाता है, तो गतिशीलता मुख्य रूप से दिलचस्प है - क्या हालिया परिवर्तनों के बाद से कुछ नया नहीं है? इस मामले के लिए, इंस्पेक्टर XE बदलावों का सारांश देते हुए विभिन्न लॉन्चों से समस्याओं के बारे में जानकारी को जोड़ सकता है:

 inspxe-cl –merge-states D:\tests\r000mi3\ -r D:\tests\r001mi3\ 

 inspxe-cl -report status -r D:\tests\r001mi3\ 

 9 problem(s) found 3 Investigated 6 Not investigated Breakdown by state: 2 Confirmed 1 Not a problem 4 Not fixed 2 Regression 

इंस्पेक्टर XE संभावित "मल्टीथ्रेडिंग त्रुटियों" को खोजने के लिए बहुत उपयोगी हो सकता है। डेटा रेस के साथ एक साधारण C ++ उदाहरण पर विचार करें। OpenMP का उपयोग करके लूप को समानांतर किया जाता है। पुनरावृत्ति स्थान को छोटे भागों में विभाजित किया गया है और इसे समानांतर में निष्पादित किया जा सकता है:

 #pragma omp parallel for shared(j) for(i=0; i<MAX; i++) { printf("j=%d ", j++); } if(j != MAX) printf(“error\n”); 

इस दौड़ के लिए कभी-कभी खुद को प्रकट करने के लिए, हमें MAX> 100,000,000 का उपयोग करने की आवश्यकता है, परीक्षण ने 10 मिनट से अधिक समय तक काम किया। इंस्पेक्टर XE को MAX = 10 और 10 सेकंड के साथ ऐसी समस्या का पता चलता है, क्योंकि संभावित डेटा दौड़ की तलाश में। बेशक, उदाहरण बहुत परिष्कृत है, लेकिन इसका उपयोग चित्रण के लिए किया जा सकता है। ऐसे मामलों में, निरीक्षक टेस्ट रन की प्रभावशीलता को बढ़ाएगा - प्रति यूनिट समय में अधिक समस्याएं।

अपनी खोज को कम करने के लिए, आप केवल कुछ एप्लिकेशन मॉड्यूल का विश्लेषण कर सकते हैं:

 inspxe-cl -collect mi1 -module-filter module1.dll,module2.dll -module-filter-mode exclude -- D:\tests\testapps\mem_error.exe 

"-मॉडल-फिल्टर-मोड" पैरामीटर निर्धारित करता है कि क्या हम निर्दिष्ट मॉड्यूल को विश्लेषण (बहिष्कृत) या इसके विपरीत से बाहर करना चाहते हैं, केवल उनका विश्लेषण करें (शामिल करें)।

यदि आपको बच्चे की प्रक्रिया का विश्लेषण करने की आवश्यकता है - उदाहरण के लिए, यदि एप्लिकेशन स्क्रिप्ट से लॉन्च किया गया है, तो "-executable-of-interest" विकल्प का उपयोग करें:

 inspxe-cl -collect mi1 -executable-of-interest mem_error.exe -- D:\tests\testapps\startup_script.bat 

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

 inspxe-cl -export -archive-name my-new-archived_result.inspxez -include-sources -result-dir myRes 

टीम के काम के लिए, आप भी काम में आ सकते हैं:

• समस्याओं के बारे में पाठ रिपोर्ट और टिप्पणियां करने की क्षमता
• विभिन्न उपयोगकर्ताओं द्वारा परिणामों के एक साथ संपादन के खिलाफ संरक्षण
• सामान्य दमन नियम। यदि, उदाहरण के लिए, निरीक्षक ने एक विदेशी मॉड्यूल (सिस्टम लाइब्रेरी) में एक समस्या पाई जिसे आप ठीक नहीं करने जा रहे हैं, तो आप इसे विशेष रूप से चिह्नित कर सकते हैं - इसे दबाएं ताकि यह परिणाम को रोक न दे। दमन नियम एक विशेष फ़ाइल में संग्रहीत किए जाते हैं जो पूरी टीम के लिए सामान्य हो सकते हैं।

वह सब है। अब यह इंस्पेक्टर XE के लॉन्च को एकीकृत करने के लिए बना हुआ है और विश्लेषण परिणामों को उन लिपियों में शामिल करता है जो रात में परीक्षण करते हैं, लेकिन यह पहले से ही व्यक्तिगत है और इस पोस्ट में शामिल नहीं है।

इंस्पेक्टर + डिबगर = दो स्टीम बूट

इंस्पेक्टर XE का उपयोग करने के लिए एक अन्य मॉडल समस्या की तह तक पहुंचने के लिए समस्याओं की मैन्युअल रूप से खोज करना है। शायद कार्यक्रम में किसी प्रकार की बग है - कभी-कभी यह जमा देता है या क्रैश होता है। या रात में एक निरीक्षक द्वारा परीक्षण ने एक नई समस्या की खोज की है जिसे संबोधित करने की आवश्यकता है। या आपने बस एक बार फिर से बैठने और अपनी रचना की विश्वसनीयता को जांचने का फैसला किया।

इन मामलों में, डिबगर्स के साथ इंस्पेक्टर एक्सई को एकीकृत करना सहायक होगा। यह कार्यक्षमता बहुत पहले नहीं दिखाई दी थी - 2013 संस्करण में। फिलहाल, लिनक्स * पर gdb और इंटेल डीबगर डीबगर के साथ एकीकरण और विंडोज पर विजुअल स्टूडियो डीबगर का समर्थन किया गया है।

यदि हम एक अज्ञात समस्या की तलाश कर रहे हैं (आवेदन में कभी-कभी छोटी गाड़ी है), तो डिबगर के साथ निरीक्षक को शुरू करने के लिए विश्लेषण सेटिंग्स में "डिबगर को सक्षम करें जब समस्या का पता लगाएं" चुनें।



अब हम विश्लेषण शुरू करते हैं और प्रतीक्षा करते हैं - जैसे ही एक समस्या का पता चलता है, इंस्पेक्टर एक्सई निष्पादन को रोक देगा, और आप डिबगर के साथ इसमें खुदाई कर सकते हैं। यह सभी समस्याओं के लिए किया जाएगा।

यदि हम पहले से ही रात के परीक्षण के दौरान प्रकट किए गए किसी प्रकार के बग के लिए लक्ष्य कर रहे हैं, तो निरीक्षक में विश्लेषण परिणाम खोलें, समस्या पर राइट-क्लिक करें, "डिबग दिस प्रॉब्लम" चुनें। इंस्पेक्टर XE फिर से उसी विश्लेषण को शुरू करेगा, और जैसे ही विख्यात समस्या फिर से खुद को प्रकट करेगी, आप इसकी घटना के स्थान पर डिबगिंग सत्र में डूब जाएंगे:



आप निरीक्षक विश्लेषण विन्यास में डिबगर शुरू करने के लिए अपना ब्रेकपॉइंट भी सेट कर सकते हैं और तीसरा विकल्प चुन सकते हैं:



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

सारांश

इंस्पेक्टर XE मेमोरी त्रुटियों और बहु-थ्रेडेड निष्पादन के लिए एक सार्वभौमिक उपकरण के रूप में कार्य करता है। गतिशील विश्लेषण के माध्यम से, काफी जटिल, गहरे बैठे समस्याओं का पता लगाया जा सकता है। इसकी वजह से, विश्लेषण के तहत कार्यक्रम निष्पादन का समय काफी बढ़ सकता है। इंस्पेक्टर XE 2013 का उपयोग दोनों GUI में काम करने के लिए किया जा सकता है, एक डिबगर के साथ जोड़ा गया जो मुश्किल समस्याओं की जड़ों को खोजने में मदद करता है, और स्वचालित सत्यापन के लिए। लेकिन दोनों मामलों में, यह कोड की स्थिरता को बढ़ाने का काम करता है - जितनी अधिक समस्याएं हैं और जितनी जल्दी यह किया जाता है, उतना ही अधिक विश्वसनीय आवेदन समाप्त हो जाएगा।

इंटेल इंस्पेक्टर एक्सई

इंटेल समानांतर स्टूडियो XE 2013

इंस्पेक्टर XE 2013 प्रलेखन