स्थैतिक विश्लेषण: मीडिया प्लेयर और बग रहित ICQ में त्रुटियां

मैं कार्यक्रमों में त्रुटियों का दौरा और स्थैतिक कोड विश्लेषण की उपयोगिता का प्रदर्शन जारी रखूंगा।



यह पीवीएस-स्टूडियो के संस्करण के बारे में मेरी आखिरी पोस्ट है जो अभी डाउनलोड के लिए उपलब्ध नहीं है। मेरी योजना है कि एक हफ्ते में आप पहले से ही सामान्य नियमों के एक नए सेट के साथ पहले बीटा संस्करण की कोशिश कर सकते हैं।



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



दूसरी परियोजना कुतुम है । यह एक ओपन सोर्स क्रॉस-प्लेटफ़ॉर्म इंस्टेंट मैसेजिंग क्लाइंट है। नवंबर 2010 की शुरुआत में कोड का विश्लेषण किया गया था। स्रोत कोड सेट मुझे डेवलपर्स में से एक द्वारा प्रदान किया गया था, लेकिन आप आधिकारिक साइट से स्रोत कोड भी डाउनलोड कर सकते हैं। यह डेवलपर, वैसे, यहां मौजूद है - gorthauer87 ।







फेनेक मीडिया प्रोजेक्ट। एक छोटी सी सामान्य परियोजना जिसमें सामान्य संख्या में त्रुटियां हैं। यहाँ पहली गलती है। या पहले दो त्रुटियों, आप कैसे गिनती पर निर्भर करता है। सामान्य तौर पर, दो स्थानों पर चर 'b' के बजाय 'a' का उपयोग किया जाता है।

  int fennec_tag_item_compare (संरचना fennec_audiotag_item * a,
   संरचना fennec_audiotag_item * b)
 {
   इंट वी;
   अगर (a-> tsize && a-> tsize)
     v = abs (str_cmp (a-> tdata, a-> tdata));
   अन्यथा
     v 1 है;
   वापसी v;
 } 

PVS-Studio ने इस कोड की ओर इशारा किया, क्योंकि स्थिति "a-> tsize && a-> tsize" स्पष्ट रूप से संदिग्ध है।



नैदानिक ​​संदेश और कोड में त्रुटि का स्थान:

V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: a -> tsize && a -> tsize Media Library.c 1076

और अब प्रिय और हर प्रोग्रामर के दिल को प्रिय - अतिरिक्त अर्धविराम। यहाँ पहला स्निपेट है:

  int settings_default (शून्य)
 {
   ...
   for (i = 0; i <16; i ++);
     के लिए (j = 0? j <32; j ++)
     {
       settings.conversion.equalizer_bands.boost [i] [j] = 0.0;
       settings.conversion.equalizer_bands.preamp [i] = 0.0;
     }
 } 

पीवीएस-स्टूडियो संदेश और स्थान कोड:

V529 अजीब अर्धविराम ';' ऑपरेटर के लिए 'के बाद'। settings.c 483

दूसरा स्निपेट:

  int trans_rest (ट्रांसकोडर_सेटिंग्स * ट्रांस)
 {
   ...
   for (i = 0; i <16; i ++);
   {
     trans-> eq.eq.preamp [i] = 0.0;
     के लिए (j = 0? j <32; j ++)
     {
       trans-> eq.eq.boost [i] [j] = 0.0;
     }
   }
 } 

पीवीएस-स्टूडियो संदेश और स्थान कोड:

V529 अजीब अर्धविराम ';' ऑपरेटर के लिए 'के बाद'। settings.c 913

';' के साथ एक तीसरा और चौथा अंश है। लेकिन मैं इसे यहां नहीं दूंगा। सब कुछ एक ही प्रकार का और अविरल है।



इसके अलावा काफी गलती नहीं है, लेकिन लगभग। _Beginthreadex फ़ंक्शन के बजाय, CreateThread का उपयोग किया जाता है। Fennec में CreateThread के लिए कई कॉल हैं, लेकिन मैं केवल एक उदाहरण दूंगा:

  t_sys_thread_handle sys_thread_call (t_sys_thread_function cfcc)
 {
   अहस्ताक्षरित लंबा tpr = 0;
   अहस्ताक्षरित लंबा tid = 0;
   वापसी (t_sys_thread_handle)
     CreateThread (0, 0, cfunc, और tpr, 0, और tid);
 } 

