.NET के लिए Amazon Web Services SDK स्रोत कोड में त्रुटियों की खोज करना

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

.NET के लिए Amazon Web Services (AWS) SDK डेवलपर के टूल का एक सेट है, जिसका अर्थ AWS इंफ्रास्ट्रक्चर में .NET पर आधारित एप्लिकेशन बनाने के लिए है। यह सेट कोड लिखने की प्रक्रिया को काफी सरल बनाने में सक्षम बनाता है। SDK में विभिन्न AWS सेवाओं के लिए API .NET जैसे अमेजन S3, Amazon EC2, DynamoDB और अन्य शामिल हैं। SDK स्रोत कोड GitHub पर उपलब्ध है ।

जैसा कि मैंने उल्लेख किया है, उस समय हमने पहले ही C ++ के लिए AWS SDK की जाँच करने के बारे में लेख लिखा है। लेख छोटा हुआ - कोड की 512 हजार पंक्तियों के अनुसार केवल कुछ ही त्रुटियां पाई गईं। इस बार हम कोड के एक बड़े आकार के साथ काम कर रहे हैं, जिसमें लगभग 34 हजार सीएसएस-फाइलें शामिल हैं, और कोड की लाइनों की कुल संख्या (खाली को छोड़कर) प्रभावशाली 5 मिलियन है। कोड का एक छोटा सा हिस्सा (664-सीएस फाइलों में 200 हजार लाइनें) परीक्षणों के लिए अर्जित करता है, मैंने उन्हें नहीं माना है।

यदि एसडीके संस्करण की .NET कोड की गुणवत्ता लगभग C ++ (प्रति 512 केएलओसी में दो त्रुटियां) के समान है, तो हमें लगभग 10 गुना अधिक संख्या में त्रुटियां प्राप्त करनी चाहिए। बेशक, यह एक बहुत ही गलत गणना पद्धति है, जो भाषाई विशिष्टताओं और कई अन्य कारकों को ध्यान में नहीं रखती है, लेकिन मुझे नहीं लगता कि पाठक अब उबाऊ तर्क में जाना चाहते हैं। इसके बजाय, मैं परिणामों पर आगे बढ़ने का सुझाव देता हूं।

पीवीएस-स्टूडियो 6.27 का उपयोग करके चेक का प्रदर्शन किया गया। यह सिर्फ अविश्वसनीय है, लेकिन फिर भी तथ्य यह है कि .NET के लिए AWS SDK में विश्लेषक 40 त्रुटियों का पता लगाने में कामयाब रहा, जिसके बारे में बात करने लायक होगा। यह एसडीके कोड की उच्च गुणवत्ता (512 केएलओसी के बारे में 4 त्रुटियां) को न केवल प्रदर्शित करता है, बल्कि सी # पीवीएस-स्टूडियो विश्लेषक की सी ++ के साथ तुलनात्मक गुणवत्ता भी है। एक महान परिणाम!

.NET के लिए AWS SDK के लेखक, आप असली चम्पी हैं! प्रत्येक परियोजना के साथ, आप कोड की जबरदस्त गुणवत्ता प्रदर्शित करते हैं। यह अन्य टीमों के लिए एक बेहतरीन उदाहरण हो सकता है। हालांकि, निश्चित रूप से, मैं एक स्थिर विश्लेषक का डेवलपर नहीं होगा, अगर मैं अपने 2 सेंट नहीं देता। :) हम पहले से ही पीवीएस-स्टूडियो के उपयोग पर अमेज़ॅन से एक लंबबर्ड टीम के साथ काम कर रहे हैं। चूंकि यह दुनिया भर की इकाइयों के एक समूह के साथ एक बहुत बड़ी कंपनी है, इसलिए यह बहुत संभावना है कि .NET के लिए AWS SDK टीम ने पीवीएस-स्टूडियो के बारे में कभी नहीं सुना है। वैसे भी, मुझे एसडीके कोड में हमारे विश्लेषक का उपयोग करने का कोई संकेत नहीं मिला है, हालांकि यह कुछ भी नहीं कहता है। हालांकि, कम से कम, टीम विज़ुअल स्टूडियो में निर्मित विश्लेषक का उपयोग करती है। यह बहुत अच्छा है, लेकिन कोड समीक्षाओं को हमेशा बढ़ाया जा सकता है :)।

