अमेज़ॅन लंबरयार्ड: आत्मा का रोना

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

परिचय

अमेज़ॅन लंबरयार्ड अमेज़ॅन द्वारा विकसित और एएए क्रॉस-प्लेटफ़ॉर्म गेम इंजन है, जो क्राय्वेज़िन इंजन वास्तुकला पर आधारित है, जिसे 2015 में क्रायटेक द्वारा लाइसेंस दिया गया था। वैसे, क्राय्वेज़िन का विश्लेषण अगस्त 2016 और अप्रैल 2017 में मेरे द्वारा पहले ही दो बार किया जा चुका है। उसी समय, मुझे यह ध्यान देना होगा कि एक वर्ष के बाद, कोड केवल खराब हो गया। और दूसरे दिन, मैंने यह देखने का फैसला किया कि अमेज़ॅन ने इस गेम इंजन के आधार पर क्या किया। उन्होंने पर्यावरण पर बहुत अच्छा काम किया। एक काम के माहौल को तैनात करने के लिए डेवलपर्स और सॉफ्टवेयर के लिए प्रलेखन बहुत अच्छा और उच्च स्तर पर बनाया गया है। लेकिन परेशानी फिर से कोड के साथ है! मुझे उम्मीद है कि अमेज़ॅन के पास परियोजना के साथ काम करने के लिए बहुत अधिक संसाधन हैं, और वे अभी भी कोड की गुणवत्ता पर ध्यान देते हैं। इस समीक्षा के साथ, मुझे कोड की गुणवत्ता के लिए डेवलपर्स का ध्यान आकर्षित करने और इस गेम इंजन के विकास में एक नए दृष्टिकोण के लिए धक्का देने की उम्मीद है। कोड की वर्तमान स्थिति इतनी खराब स्थिति में थी कि मैंने लेख के शीर्षक को कई बार बदल दिया और शीर्षक चित्र को फिर से तैयार किया जैसा कि मैंने रिपोर्ट के विश्लेषण परिणामों के माध्यम से देखा था। चित्र का पहला संस्करण कम भावनात्मक था:

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

पीवीएस-स्टूडियो के साथ एकीकरण

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

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

विश्लेषण के लिए आदेशों की सूची कुछ इस प्रकार है:

cd /path/to/lumberyard/dev lmbr_waf.bat ... CLMonitor.exe monitor MSBuild.exe ... LumberyardSDK_vs15.sln ... CLMonitor.exe analyze --log /path/to/report.plog 

जैसा कि मैंने कहा था, रिपोर्ट को विजुअल स्टूडियो में देखा जा सकता है।

इगोर और क्वालकॉम के बारे में

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

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। toglsloperand.c 700

यहां एक ही कोड को निष्पादित स्थिति की परवाह किए बिना निष्पादित किया जाता है। टिप्पणियों की पृष्ठभूमि के खिलाफ, ऐसा निर्णय संदेहास्पद लगता है।

सामान्य तौर पर, परियोजना एकमात्र स्थान नहीं है जहां स्पष्टता के लिए शर्तों को सरल बनाने की आवश्यकता होती है, या वास्तविक गलती को सुधारने के लिए। यहां ऐसे स्थानों की सूची दी गई है:

• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। रहन-सहन .Cpp 1385
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। tometalinstruction.c 4201
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। scripttable.cpp 905
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। Budgetingsystem.cpp 701
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। Editorframeworkapplication.cpp 562
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। particleitem.cpp 130
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। trackviewnodes.cpp 1223
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। propertyoarchive.cpp 447

पायथन ++

विश्लेषक को ऐसा एक अजीब कोड मिला:

V709 CWE-682 संदिग्ध तुलना में पाया गया: 'ए == बी == सी'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। toglslinstruction.c 564

 void CallBinaryOp(....) { .... uint32_t src1SwizCount = GetNumSwizzleElements(....); uint32_t src0SwizCount = GetNumSwizzleElements(....); uint32_t dstSwizCount = GetNumSwizzleElements(....); .... if (src1SwizCount == src0SwizCount == dstSwizCount) // <= { .... } .... } 

सी ++ में, ऐसा कोड, दुर्भाग्य से, सफलतापूर्वक संकलित करता है, लेकिन यह बिल्कुल भी निष्पादित नहीं करता है क्योंकि यह लग सकता है। C ++ में अभिव्यक्तियों का मूल्यांकन प्राथमिकता के क्रम में किया जाता है, यदि आवश्यक हो, तो निहित जातियों को निष्पादित करना।

इस तरह की जाँच सही होगी, उदाहरण के लिए, पायथन भाषा में। लेकिन इस स्थिति में, डेवलपर ने "खुद को पैर में गोली मार ली।"

3 अधिक नियंत्रण शॉट्स:

• V709 CWE-682 संदिग्ध तुलना में पाया गया: 'ए == बी == सी'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। toglslinstruction.c 654
• V709 CWE-682 संदिग्ध तुलना में पाया गया: 'ए == बी == सी'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। toglslinstruction.c 469
• V709 CWE-682 संदिग्ध तुलना में पाया गया: 'ए == बी == सी'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। .metalstruction अवरोध 539

सबसे अच्छा निदान का पहला और एक

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

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

V501 बाईं और 'के दाईं ओर समान उप-अभिव्यक्तियाँ हैं' || ऑपरेटर: हॉटएक्स <0 || hotX <0 editorutils.cpp 166

 QCursor CMFCUtils::LoadCursor(....) { .... if (!pm.isNull() && (hotX < 0 || hotX < 0)) { QFile f(path); f.open(QFile::ReadOnly); QDataStream stream(&f); stream.setByteOrder(QDataStream::LittleEndian); f.read(10); quint16 x; stream >> x; hotX = x; stream >> x; hotY = x; } .... } 

स्थिति में परिवर्तनशील गर्म Y का अभाव है । क्लासिक टाइपो।

V501 समान उप-अभिव्यक्तियाँ हैं 'sp.m_pTexture == m_pTexture' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। shadercompords.h 487

V501 समान उप-अभिव्यक्तियाँ 'sp.m_eCGTextureType == m_eCGTextureType' बाईं ओर और '&&' ऑपरेटर के दाईं ओर हैं। shadercompords.h 487

 bool operator != (const SCGTexture& sp) const { if (sp.m_RegisterOffset == m_RegisterOffset && sp.m_Name == m_Name && sp.m_pTexture == m_pTexture && // <= 1 sp.m_RegisterCount == m_RegisterCount && sp.m_eCGTextureType == m_eCGTextureType && // <= 2 sp.m_BindingSlot == m_BindingSlot && sp.m_Flags == m_Flags && sp.m_pAnimInfo == m_pAnimInfo && sp.m_pTexture == m_pTexture && // <= 1 sp.m_eCGTextureType == m_eCGTextureType && // <= 2 sp.m_bSRGBLookup == m_bSRGBLookup && sp.m_bGlobal == m_bGlobal) { return false; } return true; } 

इस खंड में एक बार में दो कॉपी-पेस्ट पाए गए थे। स्पष्टता के लिए, मैंने तीर चित्रित किया।

V501 बाईं और '==' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: pSrc.GetLen () == pSrc.GetLen () fbxpropertytypes.n978

 inline bool FbxTypeCopy(FbxBlob& pDst, const FbxString& pSrc) { bool lCastable = pSrc.GetLen() == pSrc.GetLen(); FBX_ASSERT( lCastable ); if( lCastable ) pDst.Assign(pSrc.Buffer(), (int)pSrc.GetLen()); return lCastable; } 

यहां मैं AUTODESK के डेवलपर्स को हैलो कहना चाहता हूं। यह त्रुटि उनके FBX SDK लाइब्रेरी से है। भ्रमित चर pSrc और pDst । मुझे लगता है, लंबरयार्ड के अलावा, कई अन्य उपयोगकर्ता भी हैं जिनकी परियोजनाएं इस त्रुटि के साथ कोड पर निर्भर करती हैं।

V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: pTS-> pRT_ALD_1 && pTS-> pRT_ALD_1 d3d_svo.cn 857

 void CSvoRenderer::ConeTracePass(SSvoTargetsSet* pTS) { .... if (pTS->pRT_ALD_1 && pTS->pRT_ALD_1) { static int nPrevWidth = 0; if (....) { .... } else { pTS->pRT_ALD_1->Apply(10, m_nTexStateLinear); pTS->pRT_RGB_1->Apply(11, m_nTexStateLinear); } } .... } 

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

और अगर यह उदाहरण पर्याप्त नहीं है, तो 5 और समान हैं।

• V501 बाईं और 'के दाईं ओर समान उप-अभिव्यक्तियाँ हैं' || ऑपरेटर:! pTS-> pRT_ALD_0 ||! pTS-> pRT_ALD_0 d3d_svo.cpp 1041
• V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: m_pRT_AIR_MIN && m_pRT_AIR_MIN d3d_svo.cn 1808
• V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: m_pRT_AIR_MAX && m_pRT_AIR_MAX d3d_svo.cn 1819
• V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: m_pRT_AIR_SHAD && m_pRT_AIR_SHAD d3d_svo.cn 1830
• V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: s_pPropertiesPanel && s_pPropertiesPanel unitobject.cpp 1700

और जैसा कि मैंने वादा किया था, यहां कोड के उदाहरणों के बिना शेष V501 चेतावनियों की एक सूची दी गई है:

खेलों में कैमरे की स्थिति के बारे में

PVS-Studio - V502 में दूसरा सबसे तेज़ निदान है। यह निदान कुछ नई प्रोग्रामिंग भाषाओं की तुलना में पुराना है, जिसमें ऐसी त्रुटि की अनुमति नहीं दी जा सकती है। और C ++ के लिए, यह त्रुटि प्रासंगिक होगी, शायद हमेशा।

एक छोटे से सरल उदाहरण से शुरू करते हैं।

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '+' ऑपरेटर की तुलना में कम प्राथमिकता है। zipencryptor.cpp 217

 bool ZipEncryptor::ParseKey(....) { .... size_t pos = i * 2 + (v1 == 0xff) ? 1 : 2; RCLogError("....", pos); return false; .... } 

अतिरिक्त संचालन में टर्नरी ऑपरेटर की तुलना में अधिक प्राथमिकता है। इसलिए, इस अभिव्यक्ति में लेखक की तुलना में पूरी तरह से अलग गणना तर्क है।

आप इस तरह से त्रुटि को ठीक कर सकते हैं:

 size_t pos = i * 2 + (v1 == 0xff ? 1 : 2); 

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '-' ऑपरेटर की तुलना में कम प्राथमिकता है। 3dengine.cpp 1898

 float C3DEngine::GetDistanceToSectorWithWater() { .... return (bCameraInTerrainBounds && (m_pTerrain && m_pTerrain->GetDistanceToSectorWithWater() > 0.1f)) ? m_pTerrain->GetDistanceToSectorWithWater() : max(camPostion.z - OceanToggle::IsActive() ? OceanRequest::GetOceanLevel() : GetWaterLevel(), 0.1f); } 

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

इस विकल्प में एक त्रुटि मौजूद है:

 camPostion.z - OceanToggle::IsActive() ? .... : .... 

यदि आपके गेम में कैमरा अचानक अनुचित व्यवहार करने लगा, तो आपको पता होना चाहिए कि डेवलपर्स ने स्थिर कोड विश्लेषण पर बचा लिया: डी।

इसी तरह की चेतावनियों के साथ अन्य उदाहरण:

• V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '-' ऑपरेटर की तुलना में कम प्राथमिकता है। scriptbind_ai.cpp 5203
• V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '+' ऑपरेटर की तुलना में कम प्राथमिकता है। qcolumnwidget.cpp 136
• V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की 'और&' ऑपरेटर की तुलना में कम प्राथमिकता है। shapetool.h 98

क्राइंगजेन लिगेसी

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

इस खंड में, मैं आपको कुछ त्रुटियां बताऊंगा जो कि क्रैन्वाइन के नवीनतम संस्करण में तय की गई थीं, और अब केवल लंबरार्ड प्रोजेक्ट की समस्या बनी हुई है।

V519 'BlendFactor [2]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 1283, 1284। ccrydxgldevicecontext.cpp 1284

लंबरार्ड डेवलपर्स द्वारा लगभग ऐसी भावनाओं का अनुभव किया जाएगा जब उन्हें पता चलेगा कि यह त्रुटि केवल उनके साथ बनी हुई है।

वैसे, दो और हैं:

• V519 'm_auBlendFactor [2]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 919, 920. ccrydxgldevicecontext.cpp 920
• V519 'm_auBlendFactor [2]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 926, 927. ccrydxgldevicecontext.cpp 927

ऐसी त्रुटि है:

V546 एक वर्ग का सदस्य अपने आप में आरंभिक होता है: 'eConfigMax (eConfigMax.VeryHigh)'। कणपरम.ह 1837

 ParticleParams() : .... fSphericalApproximation(1.f), fVolumeThickness(1.0f), fSoundFXParam(1.f), eConfigMax(eConfigMax.VeryHigh), // <= fFadeAtViewCosAngle(0.f) {} 

क्रायजेन में इस वर्ग को आम तौर पर फिर से लिखा गया था, लेकिन यहां आरंभीकरण त्रुटि बनी रही।

V521 ',' ऑपरेटर का उपयोग करने वाले ऐसे भाव खतरनाक हैं। सुनिश्चित करें कि अभिव्यक्ति '! SWords [iWord] .empty (), iWord ++' सही है। टैक्टिकलकपॉइंट्स.कंप 3376

 bool CTacticalPointSystem::Parse(....) const { string sInput(sSpec); const int MAXWORDS = 8; string sWords[MAXWORDS]; int iC = 0, iWord = 0; for (; iWord < MAXWORDS; !sWords[iWord].empty(), iWord++) { sWords[iWord] = sInput.Tokenize("_", iC); } .... } 

क्रायजाइन ने जिस संदिग्ध चक्र को फिर से लिखा है, वह पहले से ही है।

गलतियाँ आपके विचार से अधिक समय तक जीवित रहती हैं

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

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

V557 CWE-119 ऐरे ओवररन संभव है। 'Id' इंडेक्स सरणी बाउंड से परे इंगित कर रहा है। gameobjectsystem.cpp 113

 uint32 CGameObjectSystem::GetExtensionSerializationPriority(....) { if (id > m_extensionInfo.size()) { return 0xffffffff; // minimum possible priority } else { return m_extensionInfo[id].serializationPriority; } } 

जैसा कि आप जानते हैं, अमेज़न लम्बरबार्ड क्राईन्ग्वीन के नवीनतम संस्करण पर आधारित नहीं है। फिर भी, पीवीएस-स्टूडियो विश्लेषक की मदद से, एक त्रुटि ढूंढना संभव था जो अब दो गेम इंजन में मौजूद है। यह आवश्यक था कि ऑपरेटर '> =' का उपयोग करके सूचकांक की जाँच करें ...

अनुक्रमणिका त्रुटि गंभीर है। इसके अलावा, वहाँ छह ऐसी जगहें हैं ! यहाँ एक और उदाहरण है:

V557 CWE-119 ऐरे ओवररन संभव है। 'इंडेक्स' इंडेक्स सरणी बाउंड से परे इंगित कर रहा है। वाहनों की श्रेणी। 73 एपीपी

 CVehicleSeat* CVehicleSeatGroup::GetSeatByIndex(unsigned index) { if (index >= 0 && index <= m_seats.size()) { return m_seats[index]; } return NULL; } 

किसी ने एक ही प्रकार की गलतियाँ कीं, और वे सिर्फ इसलिए तय नहीं किए गए थे क्योंकि उन्हें एक बार क्राइंगजाइन बग समीक्षाओं में शामिल नहीं किया गया था।

शेष चेतावनी:

• V557 CWE-119 ऐरे ओवररन संभव है। 'Id' इंडेक्स सरणी बाउंड से परे इंगित कर रहा है। gameobjectsystem.cpp 195
• V557 CWE-119 ऐरे ओवररन संभव है। 'Id' इंडेक्स सरणी बाउंड से परे इंगित कर रहा है। gameobjectsystem.cpp 290
• V557 CWE-119 ऐरे ओवररन संभव है। 'स्टेटआईड' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। वाहनों की मरम्मत
• V557 CWE-119 ऐरे ओवररन संभव है। 'स्टेटआईड' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। व्हीकलिसिमिनेशन। सीपीसी 354

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

कॉपी-पेस्ट प्रोग्रामिंग के विभिन्न शेड्स

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

ओवरलैपिंग स्कोप में समान नाम के साथ चर घोषित करते समय यहां संदिग्ध कोड का एक उदाहरण है।

V561 CWE-563 'नए' घोषित करने की तुलना में 'pLibrary' वेरिएबल को मान देना बेहतर है। पिछली घोषणा: Unitobject.cpp, पंक्ति 4703. unitobject.cpp 4706

 void CEntityObject::OnMenuConvertToPrefab() { .... IDataBaseLibrary* pLibrary = GetIEditor()->Get....; if (pLibrary == NULL) { IDataBaseLibrary* pLibrary = GetIEditor()->Get....; } if (pLibrary == NULL) { QString sError = tr(....); CryMessageBox(....); return; } .... } 

PLibrary सूचक अपेक्षित रूप से ओवरराइट नहीं करता है। इस सूचक के आरंभीकरण को पूरी तरह से इस प्रकार की घोषणा के साथ शर्त के तहत कॉपी किया गया था।

मैं सभी समान स्थानों की सूची दूंगा:

• V561 CWE-563 'ई-टाइप' वैरिएबल को वैल्यू असाइन करना बेहतर है, इसे नए सिरे से घोषित करें। पिछली घोषणा: toglsloperand.c, लाइन 838. toglsloperand.c 1224
• V561 CWE-563 'ई-टाइप' वैरिएबल को वैल्यू असाइन करना बेहतर है, इसे नए सिरे से घोषित करें। पिछली घोषणा: toglsloperand.c, लाइन 838. toglsloperand.c 1305
• V561 CWE-563 better rSkelPose ’वैरिएबल को मान देने के लिए इसे नए सिरे से घोषित करना शायद बेहतर है। पिछली घोषणा: संलग्नक ।.cpp, लाइन 409। संलग्नक
• V561 CWE-563 यह 'nThreadID' वैरिएबल के मान को असाइन करने के लिए संभवतः नए सिरे से घोषित करना बेहतर है। पिछली घोषणा: d3dmeshbaker.cpp, लाइन 797. d3dmeshbaker.cpp 867
• V561 CWE-563 ame डाइरेक्टरीनामलिस्ट ’वैरिएबल की वैल्यू असाइन करना बेहतर है, इसे नए सिरे से घोषित करें। पिछली घोषणा: एसेट्समिशनमैनगर.कैप, लाइन asset२०
• V561 CWE-563 better pNode ’वैरिएबल की वैल्यू असाइन करना बेहतर है, इसे नए सिरे से घोषित करें। पिछली घोषणा: ब्रेकप्वाइंट्सक्लो..सी.पी., लाइन 340। ब्रेकपॉइंट्सरेक्लो.कैप 349
• V561 CWE-563 'नए' घोषित करने की तुलना में 'pLibrary' वेरिएबल को मान देना बेहतर है। पिछली घोषणा: prefabobject.cpp, लाइन 1443। prefabobject.cpp 1446
• V561 CWE-563 'नए' घोषित करने की तुलना में 'pLibrary' वेरिएबल को मान देना बेहतर है। पिछली घोषणा: प्रीफ़बोबजेक्ट.कप, लाइन १४f०
• V561 CWE-563 L cmdLine ’वैरिएबल को वैल्यू असाइन करने से बेहतर है कि इसे नए सिरे से घोषित किया जाए। पिछली घोषणा: fileutil.cpp, लाइन 110. fileutil.cpp 130
• V561 CWE-563 better sfunctionArgs ’वैरिएबल को मान देने के लिए इसे नए सिरे से घोषित करना बेहतर है। पिछली घोषणा: एफिशिएटेमोग्लिक्लबैकबैक। लाइन 291।
• V561 CWE-563 better कर्वनाम ’वैरिएबल को वैल्यू असाइन करना बेहतर है, इसे नए सिरे से घोषित करें। पिछला घोषणापत्र: qgradientselectorwidget.cpp, पंक्ति 475. qgradientselectorwidget.cpp 488

एक लंबी सूची ... सूचीबद्ध स्थानों में से कुछ भी वर्णित उदाहरण की पूरी प्रतियां हैं।

Eigenvalue आरंभीकरण

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

V570 'व्यवहारप्रेम.इग्नोरऑनवैलिक डस्ट्रोयर्ड ' वेरिएबल को ही सौंपा गया है। vehiclecomponent.cpp 168

 bool CVehicleComponent::Init(....) { .... if (!damageBehaviorTable.getAttr(....) { behaviorParams.ignoreOnVehicleDestroyed = false; } else { behaviorParams.ignoreOnVehicleDestroyed = // <= behaviorParams.ignoreOnVehicleDestroyed; // <= } .... } 

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

 bValue = !bValue 

लेकिन डेवलपर्स इस निदान के परिणामों से बेहतर परिचित हैं।

समस्या से निपटने

त्रुटि से निपटने के दौरान कुछ गलत होने पर यह खंड कई उदाहरण देगा।

उदाहरण 1

V606 मालिक रहित टोकन 'nullptr'। dx12rootsignature.cpp 599

 RootSignature* RootSignatureCache::AcquireRootSignature(....) { .... RootSignature* result = new RootSignature(m_pDevice); if (!result->Init(params)) { DX12_ERROR("Could not create root signature!"); nullptr; } m_RootSignatureMap[hash] = result; return result; } } 

वापसी nullptr लिखना भूल गया ; । अब, परिणाम चर का अमान्य मान कोड में कहीं और उपयोग किया जाएगा।

ठीक उसी कोड को एक और स्थान पर कॉपी किया गया था:

• V606 मालिक रहित टोकन 'nullptr'। dx12rootsignature.cpp 621

उदाहरण 2

V606 मालिकहीन टोकन 'गलत'। fillspacetool.cpp 191

 bool FillSpaceTool::FillHoleBasedOnSelectedElements() { .... if (validEdgeList.size() == 2) { .... } if (validEdgeList.empty()) { .... for (int i = 0, iVertexSize(....); i < iVertexSize; ++i) { validEdgeList.push_back(....); } } if (validEdgeList.empty()) // <= { false; // <= fail } std::vector<BrushEdge3D> linkedEdgeList; std::set<int> usedEdgeSet; linkedEdgeList.push_back(validEdgeList[0]); // <= fail .... } 

एक लापता रिटर्न स्टेटमेंट के साथ त्रुटि का एक बहुत ही दिलचस्प उदाहरण। अब एक खाली कंटेनर को इंडेक्स तक पहुंचाने की स्थिति संभव है।

उदाहरण 3

V564 CWE-480 द 'एंड' ऑपरेटर बूल टाइप वैल्यू पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। toglslinstruction.c 2914

 void SetDataTypes(....) { .... // Check assumption that both the values which MOVC might pick // have the same basic data type. if(!psContext->flags & HLSLCC_FLAG_AVOID_TEMP_REGISTER_ALIASING) { ASSERT(GetOperandDataType(psContext, &psInst->asOperands[2]) == GetOperandDataType(psContext, &psInst->asOperands[3])); } .... } 

ध्वज में बिट्स की उपस्थिति के लिए गलत तरीके से जाँच की गई। निगेटिव ऑपरेटर ध्वज मूल्य पर लागू होता है, संपूर्ण अभिव्यक्ति पर नहीं। इस तरह से सही लिखें:

 if(!(psContext->flags & ....)) 

इसी तरह की चेतावनी:

• V564 CWE-480 द '|' ऑपरेटर को बूल प्रकार के मूल्य पर लागू किया जाता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या 'का उपयोग करने का इरादा है' || ऑपरेटर। d3dhwshader.cpp 1832
• V564 CWE-480 द 'एंड' ऑपरेटर बूल टाइप वैल्यू पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। trackviewdialog.cpp 2112
• V564 CWE-480 द '|' ऑपरेटर को बूल प्रकार के मूल्य पर लागू किया जाता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या 'का उपयोग करने का इरादा है' || ऑपरेटर। imagecompiler.cpp 1039

उदाहरण 4

V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1491

 static std::vector<std::string> PyGetPrefabLibrarys() { CPrefabManager* pPrefabManager = GetIEditor()->GetPrefabMa....; if (!pPrefabManager) { std::runtime_error("Invalid Prefab Manager."); } .... } 

अपवाद फेंकने में त्रुटि। इस तरह लिखना आवश्यक था:

 throw std::runtime_error("Invalid Prefab Manager."); 

ऐसी त्रुटियों की पूरी सूची:

• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1515
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1521
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1543
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1549
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1603
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1619
• V596 CWE-390 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; prefabobject.cpp 1644

स्मृति के साथ काम करते समय कुछ समस्याएं

V549 CWE-688 'मेमकैंप' फ़ंक्शन का पहला तर्क दूसरे तर्क के बराबर है। meshutils.h 894

 struct VertexLess { .... bool operator()(int a, int b) const { .... if (m.m_links[a].links.size() != m.m_links[b].links.size()) { res = (m.m_links[a].links.size() < m.m_links[b].links.size()) ? -1 : +1; } else { res = memcmp(&m.m_links[a].links[0], &m.m_links[a].links[0], sizeof(m.m_links[a].links[0]) * m.m_links[a].links.size()); } .... } .... }; 

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

V611 CWE-762 स्मृति को 'नए टी []' ऑपरेटर के उपयोग से आवंटित किया गया था, लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। शायद 'डिलीट [] डेटा;' का उपयोग करना बेहतर है। vectorn.h 102

 ~vectorn_tpl() { if (!(flags & mtx_foreign_data)) { delete[] data; } } vectorn_tpl& operator=(const vectorn_tpl<ftype>& src) { if (src.len != len && !(flags & mtx_foreign_data)) { delete data; // <= data = new ftype[src.len]; } .... } 

डेटा पॉइंटर मेमोरी को अमान्य स्टेटमेंट के साथ मुक्त किया जा रहा है । डिलीट [] ऑपरेटर को हर जगह इस्तेमाल किया जाना चाहिए ।

अगम्य कोड

V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। fbxskinimporter.cpp 67

 Events::ProcessingResult FbxSkinImporter::ImportSkin(....) { .... if (BuildSceneMeshFromFbxMesh(....) { context.m_createdData.push_back(std::move(createdData)); return Events::ProcessingResult::Success; // <= } else { return Events::ProcessingResult::Failure; // <= } context.m_createdData.push_back(); // <= fail return Events::ProcessingResult::Success; } 

सशर्त विवरण की सभी शाखाएं फ़ंक्शन से बाहर निकलने के साथ समाप्त होती हैं। हालाँकि, कुछ कोड निष्पादित नहीं किया गया है।

V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। dockablelibrarytreeview.cpp 153

 bool DockableLibraryTreeView::Init(IDataBaseLibrary* lib) { .... if (m_treeView && m_titleBar && m_defaultView) { if (m_treeView->topLevelItemCount() > 0) { ShowTreeView(); } else { ShowDefaultView(); } return true; // <= } else { return false; // <= } emit SignalFocused(this); // <= fail } 

कोड के इस टुकड़े पर त्रुटि दर्ज करना आसान है लेकिन अगर आप लंबे समय तक कोड लिखते हैं, तो ध्यान तेजी से गिरता है और ऐसी त्रुटियां आसानी से परियोजना में आती हैं।

V622 CWE-478 'स्विच' स्टेटमेंट का निरीक्षण करने पर विचार करें। यह संभव है कि पहला 'केस' ऑपरेटर गायब हो। डेटम.कंप 72२

 AZ_INLINE bool IsDataGreaterEqual(....) { switch (type.GetType()) { AZ_Error("ScriptCanvas", false, "...."); return false; case Data::eType::Number: return IsDataGreaterEqual<Data::NumberType>(lhs, rhs); .... case Data::eType::AABB: AZ_Error("ScriptCanvas", false, "....", Data::Traits<Data::AABBType>::GetName()); return false; case Data::eType::OBB: AZ_Error("ScriptCanvas", false, "....", Data::Traits<Data::OBBType>::GetName()); return false; .... } 

यदि स्विच में केस / डिफॉल्ट स्टेटमेंट के बाहर कोड होता है , तो इसे कभी भी निष्पादित नहीं किया जाता है।

निष्कर्ष

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

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

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

एक सहकर्मी ने हाल ही में गेमिंग सॉफ़्टवेयर गुणवत्ता के विषय पर एक लेख लिखा था, मेरा सुझाव है कि आपको पढ़ने में रुचि हो: " वीडियो गेम उद्योग में स्थैतिक विश्लेषण: शीर्ष 10 सॉफ़्टवेयर त्रुटियां ।" पीवीएस-स्टूडियो

विश्लेषक डाउनलोड करने के लिए लिंक , आप इसके बिना कैसे कर सकते हैं ;-)

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: Svyatoslav Razmyslov। अमेज़ॅन लंबरयार्ड: ए स्क्रीम ऑफ़ एंगुइश