पीवीएस-स्टूडियो चेतावनी और स्थान कोड:

V513 CreateThread / ExitThread फ़ंक्शंस के बजाय _beginthreadex / _endthreadex फ़ंक्शंस का उपयोग करें। system.c 331

मैं CreateThread / ExitThread के बजाय _beginthreadex / _endthreadex का उपयोग करने के प्रश्न के गहरे में नहीं जाऊंगा। मैं बहुत संक्षेप में लिखूंगा, और इस मुद्दे की विस्तृत चर्चा यहां , यहां और यहां पढ़ी जा सकती है ।



शास्त्र (MSDN पर) कहता है:



एक निष्पादन योग्य में एक धागा जो C रन-टाइम लाइब्रेरी (CRT) को कॉल करता है, उसे CreateThread और ExitThread के बजाय थ्रेड मैनेजमेंट के लिए _beginthreadex और _endthreadex फ़ंक्शन का उपयोग करना चाहिए; इसके लिए CRT के बहु-थ्रेडेड संस्करण के उपयोग की आवश्यकता है। यदि CreateThread का उपयोग करके बनाया गया एक धागा CRT कहता है, तो CRT कम-मेमोरी स्थितियों में प्रक्रिया को समाप्त कर सकता है।



सामान्य तौर पर, सुरक्षित होना बेहतर है और हमेशा _beginthreadex / _endthreadex को कॉल करें। वैसे, यह वही है जो जेफरी रिक्टर ने छठे अध्याय में करने की सिफारिश की है, "पेशेवर के लिए विंडोज: प्रभावी Win32 अनुप्रयोगों का निर्माण विंडोज के 64-बिट संस्करण की विशिष्टताओं को देखते हुए" / प्रति। अंग्रेजी से - 4 वां संस्करण।



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



वापस Fennec के लिए। पहली शुरुआत:

  #define uinput_size 1024
 typedef wchar_t पत्र;

 अक्षर uinput_text [uinput_size];

 string basewindows_getuserinput (const string title,
   कास्ट स्ट्रिंग कैप, कॉस्ट स्ट्रिंग डीटीएक्स)
 {
   memset (uinput_text, 0, uinput_size);
   ...
 } 

पीवीएस-स्टूडियो निदान और स्थान कोड:

V512 'मेमसेट' फ़ंक्शन की कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा। आधार windows.c 151

"मेमसेट (uinput_text, 0, uinput_size)" के साथ पहली नज़र में, सब कुछ ठीक है। और शायद यह और भी अच्छा था, उन दिनों में जब 'अक्षर' का प्रकार 'चार' था। लेकिन अब यह 'wchar_t' है और इसके परिणामस्वरूप हम बफर के केवल आधे हिस्से को ही साफ करते हैं।



दूसरा असफल समझौता:

  typedef wchar_t पत्र;
 पत्र का नाम [30];

 int Conv_EqualizerProc (HWND hwnd, UINT uMsg,
   WPARAM wParam, LPARAM lParam)
 {
   ...
   मेमसेट (eqp.name, 0, 30);
   ...
 } 

सच में जादू की संख्या बुराई है। ऐसा लगता है कि "sizeof (eqp.name)" लिखना मुश्किल नहीं है। लेकिन हम लगातार लिखते नहीं हैं और अपने पैरों को बार-बार शूट करना जारी रखते हैं :)।



पीवीएस-स्टूडियो निदान और स्थान कोड:

V512 'मेमसेट' फ़ंक्शन की कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा। आधार विंडोज़। 2892

खैर, एक और जगह में ऐसी बग है:

V512 'मेमसेट' फ़ंक्शन की कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा। ट्रांसकोड settings.c 588

शायद, कभी-कभी कुछ कार्यक्रमों में आपने देखा कि फाइलें खोलने / सहेजने के लिए संवाद अजीब चीजों के साथ काम करते हैं या उपलब्ध एक्सटेंशन के क्षेत्र में कुछ बकवास है। अब आपको पता चलेगा कि यह पैर कहाँ से बढ़ता है।



विंडोज एपीआई में ऐसी संरचनाएं हैं जिनमें स्ट्रिंगर्स को डबल शून्य के साथ समाप्त होना चाहिए। OPENFILENAME संरचना में सबसे अधिक इस्तेमाल किया जाने वाला lpstrFilter सदस्य है। यह पैरामीटर वास्तव में '\ 0' द्वारा अलग लाइनों के एक सेट की ओर इशारा करता है। और यह पता लगाने के लिए कि लाइनें खत्म हो गई हैं और हमें अंत में दो शून्य की आवश्यकता है।



