पीवीएस-स्टूडियो विश्लेषक का उपयोग करके तीसरा क्रोमियम प्रोजेक्ट कोड सत्यापन

क्रोमियम ब्राउज़र बहुत तेजी से विकसित हो रहा है। उदाहरण के लिए, जब 2011 में हमने पहली बार इस परियोजना (समाधान) का परीक्षण किया, तो इसमें 473 परियोजनाएं शामिल थीं। अब, इसमें पहले से ही 1169 परियोजनाएं शामिल हैं। हम सोच रहे थे कि क्या क्रोम के विकास की गति में Google डेवलपर्स कोड की उच्चतम गुणवत्ता बनाए रखने में सक्षम थे। हाँ, वे कर सकते थे।

क्रोमियम

क्रोमियम Google द्वारा विकसित एक खुला स्रोत वेब ब्राउज़र है। क्रोमियम के आधार पर, Google Chrome ब्राउज़र बनाया जाता है। कोड पृष्ठ प्राप्त करें पर, आप सीख सकते हैं कि इस परियोजना के लिए स्रोत कोड कैसे डाउनलोड किया जाए।

कुछ सामान्य जानकारी

हम क्रोमियम प्रोजेक्ट की जांच करते थे, जिसके बारे में दो लेख हैं: पहला चेक (05/23/2011), दूसरा चेक (13/10/2011)। और हर समय उन्हें त्रुटियां मिलीं। यह कोड एनालाइज़र के लाभों के बारे में एक सूक्ष्म संकेत है।

अब (जुलाई 2013 में परियोजना का स्रोत कोड डाउनलोड किया गया था) क्रोमियम में 1169 परियोजनाएँ हैं । C / C ++ में स्रोत कोड की कुल राशि 260 मेगाबाइट है । इसके अलावा, आप उपयोग किए गए बाहरी पुस्तकालयों में एक और 450 मेगाबाइट जोड़ सकते हैं।

यदि हम 2011 में क्रोमियम परियोजना की अपनी पहली परीक्षा लेते हैं, तो हम देख सकते हैं कि बाहरी पुस्तकालयों की मात्रा पूरी तरह नहीं बदली है। लेकिन परियोजना का कोड ही 155 मेगाबाइट से 260 मेगाबाइट तक बढ़ गया है।

मनोरंजन के लिए, आइए चक्रवाती जटिलता की गणना करें

पीवीएस-स्टूडियो विश्लेषक में महान चक्रीय जटिलता वाले कार्यों की खोज करने की क्षमता है । आमतौर पर, ऐसे कार्य प्रत्याहार के लिए उम्मीदवार होते हैं। 1,160 परियोजनाओं की जाँच करने के बाद, मुझे स्वाभाविक रूप से दिलचस्पी हो गई कि उनमें से किसको नामांकन में चैंपियन "सबसे जटिल कार्य" कहा जा सकता है।

उच्चतम साइक्लोमैटिक जटिलता, 2782 के बराबर, क्रोमियम प्रोजेक्ट में वैलिडेटेटहंकैमड64 () फ़ंक्शन के अंतर्गत आता है। लेकिन उसे प्रतियोगिता से अयोग्य ठहराया जाना था। फ़ंक्शन सत्यापनकर्ता_x86_64.c फ़ाइल में स्थित है, जो ऑटो-जनरेट किया गया है। बहुत बुरा। और यह एक महाकाव्य रिकॉर्ड धारक होगा। मैं कभी इस तरह के चक्रवात की जटिलता में नहीं आया।

इस प्रकार, पहले तीन स्थान निम्नलिखित कार्य प्राप्त करते हैं:

1. WebKit पुस्तकालय। HTMLTokenizer :: nextToken () HTMLtokenizer.cpp फ़ाइल में कार्य करता है। साइक्लोमैटिक कठिनाई 1106 ।
2. मेसा लाइब्रेरी। Glmesl_lexer.cc फ़ाइल में _mesa_glsl_lex () फ़ंक्शन। चक्रवाती कठिनाई 1088 ।
3. Usrsctplib पुस्तकालय (कुछ अज्ञात एथलीट)। Htmltokenizer.cpp फ़ाइल में sctp_setopt () फ़ंक्शन। चक्रवाती कठिनाई 1026 ।

अगर किसी को पता नहीं है कि साइक्लोमैटिक जटिलता 1000 है, तो उसे न दें। मानसिक स्वास्थ्य बेहतर रहेगा :)। सामान्य तौर पर, यह बहुत कुछ।

कोड की गुणवत्ता

क्रोमियम प्रोजेक्ट कोड की गुणवत्ता के बारे में मैं क्या कह सकता हूं? गुणवत्ता अभी भी उत्कृष्ट है। हां, किसी भी बड़ी परियोजना के रूप में, आप हमेशा त्रुटियाँ पा सकते हैं। लेकिन यदि आप कोड की राशि से उनकी संख्या को विभाजित करते हैं, तो उनका घनत्व नगण्य होगा। यह बहुत कम त्रुटियों के साथ बहुत अच्छा कोड है। मैं एक साफ कोड के लिए पदक देता हूं। पिछला पदक माइक्रोसॉफ्ट से कैसाब्लांका परियोजना (C ++ REST SDK) में गया था।