नतीजतन, मैंने एसडीके कोड में कुछ बग ढूंढने का प्रबंधन किया और आखिरकार, उन्हें साझा करने का समय आ गया है।

तर्क में त्रुटि

PVS-Studio चेतावनी: V3008 [CWE-563] 'this.linker.s3.region' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 116, 114. AWSSDK.DynamoDBv2.Net45 S3Link.cs 116

public string Region { get { .... } set { if (String.IsNullOrEmpty(value)) { this.linker.s3.region = "us-east-1"; } this.linker.s3.region = value; } } 

विश्लेषक एक ही चर के लिए बार-बार मूल्य असाइनमेंट के बारे में चेतावनी देता है। कोड से यह स्पष्ट हो जाता है कि यह उस त्रुटि के कारण है जो कार्यक्रम के काम के तर्क का उल्लंघन करता है: चर का मान। इस .linker.s3.region हमेशा स्थिति की परवाह किए बिना चर मान के मूल्य के बराबर होगा। अगर (String.IsNullOrEmpty (मान)) । if block के शरीर में रिटर्न स्टेटमेंट छूट गया था। कोड को इस प्रकार तय करना होगा:

 public string Region { get { .... } set { if (String.IsNullOrEmpty(value)) { this.linker.s3.region = "us-east-1"; return; } this.linker.s3.region = value; } } 

अनंत पुनरावृत्ति