जिसे भूलना बहुत आसान है। कोड स्निपेट:

  int JoiningProc (HWND hwnd, UINT uMsg,
   WPARAM wParam, LPARAM lParam)
 {
   ...
   OPENFILENAME लॉफ़न;
   मेमसेट (& lofn, 0, sizeof (lofn));
   ...
   lofn.lpstrFilter = uni ("सभी फाइलें (*। *) \ 0 *। *");
   ...
 } 

पीवीएस-स्टूडियो संदेश और स्थान कोड:

V540 सदस्य 'lpstrFilter' को दो 0 वर्णों द्वारा समाप्त स्ट्रिंग की ओर संकेत करना चाहिए। आधार windows.c 5309

संवाद सामान्य रूप से काम करेगा या नहीं यह इस बात पर निर्भर करता है कि "ऑल फाइल्स (*। *। \ \ \ *। *") लाइन के बाद मेमोरी में क्या स्थित होगा। सही के अनुसार, आपको "सभी फ़ाइलें (*। *) \ 0 * *। * \ 0" लिखना चाहिए। हमने स्पष्ट रूप से एक शून्य का संकेत दिया है, संकलक एक और शून्य जोड़ देगा।



अन्य संवादों के साथ एक समान दुर्भाग्य।

  int callback_presets_dialog (HWND hwnd, UINT msg,)
   WPARAM wParam, LPARAM lParam)
 {
   ...
   // बचाओ
   OPENFILENAME लॉफ़न;
   मेमसेट (& lofn, 0, sizeof (lofn));
   ...
   lofn.lpstrFilter = uni ("इक्वालाइज़र प्रीसेट (* .qq) \ 0 * .feq");
   ...
   ...
   // लोड
   ...
   lofn.lpstrFilter = uni ("इक्वालाइज़र प्रीसेट (* .qq) \ 0 * .feq");
   ...
 }
 int localsf_show_save_playlist (शून्य)
 {
   OPENFILENAME लॉफ़न;
   मेमसेट (& lofn, 0, sizeof (lofn));
   ...
   lofn.lpstrFilter = uni ("टेक्स्ट फ़ाइल (* .txt) \ 0 * .txt \ 0M3U फ़ाइल \ 0 * .m3u");
   ...
 } 

पीवीएस-स्टूडियो निदान और कोड में स्थान:

V540 सदस्य 'lpstrFilter' को दो 0 वर्णों द्वारा समाप्त स्ट्रिंग की ओर संकेत करना चाहिए। आधार windows.c 986

V540 सदस्य 'lpstrFilter' को दो 0 वर्णों द्वारा समाप्त स्ट्रिंग की ओर संकेत करना चाहिए। आधार विंडोज़। 1039

V540 सदस्य 'lpstrFilter' को दो 0 वर्णों द्वारा समाप्त स्ट्रिंग की ओर संकेत करना चाहिए। साझा कार्य

अब एक संदिग्ध समारोह। बहुत ही संदिग्ध। हालाँकि, वास्तव में यहाँ एक गलती है या यह केवल खराब तरीके से लिखा गया है, मुझे नहीं पता:

  अहस्ताक्षरित लंबी ml_cache_getcurrent_item (शून्य)
 {
   यदि (mode_ml)
     वापसी skin.sared-> audio.output.playlist.getcurrentindex ();
   अन्यथा
     वापसी skin.sared-> audio.output.playlist.getcurrentindex ();
 } 

पीवीएस-स्टूडियो निदान और कोड में स्थान:

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। मीडिया लाइब्रेरी window.c 430