चित्रा 1. क्रोमियम के रचनाकारों को पदक।

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

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

विश्लेषक 710 मेगाबाइट की कुल मात्रा के साथ दसियों हज़ारों फ़ाइलों को चबाने में कामयाब रहा, और इससे झुकना नहीं पड़ा। इस तथ्य के बावजूद कि परियोजना को उच्च योग्य डेवलपर्स द्वारा विकसित किया गया है और विभिन्न उपकरणों के साथ परीक्षण किया गया है, पीवीएस-स्टूडियो अभी भी दोषों की पहचान करने में कामयाब रहे। यह एक बड़ी उपलब्धि है! और आखिरी - उन्होंने समानांतर सत्यापन (एएमडी एफएक्स -8320 / 3.50 गीगाहर्ट्ज / आठ-कोर प्रोसेसर, 16.0 जीबी रैम) के कारण उचित समय (लगभग 5 घंटे) में किया।

कुछ कीड़े मिले

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

सीन N1 - टाइपो

Vector3dF Matrix3F::SolveEigenproblem(Matrix3F* eigenvectors) const { // The matrix must be symmetric. const float epsilon = std::numeric_limits<float>::epsilon(); if (std::abs(data_[M01] - data_[M10]) > epsilon || std::abs(data_[M02] - data_[M02]) > epsilon || std::abs(data_[M12] - data_[M21]) > epsilon) { NOTREACHED(); return Vector3dF(); } .... } 

V501 बाईं ओर और '-' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: data_ [M02] - data_ [M02] मैट्रिक्स3_f.cc 128

यह सत्यापित किया जाना चाहिए कि एक 3x3 मैट्रिक्स सममित है।

चित्रा 2. 3x3 मैट्रिक्स।

ऐसा करने के लिए, निम्नलिखित तत्वों की तुलना करें:

• M01 और M10
• M02 और M20
• एम 12 और एम 21

सबसे अधिक संभावना है, कोड कॉपी-पेस्ट तकनीक का उपयोग करके लिखा गया था। नतीजतन, सेल M02 की तुलना खुद से की जाती है। यहाँ इस तरह के एक मजेदार मैट्रिक्स क्लास है।

एक और सरल टाइपो:

 bool IsTextField(const FormFieldData& field) { return field.form_control_type == "text" || field.form_control_type == "search" || field.form_control_type == "tel" || field.form_control_type == "url" || field.form_control_type == "email" || field.form_control_type == "text"; } 

V501 समान उप-अभिव्यक्तियाँ 'field.form_control_type == "टेक्स्ट"' हैं बाईं और दाईं ओर '' || ऑपरेटर। autocomplete_history_manager.cc 35

दो बार स्ट्रिंग "पाठ" के साथ तुलना होती है। यह संदिग्ध है। शायद एक लाइन सिर्फ सतही है। या हो सकता है कि यहां कोई अन्य तुलना की आवश्यकता न हो।

सीन एन 2 - विपरीत परिस्थितियों

 static void ParseRequestCookieLine( const std::string& header_value, ParsedRequestCookies* parsed_cookies) { std::string::const_iterator i = header_value.begin(); .... if (*i == '"') { while (i != header_value.end() && *i != '"') ++i; .... } 

V637 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी शर्त हमेशा झूठी होती है। चेक लाइनें: 500, 501. web_request_api_helpers.cc 500

यह मुझे लगता है कि इस कोड को दोहरे उद्धरणों द्वारा तैयार पाठ पारित करना चाहिए था। लेकिन वास्तव में, यह कोड कुछ भी नहीं करता है। हालत तुरंत झूठी है। स्पष्टता के लिए, मैं त्रुटि के सार पर जोर देने के लिए एक छद्मांक लिखूंगा:

 if ( A == 'X' ) { while ( .... && A != 'X' ) ....; 

सबसे अधिक संभावना है, वे पॉइंटर को एक पात्र में स्थानांतरित करना भूल गए और कोड को इस तरह दिखना चाहिए:

 if (*i == '"') { ++i; while (i != header_value.end() && *i != '"') ++i; 

सीन N3 - हटाए गए तत्वों को विफल कर दिया

 void ShortcutsProvider::DeleteMatchesWithURLs( const std::set<GURL>& urls) { std::remove_if(matches_.begin(), matches_.end(), RemoveMatchPredicate(urls)); listener_->OnProviderUpdate(true); } 

V530 '' remove_if 'फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। shortcuts_provider.cc 136

कंटेनर से तत्वों को निकालने के लिए, std :: remove_if () फ़ंक्शन का उपयोग करें। लेकिन इसका इस्तेमाल गलत तरीके से किया जाता है। वास्तव में, remove_if () कुछ भी नहीं हटाता है। यह तत्वों को शुरुआत में स्थानांतरित करता है और पुनरावृत्त को कूड़ेदान में लौटाता है। आपको कंटेनरों पर मिटा () फ़ंक्शन को कॉल करके कचरा स्वयं को हटाने की आवश्यकता है। विकिपीडिया लेख " मिटा-हटा मुहावरा " भी देखें।

सही कोड है:

 matches_.erase(std::remove_if(.....), matches_.end()); 

सीन N4 - शाश्वत के साथ अनन्त भ्रम

लिनक्स दुनिया में SOCKET, एक पूर्णांक हस्ताक्षर डेटा प्रकार है।

Windows दुनिया में SOCKET, यह एक पूर्णांक UNSIGNABLE डेटा प्रकार है।

दृश्य C ++ शीर्ष लेख फ़ाइलों में, SOCKET प्रकार इस प्रकार घोषित किया गया है:

 typedef UINT_PTR SOCKET; 

हालांकि, वे लगातार इसके बारे में भूल जाते हैं और निम्नलिखित फॉर्म का कोड लिखते हैं:

 class NET_EXPORT_PRIVATE TCPServerSocketWin { .... SOCKET socket_; .... }; int TCPServerSocketWin::Listen(....) { .... socket_ = socket(address.GetSockAddrFamily(), SOCK_STREAM, IPPROTO_TCP); if (socket_ < 0) { PLOG(ERROR) << "socket() returned an error"; return MapSystemError(WSAGetLastError()); } .... } 

V547 अभिव्यक्ति 'सॉकेट_ <0' हमेशा गलत होती है। अहस्ताक्षरित प्रकार का मान कभी <0। Tcp_server_socket_win.cc 48 नहीं है

एक अहस्ताक्षरित चर हमेशा शून्य से अधिक या उसके बराबर होता है। इसका मतलब यह है कि 'सॉकेट_ <0' के लिए जाँच करने का कोई मतलब नहीं है। यदि प्रोग्राम के संचालन के दौरान सॉकेट नहीं खोला जा सकता है, तो इस स्थिति को सही ढंग से संसाधित नहीं किया जाएगा।

सीन N5 - संचालन के साथ भ्रम ~ और!

 enum FontStyle { NORMAL = 0, BOLD = 1, ITALIC = 2, UNDERLINE = 4, }; void LabelButton::SetIsDefault(bool is_default) { .... style = is_default ? style | gfx::Font::BOLD : style & !gfx::Font::BOLD; .... } 

V564 '&' ऑपरेटर बूल प्रकार के मूल्य पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। लेबल_बटन.सीसी 131

मुझे लगता है कि कोड को इस तरह काम करना चाहिए था:

• यदि चर 'is_default' सत्य है, तो आपको हमेशा उस बिट को सेट करने की आवश्यकता होती है जो BOLD शैली के लिए ज़िम्मेदार है।
• यदि चर 'is_default' झूठा है, तो आपको हमेशा BOLD शैली के लिए थोड़ा जिम्मेदार होने की आवश्यकता है।

हालाँकि, प्रोग्रामर को उम्मीद है कि "स्टाइल एंड! Gfx :: Font :: BOLD" काम नहीं करता है। ऑपरेशन का परिणाम! Gfx :: Font :: BOLD गलत होगा। या दूसरे शब्दों में, 0. ऊपर लिखा कोड इसके बराबर है:

 style = is_default ? style | gfx::Font::BOLD : 0; 

कोड को सही ढंग से काम करने के लिए, ऑपरेशन '~' का उपयोग किया जाना चाहिए:

 style = is_default ? style | gfx::Font::BOLD : style & ~gfx::Font::BOLD; 

सीन N6 - अस्थायी वस्तुओं का संदिग्ध निर्माण

 base::win::ScopedComPtr<IDirect3DSurface9> scaler_scratch_surfaces_[2]; bool AcceleratedSurfaceTransformer::ResizeBilinear( IDirect3DSurface9* src_surface, ....) { .... IDirect3DSurface9* read_buffer = (i == 0) ? src_surface : scaler_scratch_surfaces_[read_buffer_index]; .... } 

V623 ':?' 'संचालक का निरीक्षण करने पर विचार करें। 'ScopedComPtr' प्रकार का एक अस्थायी ऑब्जेक्ट बनाया जा रहा है और बाद में नष्ट हो गया है। दूसरे ऑपरेंड की जाँच करें। accelerated_surface_transformer_win.cc 391

इस कोड में त्रुटि होने की संभावना नहीं है, लेकिन इसके बारे में बताया जाना चाहिए। यह मुझे लगता है कि कुछ प्रोग्रामर C ++ भाषा में एक नए दिलचस्प जाल के बारे में जानेंगे।

पहली नज़र में, सब कुछ सरल है। स्थिति के आधार पर, हम सूचक 'src_surface' या 'scaler_scratch_surfaces_' सरणी के तत्वों में से एक का चयन करते हैं। सरणी में बेस बेस की वस्तुएं शामिल हैं :: जीत :: ScopedComPtr <IDirect3DSurface9>, जो स्वचालित रूप से IDirect3DSurface9 के लिए एक संकेतक में डाली जा सकती है।

शैतान विवरण में है।

टर्नेरी ऑपरेटर '?:' शर्त के आधार पर एक अलग प्रकार नहीं लौटा सकता। मैं एक सरल उदाहरण के साथ समझाऊंगा।

 int A = 1; auto X = v ? A : 2.0; 

?: ऑपरेटर एक प्रकार का 'डबल' देता है। परिणामस्वरूप, चर 'X' भी डबल प्रकार का होगा। लेकिन इससे कोई फर्क नहीं पड़ता। यह महत्वपूर्ण है कि चर 'ए' का प्रकार 'डबल' टाइप किया जाएगा!

अगर आप कुछ इस तरह से लिखते हैं तो यह परेशानी पैदा होती है:

 CString s1(L"1"); wchar_t s2[] = L"2"; bool a = false; const wchar_t *s = a ? s1 : s2; 

इस कोड के निष्पादन के परिणामस्वरूप, चर 's' टाइप CString के अस्थायी ऑब्जेक्ट के अंदर डेटा को इंगित करेगा। समस्या यह है कि यह वस्तु तुरंत नष्ट हो जाएगी।

अब क्रोमियम के स्रोत कोड पर वापस जाएं।

 IDirect3DSurface9* read_buffer = (i == 0) ? src_surface : scaler_scratch_surfaces_[read_buffer_index]; 

यहाँ स्थिति 'i == 0' पूरी होने पर निम्नलिखित होगी:

• बेस बेस का एक अस्थायी ऑब्जेक्ट :: win :: ScopedComPtr <IDirect3DSurface9> का निर्माण सूचक 'src_surface' से किया जाएगा;
• अस्थायी वस्तु को परोक्ष रूप से एक IDirect3DSurface9 पॉइंटर में डाला जाएगा और read_buffer चर में रखा जाएगा;
• अस्थायी वस्तु नष्ट हो जाएगी।

मुझे कार्यक्रम और ScopedComPtr वर्ग के तर्क का पता नहीं है और यह कहना मुश्किल है कि नकारात्मक परिणाम हो सकते हैं या नहीं। सबसे अधिक संभावना है, कंस्ट्रक्टर में लिंक की संख्या का काउंटर बढ़ाया जाएगा, और विध्वंसक में कम हो जाएगा। और सब ठीक हो जाएगा।

यदि यह मामला नहीं है, तो अनजाने में आप एक अवैध सूचक प्राप्त कर सकते हैं या संदर्भ गणना तोड़ सकते हैं।

एक शब्द में, भले ही कोई गलती न हो, मुझे खुशी होगी अगर पाठकों ने कुछ नया सीखा है। जितना सुनाई देता है उससे कहीं अधिक खतरनाक टर्नरी ऑपरेटर है।

यहाँ एक और ऐसी संदिग्ध जगह है:

 typedef GenericScopedHandle<HandleTraits, VerifierTraits> ScopedHandle; DWORD HandlePolicy::DuplicateHandleProxyAction(....) { .... base::win::ScopedHandle remote_target_process; .... HANDLE target_process = remote_target_process.IsValid() ? remote_target_process : ::GetCurrentProcess(); .... } 

V623 ':?' 'संचालक का निरीक्षण करने पर विचार करें। 'GenericScopedHandle' प्रकार का एक अस्थायी ऑब्जेक्ट बनाया जा रहा है और बाद में नष्ट हो गया है। तीसरे ऑपरेंड की जाँच करें। handle_policy.cc 81

सीन N7 - आवर्ती चेक

 string16 GetAccessString(HandleType handle_type, ACCESS_MASK access) { .... if (access & FILE_WRITE_ATTRIBUTES) output.append(ASCIIToUTF16("\tFILE_WRITE_ATTRIBUTES\n")); if (access & FILE_WRITE_DATA) output.append(ASCIIToUTF16("\tFILE_WRITE_DATA\n")); if (access & FILE_WRITE_EA) output.append(ASCIIToUTF16("\tFILE_WRITE_EA\n")); if (access & FILE_WRITE_EA) output.append(ASCIIToUTF16("\tFILE_WRITE_EA\n")); .... } 

V581 एक-दूसरे के साथ स्थित 'if' ऑपरेटर के सशर्त भाव समान हैं। चेक लाइनें: 176, 178. हैंडल_मेंटर_विन.सीसी 178

यदि FILE_WRITE_EA ध्वज सेट किया गया है, तो दो बार ड्रेन "tFILE_WRITE_EA \ n" जोड़ा जाएगा। बहुत संदिग्ध कोड।

इसी तरह की एक अजीब तस्वीर यहाँ देखी जा सकती है:

 static bool PasswordFormComparator(const PasswordForm& pf1, const PasswordForm& pf2) { if (pf1.submit_element < pf2.submit_element) return true; if (pf1.username_element < pf2.username_element) return true; if (pf1.username_value < pf2.username_value) return true; if (pf1.username_value < pf2.username_value) return true; if (pf1.password_element < pf2.password_element) return true; if (pf1.password_value < pf2.password_value) return true; return false; } 

V581 एक-दूसरे के साथ स्थित 'if' ऑपरेटर के सशर्त भाव समान हैं। चेक लाइनें: 259, 261. profile_sync_service_password_unittest.cc 261

"Pf1.username_value <pf2.username_value" चेक दो बार दोहराया जाता है। शायद एक लाइन सिर्फ सतही है। या शायद वे कुछ और जांचना भूल गए, और एक पूरी तरह से अलग स्थिति लिखी जानी चाहिए।

सीन एन 8 - "एक बार" चक्र

 ResourceProvider::ResourceId PictureLayerImpl::ContentsResourceId() const { .... for (PictureLayerTilingSet::CoverageIterator iter(....); iter; ++iter) { if (!*iter) return 0; const ManagedTileState::TileVersion& tile_version = ....; if (....) return 0; if (iter.geometry_rect() != content_rect) return 0; return tile_version.get_resource_id(); } return 0; } 

V612 लूप के भीतर बिना शर्त 'वापसी'। picture_layer_impl.cc 638

इस चक्र में कुछ गड़बड़ है। लूप केवल एक पुनरावृत्ति करता है। लूप के अंत में बिना शर्त रिटर्न स्टेटमेंट है। संभावित कारण:

• तो यह कल्पना की है। लेकिन यह बहुत ही संदिग्ध है। फिर एक लूप क्यों बनाएं, एक इटरेटर बनाएं, आदि।
• 'वापसी' में से एक के बजाय, 'जारी रखें' लिखा जाना चाहिए। लेकिन यह भी संदिग्ध।
• सबसे अधिक संभावना है, अंतिम 'वापसी' से पहले कुछ स्थिति गायब है।

अन्य अजीब लूप हैं जो केवल एक बार चलते हैं:

 scoped_ptr<ActionInfo> ActionInfo::Load(....) { .... for (base::ListValue::const_iterator iter = icons->begin(); iter != icons->end(); ++iter) { std::string path; if (....); return scoped_ptr<ActionInfo>(); } result->default_icon.Add(....); break; } .... } 

V612 लूप के भीतर बिना शर्त 'ब्रेक'। action_info.cc 76

 const BluetoothServiceRecord* BluetoothDeviceWin::GetServiceRecord( const std::string& uuid) const { for (ServiceRecordList::const_iterator iter = service_record_list_.begin(); iter != service_record_list_.end(); ++iter) { return *iter; } return NULL; } 

V612 लूप के भीतर बिना शर्त 'वापसी'। bluetooth_device_win.cc 224

सीन N9 - अनइंस्टॉल किए गए चर

 HRESULT IEEventSink::Attach(IWebBrowser2* browser) { DCHECK(browser); HRESULT result; if (browser) { web_browser2_ = browser; FindIEProcessId(); result = DispEventAdvise(web_browser2_, &DIID_DWebBrowserEvents2); } return result; } 

V614 संभावित रूप से असंगठित चर 'परिणाम' का इस्तेमाल किया। ie_event_sink.cc 240

यदि 'ब्राउजर' पॉइंटर शून्य है, तो फंक्शन अनइंस्टॉल किया गया वेरिएबल लौटाएगा।

कोड का एक और टुकड़ा:

 void SavePackage::GetSaveInfo() { .... bool skip_dir_check; .... if (....) { ....->GetSaveDir(...., &skip_dir_check); } .... BrowserThread::PostTask(BrowserThread::FILE, FROM_HERE, base::Bind(..., skip_dir_check, ...)); } 

V614 संभावित रूप से असंगठित चर 'Skip_dir_check' का उपयोग किया जाता है। 'बिंद' फ़ंक्शन के पांचवें वास्तविक तर्क की जाँच करने पर विचार करें। save_package.cc 1326

चर 'Skip_dir_check' अनधिकृत रह सकता है।

अधिसूचित N10 - कोड संरेखण इसके संचालन के तर्क से मेल नहीं खाता है

 void OnTraceNotification(int notification) { if (notification & TraceLog::EVENT_WATCH_NOTIFICATION) ++event_watch_notification_; notifications_received_ |= notification; } 

V640 कोड का परिचालन तर्क इसके प्रारूपण के अनुरूप नहीं है। कथन सही के लिए प्रेरित है, लेकिन इसे हमेशा निष्पादित किया जाता है। यह संभव है कि घुंघराले कोष्ठक गायब हैं। ट्रेस_एवेंट_ यूनीटेस्ट.सीसी 57

इस तरह के कोड को ध्यान में रखते हुए, यह स्पष्ट नहीं है कि घुंघराले कोष्ठक यहां भूल गए हैं या नहीं। यहां तक ​​कि अगर कोड सही है, तो इसे सही किया जाना चाहिए ताकि यह अन्य प्रोग्रामर को एक विचारशील स्थिति में न ले जाए।

यहां बहुत सारे संदिग्ध कोड संरेखण के साथ स्थान दिए गए हैं:

• nss_memio.c 152
• nss_memio.c 184

नोटिफ़ाइड N11 - पॉइंटर चेक न्यू के बाद

कई कार्यक्रमों में पुराने विरासत कोड वापस लिखे गए हैं, जब 'नया' ऑपरेटर अपवाद नहीं छोड़ता था। पहले, अपर्याप्त स्मृति के मामले में, यह एक अशक्त सूचक लौटाता है।

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

एक उदाहरण पर विचार करें:

 static base::DictionaryValue* GetDictValueStats( const webrtc::StatsReport& report) { .... DictionaryValue* dict = new base::DictionaryValue(); if (!dict) return NULL; dict->SetDouble("timestamp", report.timestamp); base::ListValue* values = new base::ListValue(); if (!values) { delete dict; return NULL; } .... } 

V668 नल के खिलाफ 'तानाशाह' सूचक के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। peer_connection_tracker.cc 164

V668 नल के खिलाफ 'मान' पॉइंटर के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। peer_connection_tracker.cc 169

पहला चेक "if (? Dict) NULL को लौटाएगा", कोई नुकसान नहीं होने की संभावना है। लेकिन दूसरा चेक खराब है। यदि "नया आधार :: ListValue ()" का उपयोग करके कोई ऑब्जेक्ट बनाते हैं, तो मेमोरी आवंटित करना संभव नहीं है, एक अपवाद 'std :: bad_alloc' फेंका जाएगा। यह GetDictValueStats () फ़ंक्शन के संचालन को पूरा करता है।

नतीजतन, यहां यह कोड है:

 if (!values) { delete dict; return NULL; } 

ऐसी वस्तु को कभी नष्ट नहीं करेगा जिसका पता 'अधिमान' चर में जमा हो।

यहां सही समाधान कोड को रिफलेक्टर करना और स्मार्ट पॉइंटर्स का उपयोग करना होगा।

कोड के एक और टुकड़े पर विचार करें:

 bool Target::Init() { { .... ctx_ = new uint8_t[abi_->GetContextSize()]; if (NULL == ctx_) { Destroy(); return false; } .... } 

V668 नल के खिलाफ 'ctx_' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। target.cc 73

स्मृति आवंटन त्रुटि की स्थिति में, नष्ट () फ़ंक्शन को नहीं कहा जाएगा।

इसके बारे में आगे लिखना दिलचस्प नहीं है। मैं कोड में देखे गए अन्य संभावित खतरनाक स्थानों की सूची दूंगा:

• 'डेटा' सूचक। target.cc 109
• 'page_data' पॉइंटर। mock_printer.cc 229
• 'मॉड्यूल' सूचक। काली मिर्च_कोन्ट्रीपॉइंट। सी सी 39
• 'c_protocols' पॉइंटर। websocket.cc 44
• 'type_enum' पॉइंटर। pin_base_win.cc 96
• 'pin_enum' पॉइंटर। फ़िल्टर_बेस_विन.सीसी win५
• 'Port_data'। port_monitor.cc 388
• 'xcv_data' सूचक। port_monitor.cc 552
• 'Monitor_data'। port_monitor.cc 625
• 'प्रेषक_' सूचक। crash_service.cc 221
• 'कैश' पॉइंटर। crash_cache.cc 269
• 'current_browser' पॉइंटर। Print_preview_dialog_controller.cc 403
• 'udp_socket' सूचक। network_stats.cc 212
• 'popup_' सूचक। try_chrome_dialog_view.cc 90

सीन एन 12 - परीक्षण जो खराब परीक्षण करते हैं

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

क्रोमियम के परीक्षणों में मुझे मिली त्रुटियों के कुछ उदाहरण यहां दिए गए हैं:

 std::string TestAudioConfig::TestValidConfigs() { .... static const uint32_t kRequestFrameCounts[] = { PP_AUDIOMINSAMPLEFRAMECOUNT, PP_AUDIOMAXSAMPLEFRAMECOUNT, 1024, 2048, 4096 }; .... for (size_t j = 0; j < sizeof(kRequestFrameCounts)/sizeof(kRequestFrameCounts); j++) { .... } 

V501 समान उप-अभिव्यक्तियाँ 'sizeof (kRequestFrameCounts)' बाईं ओर और '/' ऑपरेटर के दाईं ओर हैं। test_audio_config.cc 56

केवल एक परीक्षण एक लूप में निष्पादित किया जाएगा। त्रुटि यह है कि "sizeof (kRequestFrameCounts) / sizeof (kRequestFrameCounts)" एक है। सही अभिव्यक्ति "sizeof (kRequestFrameCounts) / sizeof (kRequestFrameCounts [0]) है।"

एक और त्रुटि परीक्षण:

 void DiskCacheEntryTest::ExternalSyncIOBackground(....) { .... scoped_refptr<net::IOBuffer> buffer1(new net::IOBuffer(kSize1)); scoped_refptr<net::IOBuffer> buffer2(new net::IOBuffer(kSize2)); .... EXPECT_EQ(0, memcmp(buffer2->data(), buffer2->data(), 10000)); .... } 

V549 'मेमकैंप' फ़ंक्शन का पहला तर्क दूसरे तर्क के बराबर है। entry_unittest.cc 393

मेम्कैंप () फ़ंक्शन बफर की खुद के साथ तुलना करता है। नतीजतन, परीक्षण आवश्यक परीक्षण नहीं करता है। जाहिर है, यहाँ होना चाहिए:

 EXPECT_EQ(0, memcmp(buffer1->data(), buffer2->data(), 10000)); 

और यहाँ एक परीक्षण है जो अचानक अन्य परीक्षणों को तोड़ सकता है:

 static const int kNumPainters = 3; static const struct { const char* name; GPUPainter* painter; } painters[] = { { "CPU CSC + GPU Render", new CPUColorPainter() }, { "GPU CSC/Render", new GPUColorWithLuminancePainter() }, }; int main(int argc, char** argv) { .... // Run GPU painter tests. for (int i = 0; i < kNumPainters; i++) { scoped_ptr<GPUPainter> painter(painters[i].painter); .... } 

V557 ऐरे ओवररन संभव है। 'I' इंडेक्स का मान 2. shader_bench.cc 152 तक पहुंच सकता है

शायद पहले के 'चित्रकारों' की सरणी में तीन तत्व शामिल थे। अब उनमें से केवल दो हैं। और निरंतर 'kNumPainters' का मान 3 के बराबर रहता है।

परीक्षणों में कुछ अन्य स्थान जो मुझे लगता है कि ध्यान देने योग्य हैं:

V579 स्ट्रिंग फ़ंक्शन सूचक और उसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। दूसरे तर्क का निरीक्षण करें। Syncable_unittest.cc 1790

V579 स्ट्रिंग फ़ंक्शन सूचक और उसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। दूसरे तर्क का निरीक्षण करें। Syncable_unittest.cc 1800

V579 स्ट्रिंग फ़ंक्शन सूचक और उसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। दूसरे तर्क का निरीक्षण करें। Syncable_unittest.cc 1810

V595 nullptr के खिलाफ सत्यापित होने से पहले 'ब्राउज़र' पॉइंटर का उपयोग किया गया था। जाँच रेखाएँ: 5489, 5493. test_automation_provider.cc 5489

V595 nullptr के खिलाफ सत्यापित होने से पहले 'Wait_for_.get ()' पॉइंटर का उपयोग किया गया था। चेक लाइन्स: 205, 222. डाउनलोड_पाइ_युनिटेस्ट.सीसी 205

N5ptr के खिलाफ सत्यापित होने से पहले V595 'pNPWindow' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 34, 35. प्लगइन_विशिष्ट_स्टेस्ट.सीसी 34

N5ptr के खिलाफ सत्यापित होने से पहले V595 'pNPWindow' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 16, 20. प्लगइन_विंडो_साइज़_टैस्ट।सीसी 16

V595 nullptr के विरुद्ध सत्यापित होने से पहले 'textfield_view_' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 182, 191. native_textfield_views_unittest.cc 182

V595 nullptr के विरुद्ध सत्यापित होने से पहले 'message_loop_' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 53, 55. test_flash_message_loop.cc 53

सीन N13 - परिवर्तन की संख्या के साथ फ़ंक्शन

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

एक उदाहरण:

 DWORD GetLastError(VOID); void TryOpenFile(wchar_t *path, FILE *output) { wchar_t path_expanded[MAX_PATH] = {0}; DWORD size = ::ExpandEnvironmentStrings( path, path_expanded, MAX_PATH - 1); if (!size) { fprintf(output, "[ERROR] Cannot expand \"%S\". Error %S.\r\n", path, ::GetLastError()); } .... } 

V576 गलत प्रारूप। 'फ़र्फ़रफ़' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। Wchar_t प्रकार के प्रतीकों के स्ट्रिंग के लिए सूचक अपेक्षित है। fs.cc 17

यदि चर 'आकार' शून्य है, तो प्रोग्राम फ़ाइल में एक पाठ संदेश लिखने की कोशिश करेगा। लेकिन इस संदेश में अंत में बिलियर्ड्स शामिल होने की संभावना है। इसके अलावा, यह कोड उल्लंघन का कारण बन सकता है।

यह लिखने के लिए fprintf () फ़ंक्शन का उपयोग करता है। यह फ़ंक्शन अपने तर्कों के प्रकारों को नियंत्रित नहीं करता है। वह अंतिम तर्क को स्ट्रिंग के लिए एक संकेतक होने की उम्मीद करता है। लेकिन वास्तव में, वास्तविक तर्क एक संख्या (त्रुटि कोड) है। इस नंबर को एक पते में बदल दिया जाएगा और प्रोग्राम आगे कैसे व्यवहार करेगा यह अज्ञात है।

किसी का ध्यान नहीं

एक बार फिर, मैं संदेशों की सूची को सतही रूप से देख रहा था। मैंने इस लेख में उद्धृत किया है कि मेरा ध्यान क्या आकर्षित करता है। इसके अलावा, मैंने लेख में जितना लिखा है, उससे अधिक ध्यान दिया। सब कुछ के बारे में बताते हुए, मैं बहुत लंबा लेख प्राप्त करता हूं। और वह पहले से ही बहुत बड़ा है।

मैंने कोड के इतने टुकड़े फेंक दिए कि मुझे लगता है कि यह पाठक के लिए बहुत दिलचस्प नहीं होगा। मैं स्पष्टता के लिए कुछ उदाहरण दूंगा।

 bool ManagedUserService::UserMayLoad( const extensions::Extension* extension, string16* error) const { if (extension_service && extension_service->GetInstalledExtension(extension->id())) return true; if (extension) { bool was_installed_by_default = extension->was_installed_by_default(); ..... } } 

N5ptr के खिलाफ सत्यापित होने से पहले V595 'एक्सटेंशन' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 277, 280. प्रबंधित_युजर_ सर्विस।सीसी 277

शुरुआत में, 'एक्सटेंशन' पॉइंटर को "एक्सटेंशन-> आईडी ()" के रूप में दर्शाया गया है। तब इस सूचक को शून्य की समानता के लिए जाँच की जाती है।

अक्सर, ऐसे कोड में त्रुटियां नहीं होती हैं। ऐसा होता है कि पॉइंटर बस शून्य नहीं हो सकता है और चेक बेमानी है। इसलिए, ऐसी जगहों को सूचीबद्ध करने का कोई मतलब नहीं है, क्योंकि मैं गलती कर सकता हूं और त्रुटि के लिए पूरी तरह से काम करने वाला कोड दे सकता हूं।

यहाँ एक और नैदानिक ​​उदाहरण है जिसे मैंने नोटिस नहीं किया है:

 bool WebMClusterParser::ParseBlock(....) { int timecode = buf[1] << 8 | buf[2]; .... if (timecode & 0x8000) timecode |= (-1 << 16); .... } 

V610 अपरिभाषित व्यवहार। शिफ्ट ऑपरेटर की जाँच करें <<। बायां संचालक '-1' ऋणात्मक है। webm_cluster_parser.cc 217

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

झूठी सकारात्मकता के बारे में

मुझसे अक्सर सवाल पूछा जाता है:

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

और मैं हमेशा यह नहीं जानता कि इस प्रश्न का तुरंत उत्तर क्या है। मेरे दो विपरीत उत्तर हैं: पहला बहुत है, दूसरा पर्याप्त नहीं है। यह सब इस बात पर निर्भर करता है कि जारी संदेश सूची के विचार पर कैसे विचार किया जाए। अब, क्रोमियम के उदाहरण का उपयोग करके, मैं इस तरह के द्वंद्व के सार को समझाने की कोशिश करूंगा।

PVS-Studio विश्लेषक ने 3582 प्रथम स्तर के अलर्ट (GA सामान्य नियम) उत्पन्न किए। यह बहुत कुछ है। और इनमें से ज्यादातर मैसेज झूठे हैं। यदि आप "हेड-ऑन" जाते हैं और तुरंत पूरी सूची ब्राउज़ करना शुरू करते हैं, तो यह बहुत जल्दी थक जाएगा। और आभास भयानक होगा। उसी प्रकार के कुछ ठोस गलत सकारात्मक। कुछ भी दिलचस्प नहीं है। खराब उपकरण।

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

हालांकि, यह हमेशा काम नहीं करता है। यह क्रोमियम के साथ काम नहीं करता था। उदाहरण के लिए, मैक्रो 'DVLOG' के कारण भारी संख्या में गलत संदेश गए। यह मैक्रो कुछ लॉग कर रहा है। इसे चालाकी से लिखा गया था और पीवीएस-स्टूडियो ने गलती से माना था कि इसमें कोई गलती हो सकती है। चूंकि मैक्रो बहुत सक्रिय रूप से उपयोग किया जाता है, इसलिए बहुत सारे झूठे संदेश निकले। हम कह सकते हैं कि DVLOG मैक्रो का उपयोग कितनी बार किया जाता है, इसलिए रिपोर्ट में कई गलत चेतावनी मिलेंगी। अर्थात्, 2300 के बारे में मैक्रो के बारे में जारी किए गए थेगलत संदेश "V501 समान उप-अभिव्यक्तियाँ हैं ....."।

आप मैक्रो डिक्लेरेशन के आगे हेडर फ़ाइल में लिखकर इन चेतावनियों को दबा सकते हैं, यहाँ इस तरह की टिप्पणी है:

// - V: DVLOG: 501

देखो, इस तरह की एक सरल क्रिया से हम 3582 संदेशों में से 2300 झूठे संदेशों को हटा देंगे। हमने तुरंत 65% संदेशों को समाप्त कर दिया । और अब हमें उन्हें व्यर्थ देखने की आवश्यकता नहीं है।

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

मुझे उम्मीद है कि अब यह स्पष्ट है। पहला उत्तर क्यों - इसमें बहुत सारी झूठी सकारात्मकताएँ हैं। और दूसरा जवाब क्यों - कुछ झूठी सकारात्मकताएं हैं। यह सब इस बात पर निर्भर करता है कि क्या कोई व्यक्ति उत्पाद का अध्ययन करने और अनावश्यक संदेशों से खुद को बचाने के लिए कम से कम समय बिताने के लिए तैयार है।

पाठकों के लिए शब्द जुदा करना

मैं अपने माता-पिता को नमस्ते कहने का अवसर लेता हूं। अरे नहीं, यह कुछ गड़बड़ है। इस अवसर को लेते हुए, मैं प्रोग्रामरों को बधाई देना चाहता हूं और यह याद रखना चाहता हूं:

• प्रश्न का उत्तर "क्या आपने प्रोजेक्ट में पाए जाने वाले किसी भी कीड़े को डेवलपर्स को रिपोर्ट किया है?" ध्यान में रखें " उन प्रश्नों के उत्तर जो अक्सर हमारे लेख पढ़ने के बाद पूछे जाते हैं ।"
• , . twitter, - .
• : @Code_Analysis . ++.