.NET स्रोत कोड के लिए अमेज़ॅन वेब सेवा एसडीके में बग की तलाश है

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

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

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

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

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

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

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

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

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; } } 

विश्लेषक उसी चर के मान को फिर से असाइन करने की चेतावनी देता है। कोड से, यह स्पष्ट हो जाता है कि यह एक त्रुटि के कारण होता है जो ऑपरेशन के तर्क का उल्लंघन करता है: this.linker.s3.region वैरिएबल का मान हमेशा मान के बराबर होगा , चाहे कोई भी स्थिति हो (String.IsNullnrEmpty (मान)) । अगर ब्लॉक के शरीर में, वापस छोड़ दिया गया था। कोड को इस प्रकार तय करना होगा:

 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; } } 

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

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

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

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

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

PVS-Studio चेतावनी: 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; } } 

माइंडफुलनेस टेस्ट

निम्नलिखित एक प्रोग्रामर का एक कार्य है जो कॉपी-पेस्ट तकनीक का उपयोग करने का इच्छुक है। दृश्य स्टूडियो संपादक में कोड कैसा दिखता है और त्रुटि को खोजने का प्रयास करें।

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

मैंने सभी अनावश्यक को हटाते हुए, अनमरशाल एक्ससेप्शन विधि के शरीर को कम कर दिया। अब आप देख सकते हैं कि समान चेक एक के बाद एक का पालन करते हैं:

 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 पोस्टकमेन्टफॉरपॉलरैलसेंप्रेस्सेंटस यूएनआर्सहेलर .cs 201
• 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 मान्यता

तुम क्या हो

PVS-Studio चेतावनी: 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 शब्दकोश में), तो विशेषता मान वापस आ जाना चाहिए, अन्यथा शून्य । हकीकत में, जब से हालत का नाम Name.Contains (FeatureName) हमेशा सत्य होता है, एक कुंजी द्वारा एक मान को वापस करने का प्रयास किया जाता है जो कि शब्दकोश में नहीं पाया जा सकता है। फिर, अशक्त लौटने के बजाय , एक 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; } 

यह विधि जाँचता है कि क्या विशेषता नाम (विशेषता नाम) _attributes शब्दकोश में मौजूद है। आइए 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); .... } 

विश्लेषक ने स्ट्रिंग को सतर्क किया। INNOOEEpty (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

PVS-Studio चेतावनी: 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 ऐसा कभी नहीं होगा। यह संदिग्ध लग रहा है। दूसरी ओर, पांच हैंडलर के साथ समान व्यवहार (हमेशा सही वापसी) होता है, इसलिए शायद यह इरादा था और यह टाइपो का परिणाम नहीं है।

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

अर्थहीन जाँच

PVS-Studio चेतावनी: 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 // <= )) { .... } .... } 

JsonToken.String मान के JsonToken गणना के साथ इस .oken फ़ील्ड की डबल तुलना करें। संभवतः तुलनाओं में से एक में एक अलग गणना मूल्य होना चाहिए। यदि ऐसा है, तो एक गंभीर गलती की गई है।

लापरवाही + लापरवाही?

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

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

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

निष्कर्ष

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई ख्रेनोव। .NET के लिए Amazon Web Services SDK स्रोत कोड में त्रुटियों की खोज करना