मैंने Fennec के साथ आने वाले विभिन्न एक्सटेंशन मॉड्यूल का विश्लेषण नहीं किया। लेकिन कम दुखी जगह नहीं हैं। मैं केवल कुछ उदाहरण दूंगा। कोडेक एसीसी परियोजना से कोड का एक स्निपेट।

  शून्य MP4RtpHintTrack :: GetPayload (...)
 {
   ...
   अगर (pSlash! = NULL) {
     pSlash ++;
     अगर (pSlash! = '\ 0') {
       length = strlen (pRtpMap) - (pSlash - pRtpMap);
       * ppEncodingParams = (char *) MP4Calloc (लंबाई + 1);
       strncpy (* ppEncodingParams, pSlash, लंबाई);
     }
 } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश से निम्नानुसार है:

V528 यह अजीब है कि 'char' प्रकार के सूचक की तुलना '\ 0' मान से की जाती है। शायद इसका मतलब है: * pSlash! = '\ 0'। rtphint.cpp 346

यहाँ सूचक को रोकना भूल गया। यह पता चला है कि हम 0. के साथ सूचक की एक व्यर्थ तुलना कर रहे हैं। यह होना चाहिए: "अगर (* pSlash! = '\ 0')।"



डिकोडर एमपीईजी ऑडियो परियोजना से कोड स्निपेट:

  शून्य * tag_write_setframe (चार * temem,
   कास्ट चार * टिड, कास्ट स्ट्रिंग डस्ट)
 {
   ...
   अगर (lset)
   {
     fhead [11] = '\ 0';
     fhead [12] = '\ 0';
     fhead [13] = '\ 0';
     fhead [13] = '\ 0';
   }
   ...
 } 

पीवीएस-स्टूडियो निदान संदेश और कोड में स्थान:

V525 समान ब्लॉकों के संग्रह वाले कोड। चेक आइटम '11', '12', '13', '13' लाइनों में 716, 717, 718, 719. id3 editor.c 716

यहाँ यह कॉपी-पेस्ट :) की बुराई है।



कुल मिलाकर, फेनेक मीडिया प्रोजेक्ट में, पीवीएस-स्टूडियो में सामान्य-उद्देश्य विश्लेषण बहुत अच्छा साबित हुआ। विश्लेषण एक कम झूठी सकारात्मक दर के साथ किया गया था। कुल मिलाकर, पीवीएस-स्टूडियो ने 31 कोड स्निपेट की ओर इशारा किया। इसके अलावा, 19 स्थानों में, कोड को वास्तव में सही किया जाना चाहिए।



अब क्यूटीम प्रोजेक्ट पर चलते हैं।



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



आपको "गलतियों की टीम" के लिए एक बिंदु गिनना होगा।



इसका क्या मतलब है? इसका मतलब है:



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



2) पीवीएस-स्टूडियो में अधिक उन्नत डायग्नोस्टिक्स जाने और विकसित करने का एक लंबा रास्ता है। अब यह और स्पष्ट हो गया है कि इसके लिए क्या प्रयास करना चाहिए। लक्ष्य है कि कम से कम कुछ असली बग्स को क्यूटीआईएम में ढूंढना है।



क्या पीवीएस-स्टूडियो ने क्यूटीआईएम परियोजना के लिए कुछ उत्पादन किया? जारी किए गए। लेकिन कुछ और लगभग सभी झूठी सकारात्मक। कम से कम कुछ ब्याज में से, केवल निम्नलिखित को प्रतिष्ठित किया जा सकता है।



A) CreateThread फ़ंक्शन का उपयोग किया जाता है।



बी) कुछ अजीब विशेषताएं मिलीं। तब कुटिम लेखकों में से एक ने कहा कि ये भूल गए स्टब्स थे। अजीब बात यह है कि एक का नाम सेव (), दूसरा कैंसिल () है, लेकिन उनकी सामग्री समान है:

  शून्य XSettingsWindow :: बचा ()
 {
   QWidget * c = p-> stackedWidget-> currentWidget ();
   जबकि (p-> संशोधित किए गए बजट.काउंट ()) {
     SettingsWidget * विजेट = p-> संशोधितWidgets.takeFirst ();
     विजेट-> बचा ();
     अगर (विजेट! = c)
       विजेट-> हटाएं ();
   }
   p-> बटनबॉक्स-> करीब ();
 }

 शून्य XSettingsWindow :: रद्द करें ()
 {
   QWidget * c = p-> stackedWidget-> currentWidget ();  
   जबकि (p-> संशोधित किए गए बजट.काउंट ()) {
     SettingsWidget * विजेट = p-> संशोधितWidgets.takeFirst ();
     विजेट-> बचा ();
     अगर (विजेट! = c)
       विजेट-> हटाएं ();
   }  
   p-> बटनबॉक्स-> करीब ();
 } 

पीवीएस-स्टूडियो डायग्नोस्टिक्स:

V524 यह अजीब है कि 'रद्द करें' फ़ंक्शन 'सेव' फ़ंक्शन (xsettingswindow.cpp, लाइन 256) के बराबर है। xsettingswindow.cpp 268

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

---

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