PVS-Studio चेतावनी: V3110 [CWE-674] 'OnFailure' संपत्ति के अंदर संभावित अनंत पुनरावृत्ति। AWSSDK.ElasticMapReduce.Net45 ResizeJobFlowStep.cs 171

 OnFailure? onFailure = null; public OnFailure? OnFailure { get { return this.OnFailure; } // <= set { this.onFailure = value; } } 

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

 public OnFailure? OnFailure { get { return this.onFailure; } set { this.onFailure = value; } } 

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

इस निर्माण के लिए एक और टिप्पणी पहचानकर्ता का उपयोग कर रही है, जो पूरी तरह से ऑनफ़ेलियर प्रकार के नाम से मेल खाती है। संकलक के दृष्टिकोण से, यह काफी स्वीकार्य है, लेकिन यह किसी व्यक्ति के लिए कोड की धारणा को जटिल करता है।

इसी तरह की एक और त्रुटि:

पीवीएस-स्टूडियो चेतावनी: V3110 [CWE-674] 'SSES3' संपत्ति के अंदर संभावित अनंत पुनरावृत्ति। AWSSDK.S3.Net45 InventoryEnc एन्क्रिप्शन.cs 37

 private SSES3 sSES3; public SSES3 SSES3 { get { return this.SSES3; } set { this.SSES3 = value; } } 

स्थिति ऊपर वर्णित के समान है। हालाँकि, यहाँ पढ़ने और असाइनमेंट दोनों के लिए संपत्ति SSES3 को एक्सेस करने पर अनंत पुनरावृत्ति होगी। सही प्रकार:

 public SSES3 SSES3 { get { return this.sSES3; } set { this.sSES3 = value; } } 

विचार पर परीक्षण

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

पीवीएस-स्टूडियो चेतावनी: V3029 एक-दूसरे के साथ स्थित 'अगर' कथन की सशर्त अभिव्यक्तियाँ समान हैं। जाँच लाइनें: 91, 95. AWSSDK.AppSync.Net45 CreateApiKeyResponseUnmarshaller .cs 91

मैंने UnmarshallException के तरीके को कम कर दिया है, जिससे हर उस चीज़ को हटा दिया गया है जिसकी आवश्यकता नहीं है। अब आप देख सकते हैं कि समान चेक एक दूसरे का अनुसरण करते हैं:

 public override AmazonServiceException UnmarshallException(....) { .... if (errorResponse.Code != null && errorResponse.Code.Equals("LimitExceededException")) { return new LimitExceededException(errorResponse.Message, innerException, errorResponse.Type, errorResponse.Code, errorResponse.RequestId, statusCode); } if (errorResponse.Code != null && errorResponse.Code.Equals("LimitExceededException")) { return new LimitExceededException(errorResponse.Message, innerException, errorResponse.Type, errorResponse.Code, errorResponse.RequestId, statusCode); } .... } 

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

कोड में, कई समान त्रुटियां हैं।

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

• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 75, 79. AWSSDK.CloudDirectory.Net45 CreateSchemaResponseUnmarshaller.cs 75
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 105, 109. AWSSDK.CloudDirectory.Net45 GetSchemaAsJsonResponseUnmarshaller.cs 105
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 201, 205. AWSSDK.CodeCommit.Net45 पोस्टकॉममेंटफोरपॉलररैप्लेस्ट्रियासुपरहॉलर।
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 101, 105. AWSSDK.CognitoIdentityProvider.Net45 VerifySoftwareTokenResponseUnmarshaller.cs 101
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। जाँच लाइनें: 72, 76. AWSSDK.Glue.Net45 अपडेटसंपादित करेंनिरीक्षणउपयोगकर्ताउपयोगकर्ता। 72
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइन: 123, 127. AWSSDK.Neptune.Net45 RestoreDBClusterFromSnapshotResponseUnmarshaller.cs 123
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 167, 171. AWSSDK.Neptune.Net45 RestoreDBClusterFromSnapshotResponseUnmarshaller.cs 167
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 127, 131. AWSSDK.RDS.Net45 RestoreDBClusterFromSnapshotResponseUnmarshaller.cs 127
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 171, 175. AWSSDK.RDS.Net45 RestoreDBClusterFromSnapshotResponseUnmarshaller.cs 171
• V3029 एक दूसरे के साथ स्थित 'if' स्टेटमेंट्स की सशर्त अभिव्यक्तियाँ समान हैं। जाँच लाइनें: 99, 103. AWSSDK.Rekognition.Net45 मान्यता

यह क्या है?

पीवीएस-स्टूडियो चेतावनी: V3062 एक ऑब्जेक्ट 'एट्रिब्यूटनाम' का उपयोग अपने तरीके से एक तर्क के रूप में किया जाता है। 'कंटेंस' विधि के पहले वास्तविक तर्क की जाँच करने पर विचार करें। AWSSDK.MobileAnalytics.Net45 CustomEvent.cs 261

 /// <summary> /// Dictionary that stores attribute for this event only. /// </summary> private Dictionary<string,string> _attributes = new Dictionary<string,string>(); /// <summary> /// Gets the attribute. /// </summary> /// <param name="attributeName">Attribute name.</param> /// <returns>The attribute. Return null of attribute doesn't /// exist.</returns> public string GetAttribute(string attributeName) { if(string.IsNullOrEmpty(attributeName)) { throw new ArgumentNullException("attributeName"); } string ret = null; lock(_lock) { if(attributeName.Contains(attributeName)) // <= ret = _attributes[attributeName]; } return ret; } 

विश्लेषक ने GetAttribute विधि में एक त्रुटि का पता लगाया है: एक स्ट्रिंग की जाँच की जाती है कि क्या इसमें स्वयं शामिल है या नहीं। विधि के विवरण से यह इस प्रकार है कि यदि विशेषता नाम (विशेषता नाम) पाया जाता है (शब्दकोश _attributes में ), तो विशेषता मान वापस आ जाना चाहिए, अन्यथा - अशक्त । वास्तव में, जैसा कि स्थिति का गुण है। नाम (कॉन्टेक्ट्स) (विशेषता नाम) हमेशा सत्य होता है, एक कुंजी द्वारा मूल्य को वापस करने का प्रयास किया जाता है जो एक शब्दकोश में नहीं मिल सकता है। फिर, अशक्त लौटने के बजाय , एक अपवाद KeyNotFoundException को फेंक दिया जाएगा।

आइए इस कोड को ठीक करने का प्रयास करें। यह कैसे करना है यह बेहतर तरीके से समझने के लिए, आपको एक अन्य विधि देखनी चाहिए:

 /// <summary> /// Determines whether this instance has attribute the specified /// attributeName. /// </summary> /// <param name="attributeName">Attribute name.</param> /// <returns>Return true if the event has the attribute, else /// false.</returns> public bool HasAttribute(string attributeName) { if(string.IsNullOrEmpty(attributeName)) { throw new ArgumentNullException("attributeName"); } bool ret = false; lock(_lock) { ret = _attributes.ContainsKey(attributeName); } return ret; } 

यह विधि जाँचती है कि क्या विशेषता नाम (विशेषता नाम कुंजी) शब्दकोष में मौजूद है। चलिए फिर से GetAttribute विधि पर वापस आते हैं और त्रुटि को ठीक करते हैं:

 public string GetAttribute(string attributeName) { if(string.IsNullOrEmpty(attributeName)) { throw new ArgumentNullException("attributeName"); } string ret = null; lock(_lock) { if(_attributes.ContainsKey(attributeName)) ret = _attributes[attributeName]; } return ret; } 

अब विधि वही करती है जो विवरण में बताई गई है।

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

संदेहास्पद व्यवहार

पीवीएस-स्टूडियो चेतावनी: V3063 [CWE-571] सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है यदि इसका मूल्यांकन किया जाता है: string.IsNullOrEmpty (inferredIndexName)। AWSSDK.DynamoDBv2.PCL संदर्भ। शाब्दिक 802

 private static string GetQueryIndexName(....) { .... string inferredIndexName = null; if (string.IsNullOrEmpty(specifiedIndexName) && indexNames.Count == 1) { inferredIndexName = indexNames[0]; } else if (indexNames.Contains(specifiedIndexName, StringComparer.Ordinal)) { inferredIndexName = specifiedIndexName; } else if (string.IsNullOrEmpty(inferredIndexName) && // <= indexNames.Count > 0) throw new InvalidOperationException("Local Secondary Index range key conditions are used but no index could be inferred from model. Specified index name = " + specifiedIndexName); .... } 

विश्लेषक चेक स्ट्रिंग के बारे में चिंतित था। SsNullOrEmpty (inferredIndexName) । वास्तव में, स्ट्रिंग inferredIndexName को अशक्त ठहराया जाता है, फिर इस चर का मान कहीं भी नहीं बदला जाता है, फिर किसी कारण से इसे शून्य या रिक्त स्ट्रिंग के लिए जांचा जाता है। संदिग्ध लग रहा है। आइए उपरोक्त कोड के टुकड़े पर करीब से नज़र डालें। मैंने जानबूझकर बेहतर स्थिति को समझने के लिए इसे कम नहीं किया। तो, पहले अगर स्टेटमेंट (और अगले एक में भी) वेरिएबल स्पेसिफाइडनाम किसी तरह चेक किया गया है। चेकों के परिणामों के आधार पर, चर inferredIndexName को एक नया मान मिल रहा है। अब आइए कथन को तीसरे पर देखें। इस कथन के अपवाद (अपवाद को फेंकने) का प्रदर्शन किया जाएगा , अगर indexNames.Count> 0, पूरी स्थिति के पहले भाग के रूप में, जो कि string.IsNullOrEmpty (inferredIndexName) हमेशा सत्य है। शायद, चर निर्दिष्ट किए गए IndexexName और inferredIndexName को मिलाया जाता है या तीसरे चेक के बिना होना चाहिए, यदि कथन में स्वसंपूर्ण का प्रतिनिधित्व हो:

 if (string.IsNullOrEmpty(specifiedIndexName) && indexNames.Count == 1) { inferredIndexName = indexNames[0]; } else if (indexNames.Contains(specifiedIndexName, StringComparer.Ordinal)) { inferredIndexName = specifiedIndexName; } if (string.IsNullOrEmpty(inferredIndexName) && indexNames.Count > 0) throw new InvalidOperationException(....); 

इस मामले में, इस कोड को ठीक करने के लिए विकल्पों पर एक निश्चित उत्तर देना मुश्किल है। वैसे भी, लेखक को इसकी जांच करने की आवश्यकता है।

NullReferenceException

पीवीएस-स्टूडियो चेतावनी: V3095 [CWE-476] नल से सत्यापित होने से पहले ' कंडीशनवैल्यूज ' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 228, 238. AWSSDK.Core.Net45 JsonPolicyWriter.cs 228

 private static void writeConditions(....) { .... foreach (....) { IList<string> conditionValues = keyEntry.Value; if (conditionValues.Count == 0) // <= continue; .... if (conditionValues != null && conditionValues.Count != 0) { .... } .... } } 

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

 private static void writeConditions(....) { .... foreach (....) { IList<string> conditionValues = keyEntry.Value; if (conditionValues != null && conditionValues.Count == 0) continue; .... if (conditionValues != null && conditionValues.Count != 0) { .... } .... } } 

मुझे कोड में कई समान त्रुटियां मिलीं।

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

• V3095 [CWE-476] नल के खिलाफ सत्यापित होने से पहले 'ts.Listeners' ऑब्जेक्ट का उपयोग किया गया था। लाइनों की जाँच करें: 140, 143. AWSSDK.Core.Net45 Logger.Diagnostic.cs 140
• V3095 [CWE-476] नल के खिलाफ सत्यापित होने से पहले 'obj' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 743, 745. AWSSDK.Core.Net45 JsonMapper.cs 743
• V3095 [CWE-476] 'मल्टीपर्टअपलोडमूलिपार्टअप लोडरपार्ट्सलिस्ट' ऑब्जेक्ट का उपयोग इससे पहले किया गया था क्योंकि इसे शून्य के खिलाफ सत्यापित किया गया था। जाँच लाइनें: 65, 67. AWSSDK.S3.Net45 पूर्णमूलिपार्टUploadRequestMarshaller .cs 65

निम्नलिखित चेतावनी अर्थ में बहुत समान है, लेकिन मामला ऊपर चर्चा किए गए के विपरीत है।

PVS-Studio चेतावनी: V3125 [CWE-476] शून्य के खिलाफ सत्यापित होने के बाद 'राज्य' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 139, 127. AWSSDK.Core.Net45 RefreshingAWSCredentials.cs 139

 private void UpdateToGeneratedCredentials( CredentialsRefreshState state) { string errorMessage; if (ShouldUpdate) { .... if (state == null) errorMessage = "Unable to generate temporary credentials"; else .... throw new AmazonClientException(errorMessage); } state.Expiration -= PreemptExpiryTime; // <= .... } 

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

 private void UpdateToGeneratedCredentials( CredentialsRefreshState state) { string errorMessage; if (ShouldUpdate) { .... if (state == null) errorMessage = "Unable to generate temporary credentials"; else .... throw new AmazonClientException(errorMessage); } if (state != null) state.Expiration -= PreemptExpiryTime; .... } 

कोड में, अन्य समान त्रुटियाँ हैं:

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

• V3125 [CWE-476] शून्य से सत्यापित होने के बाद 'लिपटेक्स्पेस्ट.कंटेंट' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 395, 383. AWSSDK.Core.Net45 HttpHandler.cs 395
• V3125 [CWE-476] शून्य के खिलाफ सत्यापित होने के बाद 'डेटासेटअपडेट्स' ऑब्जेक्ट का उपयोग किया गया था। जाँच लाइनें: 477, 437. AWSSDK.CognitoSync.Net45 Dataset.cs 477
• V3125 [CWE-476] 'cORSConfigurationCORSConfigurationcorsRulesListValue' ऑब्जेक्ट का उपयोग तब किया गया था जब इसे null के खिलाफ सत्यापित किया गया था। जाँच लाइनें: 125, 111. AWSSDK.S3.Net45 PutCORSConfigurationRequestMarshaller .cs 125
• V3125 [CWE-476] 'LifeecycleConfigurationLifecycleConfigurationrulesListValue' ऑब्जेक्ट का उपयोग तब किया गया था जब इसे null के खिलाफ सत्यापित किया गया था। चेक लाइन: 157, 68. AWSSDK.S3.Net45 PutLifecycleConfigurationRequestMarshaller.cs 157
• V3125 [CWE-476] नल के खिलाफ सत्यापित होने के बाद 'this.Key' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 199, 183. AWSSDK.S3.Net45 S3PostUploadRequest.cs 199

गैर-वैकल्पिक वास्तविकता

PVS-Studio चेतावनी: V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'समान' का सही मान देती है। AWSSDK.Core.Net45 Lexer.cs 651

 private static bool State19 (....) { while (....) { switch (....) { case '"': .... return true; case '\\': .... return true; default: .... continue; } } return true; } 

विधि हमेशा सही होती है । आइए देखें कि कॉलिंग कोड के लिए यह कितना महत्वपूर्ण है। मैंने State19 विधि का उपयोग करने के मामलों की जाँच की। यह अन्य समान विधियों के साथ समान रूप से हैंडलर fsm_handler_table के सरणी को भरने में शामिल है (क्रमशः नाम के साथ उनमें से 28 हैं, जो राज्य 1 से राज्य 28 से शुरू होते हैं )। यहां यह नोट करना महत्वपूर्ण है कि, स्टेट 19 के अलावा, कुछ अन्य हैंडलर के लिए भी चेतावनी V3009 [CWE-393] जारी की गई थी। ये हैंडलर हैं: State23, State26, State27, State28 । उनके लिए विश्लेषक द्वारा जारी की गई चेतावनी:

• V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। AWSSDK.Core.Net45 Lexer.cs 752
• V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। AWSSDK.Core.Net45 Lexer.cs 810
• V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। AWSSDK.Core.Net45 Lexer.cs 822
• V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। AWSSDK.Core.Net45 Lexer.cs 834

इस तरह से घोषणा और हैंडलर्स की सरणी आरंभीकरण इस तरह दिखता है:

 private static StateHandler[] fsm_handler_table; .... private static void PopulateFsmTables () { fsm_handler_table = new StateHandler[28] { State1, State2, .... State19, .... State23, .... State26, State27, State28 }; 

चित्र को पूरा करने के लिए, आइए उन हैंडलर में से एक का कोड देखें, जिसके लिए विश्लेषक के पास कोई दावा नहीं है, उदाहरण के लिए, State2 :

 private static bool State2 (....) { .... if (....) { return true; } switch (....) { .... default: return false; } } 

यहां बताया गया है कि हैंडलर की कॉल कैसे होती है:

 public bool NextToken () { .... while (true) { handler = fsm_handler_table[state - 1]; if (! handler (fsm_context)) // <= throw new JsonException (input_char); .... } .... } 

जैसा कि हम देख सकते हैं, झूठे लौटने के मामले में एक अपवाद फेंक दिया जाएगा। हमारे मामले में, संचालकों के लिए State19, State23, State26 State27 और State28 ऐसा कभी नहीं होगा। संदिग्ध लग रहा है। दूसरी ओर, पांच हैंडलर समान व्यवहार करते हैं (हमेशा सच लौटाएंगे), इसलिए शायद यह इतना विवादित था और टाइपो का परिणाम नहीं था।

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

अर्थहीन जाँच

पीवीएस-स्टूडियो चेतावनी: V3022 [CWE-571] अभिव्यक्ति 'doLog' हमेशा सच होती है। AWSSDK.Core.Net45 StoredProfileAWSCredentials.cs 235

 private static bool ValidCredentialsExistInSharedFile(....) { .... var doLog = false; try { if (....) { return true; } else { doLog = true; } } catch (InvalidDataException) { doLog = true; } if (doLog) // <= { .... } .... } 

DoLog वैरिएबल पर ध्यान दें । झूठे मूल्य के साथ आरंभ होने के बाद, इस चर को कोड के साथ सभी मामलों में सही मूल्य मिलेगा। इसलिए, जांचें कि क्या (doLog) हमेशा सही होता है। शायद, पहले की विधि में एक शाखा थी, जिसमें doLog वैरिएबल को कोई मान नहीं दिया गया था। जाँच के समय इसमें गलत मूल्य शामिल हो सकता है, जिसे आरंभ करते समय प्राप्त किया जाता है। लेकिन अब ऐसी कोई शाखा नहीं है।

इसी तरह की एक और त्रुटि:

PVS-Studio चेतावनी: V3022 अभिव्यक्ति 'परिणाम' हमेशा गलत होता है। AWSSDK.CognitoSync.PCL SQLiteLocalStorage.cs 353

 public void PutValue(....) { .... bool result = PutValueHelper(....); if (!result) <= { _logger.DebugFormat("{0}", @"Cognito Sync - SQLiteStorage - Put Value Failed"); } else { UpdateLastModifiedTimestamp(....); } .... } 

विश्लेषक दावा करता है कि परिणाम चर का मूल्य हमेशा सही होता है। यह केवल तभी संभव है जब विधि PutValueHelper हमेशा सही लौटेगी। इस विधि पर एक नज़र डालें:

 private bool PutValueHelper(....) { .... if (....)) { return true; } if (record == null) { .... return true; } else { .... return true; } } 

वास्तव में, विधि सभी शर्तों के तहत सही लौटेगी। इसके अलावा, विश्लेषक ने इस पद्धति के लिए एक चेतावनी जारी की है। PVS-Studio चेतावनी: V3009 [CWE-393] यह विचित्र है कि यह विधि हमेशा एक और 'समान' का सही मान देती है। SQLiteLocalStorage.cs 1016

मैंने जानबूझकर पहले इस चेतावनी का हवाला नहीं दिया था जब मैं अन्य कीड़े V3009 में पूछताछ कर रहा था और इस मामले के लिए इसे बचाया। इस प्रकार, कॉलिंग कोड में त्रुटि V3022 को इंगित करने के लिए उपकरण सही था।

कॉपी-पेस्ट। फिर

PVS-Studio चेतावनी: V3001 समान उप-अभिव्यक्तियाँ हैं 'this.token == JsonToken.String' बाईं ओर और 'दाईं ओर' ऑपरेटर। AWSSDK.Core.Net45 JsonReader.cs 343

 public bool Read() { .... if ( (this.token == JsonToken.ObjectEnd || this.token == JsonToken.ArrayEnd || this.token == JsonToken.String || // <= this.token == JsonToken.Boolean || this.token == JsonToken.Double || this.token == JsonToken.Int || this.token == JsonToken.UInt || this.token == JsonToken.Long || this.token == JsonToken.ULong || this.token == JsonToken.Null || this.token == JsonToken.String // <= )) { .... } .... } 

यह फ़ील्ड ..ten की तुलना JsonToken के मान से दो बार की जाती है । गणना JsonToken की स्ट्रिंग । संभवतः, तुलनाओं में से एक में एक और गणना मूल्य होना चाहिए। यदि हां, तो यहां एक गंभीर गलती की गई है।

Refactoring + असावधानी?

पीवीएस-स्टूडियो चेतावनी: V3025 [CWE-685] गलत प्रारूप। 'फ़ॉर्मेट' फ़ंक्शन को कॉल करते समय एक अलग प्रारूप प्रारूप की उम्मीद की जाती है। तर्क का उपयोग नहीं किया गया: AWSConfigs.AWSRegionKey। AWSSDK.Core.Net45 AWSRegion.cs 116

 public InstanceProfileAWSRegion() { .... if (region == null) { throw new InvalidOperationException( string.Format(CultureInfo.InvariantCulture, "EC2 instance metadata was not available or did not contain region information.", AWSConfigs.AWSRegionKey)); } .... } 

शायद, स्ट्रिंग के लिए प्रारूप स्ट्रिंग .ormat विधि में पहले प्रारूप आइटम {0} शामिल था, जिसके लिए तर्क AWSConfigs.AWSRegionKey सेट किया गया था। तब स्ट्रिंग को बदल दिया गया था, प्रारूप आइटम चला गया था, लेकिन एक डेवलपर तर्क को दूर करना भूल गया। दिए गए कोड उदाहरण त्रुटियों के बिना काम करता है (अपवाद को विपरीत स्थिति में फेंक दिया गया था - तर्क के बिना प्रारूप आइटम), लेकिन यह अच्छा नहीं लगता है। कोड निम्नानुसार सही किया जाना चाहिए:

 if (region == null) { throw new InvalidOperationException( "EC2 instance metadata was not available or did not contain region information."); } 

असुरक्षित

PVS-Studio चेतावनी: V3083 [CWE-367] 'mOnSyncSuccess' इवेंट का असुरक्षित आमंत्रण, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.CognitoSync.PCL Dataset.cs 827

 protected void FireSyncSuccessEvent(List<Record> records) { if (mOnSyncSuccess != null) { mOnSyncSuccess(this, new SyncSuccessEventArgs(records)); } } 

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

 protected void FireSyncSuccessEvent(List<Record> records) { mOnSyncSuccess?.Invoke(this, new SyncSuccessEventArgs(records)); } 

कोड में, अन्य समान त्रुटियाँ हैं:

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

• V3083 [CWE-367] 'mOnSyncFailure' इवेंट का असुरक्षित आमंत्रण, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.CognitoSync.PCL Dataset.cs 839
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL AmazonServiceClient.cs 332
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL AmazonServiceClient.cs 344
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL AmazonServiceClient.cs 357
• V3083 [CWE-367] इवेंट 'mExceptionEvent' का असुरक्षित आमंत्रण, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL AmazonServiceClient.cs 366
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL AmazonWebServiceRequest.cs 78
• V3083 [CWE-367] 'OnRead', NullReferenceException घटना के असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.PCL EventStream.cs 97
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.Android NetworkReachability.cs 57
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.Android NetworkReachability.cs 94
• V3083 [CWE-367] घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। AWSSDK.Core.iOS NetworkReachability.cs 54

क्रूड क्लास

PVS-Studio चेतावनी: V3126 टाइप 'JsonData' IEquitable <T> लागू करने वाला इंटरफ़ेस 'GetHashCode' विधि को ओवरराइड नहीं करता है। AWSSDK.Core.Net45 JsonData.cs 26

 public class JsonData : IJsonWrapper, IEquatable<JsonData> { .... } 

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

निष्कर्ष

ये सभी दिलचस्प बग हैं जिन्हें मैं पीवीएस-स्टूडियो स्टेटिक विश्लेषक का उपयोग करके .NET के लिए AWS SDK के कोड में पता लगाने में सक्षम था। मैं एक बार फिर से परियोजना की गुणवत्ता पर प्रकाश डालना चाहूंगा। मुझे कोड की 5 मिलियन लाइनों के लिए बहुत कम त्रुटियां मिलीं। हालाँकि, जारी की गई चेतावनियों का अधिक गहन विश्लेषण मुझे इस सूची में कुछ और त्रुटियां जोड़ने देगा। फिर भी, यह भी काफी संभावना है कि मैंने कुछ चेतावनियों में त्रुटियों के लिए जोड़ा। इस मामले में अस्पष्ट निष्कर्ष हमेशा केवल एक डेवलपर द्वारा किए जाते हैं जो चेक किए गए कोड के संदर्भ में होता है।