पीवीएस-स्टूडियो रेड डेड रिडेम्पशन के बुलेट इंजन में देखा गया

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

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

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

वार्म अप करें

उदाहरण 1:

आइए एक गलती से शुरू करें:

V624 '3.141592538' स्थिरांक में एक गलत धारणा है। <Math.h> से M_PI स्थिरांक का उपयोग करने पर विचार करें। PhysicsClientC_API.cpp 4109

B3_SHARED_API void b3ComputeProjectionMatrixFOV(float fov, ....) { float yScale = 1.0 / tan((3.141592538 / 180.0) * fov / 2); .... } 

पाई मूल्य में एक छोटा टाइपो (3.141592653 ...)। भिन्नात्मक भाग में 7 वां अंक गायब है - यह 6 के बराबर होना चाहिए।
शायद, दशमलव बिंदु के बाद दस लाखवें अंश में एक त्रुटि किसी भी महत्वपूर्ण परिणाम को जन्म नहीं देगी, लेकिन फिर भी आपको पहले से मौजूद पुस्तकालय स्थिरांक का उपयोग करना चाहिए, जिसमें कोई टाइपो नहीं है। Math.h शीर्ष लेख से Pi नंबर के लिए M_PI स्थिरांक है।

कॉपी पेस्ट करें

उदाहरण 2:

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

V751 पैरामीटर 'halfExtentsZ' का उपयोग फ़ंक्शन बॉडी के अंदर नहीं किया जाता है। TinyRenderer.cpp 375

 void TinyRenderObjectData::createCube(float halfExtentsX, float halfExtentsY, float halfExtentsZ, ....) { .... m_model->addVertex(halfExtentsX * cube_vertices_textured[i * 9], halfExtentsY * cube_vertices_textured[i * 9 + 1], halfExtentsY * cube_vertices_textured[i * 9 + 2], cube_vertices_textured[i * 9 + 4], ....); .... } 

उदाहरण 3:

विश्लेषक ने निम्नलिखित दिलचस्प टुकड़े का भी पता लगाया है और मैं इसे शुरुआती रूप में दिखाऊंगा।


इस looooooooooong लाइन देखें?


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

विश्लेषक ने इस पंक्ति पर निम्नलिखित चेतावनी दी।

V501 समान उप-अभिव्यक्तियाँ हैं 'रोटैट.कॉल्यूमेंट 1 ()। नॉर्म () <1.0001' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। LinearR4.cpp 351

V501 समान उप-अभिव्यक्तियाँ हैं '0.9999 <rotmat.Column1 ()। Norm ()' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। LinearR4.cpp 351

यदि हम इसे एक स्पष्ट "सारणीबद्ध" रूप में लिखते हैं, तो हम देख सकते हैं कि सभी समान चेक कॉलम 1 पर लागू होते हैं। अंतिम दो तुलनाएं बताती हैं कि Column1 और Column2 हैं । सबसे अधिक संभावना है, तीसरी और चौथी तुलना में कॉलम 2 के मूल्य की जांच होनी चाहिए।

  Column1().Norm() < 1.0001 && 0.9999 < Column1().Norm() && Column1().Norm() < 1.0001 && 0.9999 < Column1().Norm() &&(Column1() ^ Column2()) < 0.001 && (Column1() ^ Column2()) > -0.001 

इस रूप में, समान तुलनाएं अधिक ध्यान देने योग्य हो जाती हैं।

उदाहरण 4:

उसी तरह की त्रुटि:

V501 समान उप-अभिव्यक्तियाँ हैं 'cs.m_fJacCoeffInv [0] == 0' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। b3CpuRigidBodyPipeline.cpp 169

 float m_fJacCoeffInv[2]; static inline void b3SolveFriction(b3ContactConstraint4& cs, ....) { if (cs.m_fJacCoeffInv[0] == 0 && cs.m_fJacCoeffInv[0] == 0) { return; } .... } 

इस मामले में, एक और एक ही सरणी तत्व को दो बार जांचा जाता है। सबसे अधिक संभावना है, हालत इस तरह दिखना चाहिए: cs.m_fJacCoeffInv [0] == 0 && cs.m_fJacCoeffInv [1] == 0 । यह कॉपी-पेस्ट त्रुटि का एक उत्कृष्ट उदाहरण है।

उदाहरण 5:

यह भी पता चला कि इस तरह का दोष था:

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। जाँच लाइनें: 79, 112. main.cpp 79

 int main(int argc, char* argv[]) { .... while (serviceResult > 0) { serviceResult = enet_host_service(client, &event, 0); if (serviceResult > 0) { .... } else if (serviceResult > 0) { puts("Error with servicing the client"); exit(EXIT_FAILURE); } .... } .... } 

फ़ंक्शन enet_host_service , जिसका परिणाम serviceResult को सौंपा गया है, सफल समापन के मामले में 1 और विफलता के मामले में -1 देता है। सबसे अधिक संभावना है, अगर शाखा को सेवा के नकारात्मक मूल्य पर प्रतिक्रिया देनी चाहिए। संभवतः यह एक कॉपी-पेस्ट त्रुटि भी है।

विश्लेषक की एक समान चेतावनी है, लेकिन इस लेख में इसे और करीब से देखने का कोई मतलब नहीं है।

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। जाँच लाइनें: 151, 190. PhysicsClientUDP.cpp 151

शीर्ष पर: सरणी सीमाओं को पार करना

उदाहरण 6:

अरुण के लिए खोज करने के लिए अप्रिय त्रुटियों में से एक है। लूप में जटिल अनुक्रमण के कारण यह त्रुटि अक्सर होती है।

यहाँ, लूप कंडीशन में, dofIndex वेरिएबल की ऊपरी सीमा 128 है और dof''s 4 समावेशी है। लेकिन m_desiredState में केवल 128 आइटम शामिल हैं। नतीजतन, [dofIndex + dof] सूचकांक एक सरणी अतिरंजित हो सकता है।

V557 ऐरे ओवररन संभव है। 'DofIndex + dof' इंडेक्स का मान 130 तक पहुंच सकता है। PhysicsClientC_API.cpp 968

 #define MAX_DEGREE_OF_FREEDOM 128 double m_desiredState[MAX_DEGREE_OF_FREEDOM]; B3_SHARED_API int b3JointControl(int dofIndex, double* forces, int dofCount, ....) { .... if ( (dofIndex >= 0) && (dofIndex < MAX_DEGREE_OF_FREEDOM ) && dofCount >= 0 && dofCount <= 4) { for (int dof = 0; dof < dofCount; dof++) { command->m_sendState.m_desiredState[dofIndex+dof] = forces[dof]; .... } } .... } 

उदाहरण 7:

इसी तरह की एक त्रुटि लेकिन अब यह एक सरणी को अनुक्रमित करते समय नहीं बल्कि एक स्थिति में समेटने के कारण होता है। यदि फ़ाइल में अधिकतम लंबाई के साथ एक नाम है, तो टर्मिनल शून्य सरणी ( ऑफ-बाय-वन एरर ) के बाहर लिखा जाएगा। बेशक, लेन चर केवल असाधारण मामलों में MAX_FILENAME_LENGTH के बराबर होगा, लेकिन यह त्रुटि को समाप्त नहीं करता है, लेकिन केवल इसे दुर्लभ बनाता है।

V557 ऐरे ओवररन संभव है। 'लेन' सूचकांक का मान 1024 तक पहुंच सकता है। PhysicsClientC_API.cpp 5223

 #define MAX_FILENAME_LENGTH MAX_URDF_FILENAME_LENGTH 1024 struct b3Profile { char m_name[MAX_FILENAME_LENGTH]; int m_durationInMicroSeconds; }; int len = strlen(name); if (len >= 0 && len < (MAX_FILENAME_LENGTH + 1)) { command->m_type = CMD_PROFILE_TIMING; strcpy(command->m_profile.m_name, name); command->m_profile.m_name[len] = 0; } 

इसे एक बार मापें, इसे सात बार काटें

उदाहरण 8:

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

V807 प्रदर्शन में कमी। 'M_app-> m_renderer-> getActiveCamera () बार-बार अभिव्यक्ति का उपयोग करने से बचने के लिए एक पॉइंटर बनाने पर विचार करें। InverseKinematicsExample.cpp 315

 virtual void resetCamera() { .... if (....) { m_app->m_renderer->getActiveCamera()->setCameraDistance(dist); m_app->m_renderer->getActiveCamera()->setCameraPitch(pitch); m_app->m_renderer->getActiveCamera()->setCameraYaw(yaw); m_app->m_renderer->getActiveCamera()->setCameraPosition(....); } } 

एक ही कॉल चेन का उपयोग यहां कई बार किया जाता है और इसे सिंगल पॉइंटर से बदला जा सकता है।

उदाहरण 9:

V810 प्रदर्शन में कमी। 'BtCos (euler_out.pitch)' फ़ंक्शन को समान तर्कों के साथ कई बार कहा गया था। परिणाम को संभवतः एक अस्थायी चर में सहेजा जाना चाहिए, जिसे तब 'btAtan2' फ़ंक्शन को कॉल करते समय उपयोग किया जा सकता है। btMatrix3x3.h 576

V810 प्रदर्शन में कमी। समान तर्कों के साथ 'btCos (euler_out2.pitch)' समारोह को कई बार बुलाया गया। परिणाम को संभवतः एक अस्थायी चर में सहेजा जाना चाहिए, जिसे तब 'btAtan2' फ़ंक्शन को कॉल करते समय उपयोग किया जा सकता है। btMatrix3x3.h 578

 void getEulerZYX(....) const { .... if (....) { .... } else { .... euler_out.roll = btAtan2(m_el[2].y() / btCos(euler_out.pitch), m_el[2].z() / btCos(euler_out.pitch)); euler_out2.roll = btAtan2(m_el[2].y() / btCos(euler_out2.pitch), m_el[2].z() / btCos(euler_out2.pitch)); euler_out.yaw = btAtan2(m_el[1].x() / btCos(euler_out.pitch), m_el[0].x() / btCos(euler_out.pitch)); euler_out2.yaw = btAtan2(m_el[1].x() / btCos(euler_out2.pitch), m_el[0].x() / btCos(euler_out2.pitch)); } .... } 

इस स्थिति में, आप दो चर बना सकते हैं और euler_out.pitch और euler_out2.pitch के लिए btCos फ़ंक्शन द्वारा दिए गए मानों को सहेज सकते हैं, बजाय फ़ंक्शन को प्रत्येक तर्क के लिए चार बार कॉल कर सकते हैं।

रिसाव

उदाहरण 10:

परियोजना में निम्नलिखित प्रकार की बहुत सी त्रुटियों का पता लगाया गया था:

V773 'आयातक' पॉइंटर की दृश्यता का दायरा मेमोरी जारी किए बिना बाहर निकल गया था। एक स्मृति रिसाव संभव है। सीरियलाइज़सैटअप। सीपी 94

 void SerializeSetup::initPhysics() { .... btBulletWorldImporter* importer = new btBulletWorldImporter(m_dynamicsWorld); .... fclose(file); m_guiHelper->autogenerateGraphicsObjects(m_dynamicsWorld); } 

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

C ++ अपने कोड द्वारा रहता है

उदाहरण 11:

अगली त्रुटि कोड में दिखाई देती है क्योंकि C ++ नियम हमेशा गणितीय नियमों या "सामान्य ज्ञान" के साथ मेल नहीं खाते हैं। क्या आप देखेंगे कि इस छोटे से कोड के टुकड़े में कोई त्रुटि है?

 btAlignedObjectArray<btFractureBody*> m_fractureBodies; void btFractureDynamicsWorld::fractureCallback() { for (int i = 0; i < numManifolds; i++) { .... int f0 = m_fractureBodies.findLinearSearch(....); int f1 = m_fractureBodies.findLinearSearch(....); if (f0 == f1 == m_fractureBodies.size()) continue; .... } .... } 

विश्लेषक निम्नलिखित चेतावनी उत्पन्न करता है:

V709 संदिग्ध तुलना में पाया गया: 'f0 == f1 == m_fractureBodies.size ()'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। btFractureDynamicsWorld.cpp 483

ऐसा प्रतीत होता है कि स्थिति यह जांचती है कि f0 f1 के बराबर है और m_fractureBodies में मदों की संख्या के बराबर है। ऐसा लगता है कि इस तुलना को जांचना चाहिए था कि क्या f0 और f1 m_fractureBodies सरणी के अंत में स्थित हैं, क्योंकि वे findLinearSearch () विधि द्वारा पाई गई वस्तु स्थिति में हैं। लेकिन वास्तव में, यह अभिव्यक्ति यह देखने के लिए जांच में बदल जाती है कि क्या f0 और f1 m_fractureBodies.size () के बराबर हैं और फिर यह देखने के लिए कि क्या m_fractureBodies.size () परिणाम f0 == f1 के बराबर है। नतीजतन, यहां तीसरे ऑपरेंड की तुलना 0 या 1 से की जाती है।

सुंदर गलती! और, सौभाग्य से, काफी दुर्लभ। अब तक, हम इसे केवल दो ओपन सोर्स प्रोजेक्ट्स में मिले हैं, और यह दिलचस्प है कि ये सभी गेम इंजन थे।

उदाहरण 12:

स्ट्रिंग्स के साथ काम करते समय, अक्सर स्ट्रिंग क्लास द्वारा प्रदान की जाने वाली सुविधाओं का उपयोग करना बेहतर होता है। इसलिए, अगले दो मामलों के लिए क्रमशः MyStr.length () और val.clear () के साथ strlen (MyStr.c_str ()) और val = "" को बदलना बेहतर है।

V806 प्रदर्शन में कमी। Strlen (MyStr.c_str ()) तरह के अभिव्यक्ति को MyStr.length () के रूप में फिर से लिखा जा सकता है। RobotLoggingUtil.cpp 213

 FILE* createMinitaurLogFile(const char* fileName, std::string& structTypes, ....) { FILE* f = fopen(fileName, "wb"); if (f) { .... fwrite(structTypes.c_str(), strlen(structTypes.c_str()), 1, f); .... } .... } 

V815 प्रदर्शन में कमी। 'Val.clear ()' के साथ 'val = "" "की जगह पर विचार करें। b3CommandLineArgs.h 40

 void addArgs(int argc, char **argv) { .... std::string val; .... val = ""; .... } 

अन्य चेतावनियाँ थीं, लेकिन मुझे लगता है कि हम यहाँ रुक सकते हैं। जैसा कि आप देखते हैं, स्थैतिक कोड विश्लेषण विभिन्न त्रुटियों की एक विस्तृत श्रृंखला का पता लगा सकता है।

एक बार की परियोजना जांच के बारे में पढ़ना दिलचस्प है, लेकिन यह स्थिर कोड विश्लेषक का उपयोग करने का उचित तरीका नहीं है। और हम इसके बारे में नीचे बोलेंगे।

हमारे सामने त्रुटियां पाई गईं

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

रिपॉजिटरी में कई पुल अनुरोध नहीं थे और उनमें से कई इंजन के आंतरिक तर्क से संबंधित हैं। लेकिन ऐसी त्रुटियां भी थीं जो विश्लेषक का पता लगा सकते थे।

उदाहरण 13:

 char m_deviceExtensions[B3_MAX_STRING_LENGTH]; void b3OpenCLUtils_printDeviceInfo(cl_device_id device) { b3OpenCLDeviceInfo info; b3OpenCLUtils::getDeviceInfo(device, &info); .... if (info.m_deviceExtensions != 0) { .... } } 

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

V600 स्थिति का निरीक्षण करने पर विचार करें। 'Info.m_deviceExtensions' पॉइंटर हमेशा NULL के बराबर नहीं होता है। b3OpenCLUtils.cpp 551

उदाहरण 14:

क्या आप पता लगा सकते हैं कि अगले कार्य में क्या समस्या है?

 inline void Matrix4x4::SetIdentity() { m12 = m13 = m14 = m21 = m23 = m24 = m13 = m23 = m41 = m42 = m43 = 0.0; m11 = m22 = m33 = m44 = 1.0; } 

विश्लेषक निम्नलिखित चेतावनी देता है:

V570 समान मान दो बार 'm23' चर को सौंपा गया है। लीनियर ४.एच ६२h

V570 एक ही मान 'm13' चर के लिए दो बार सौंपा गया है। लीनियर 4.एच 627

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

 m12 = m13 = m14 = m21 = m23 = m24 = m31 = m32 = m34 = m41 = m42 = m43 = 0.0; 

उदाहरण 15:

BtSoftBody फ़ंक्शन की शर्तों में से एक में निम्न त्रुटि :: addAeroForceToNode () एक स्पष्ट बग के लिए नेतृत्व किया। पुल अनुरोध में टिप्पणी के अनुसार, बलों को गलत तरफ से वस्तुओं पर लागू किया गया था।

 struct eAeroModel { enum _ { V_Point, V_TwoSided, .... END }; }; void btSoftBody::addAeroForceToNode(....) { .... if (....) { if (btSoftBody::eAeroModel::V_TwoSided) { .... } .... } .... } 

PVS- स्टूडियो भी इस त्रुटि को पा सकता है और निम्नलिखित चेतावनी उत्पन्न कर सकता है:

V768 एन्यूमरेशन स्थिरांक 'V_TwoSided' का उपयोग बूलियन-प्रकार के एक चर के रूप में किया जाता है। btSoftBody.cpp 542

फिक्स्ड चेक इस तरह दिखता है:

 if (m_cfg.aeromodel == btSoftBody::eAeroModel::V_TwoSided) { .... } 

एक एन्यूमरेटर्स में किसी ऑब्जेक्ट की संपत्ति के समतुल्य के बजाय, V_TwoSered एन्यूमरेटर को स्वयं चेक किया गया था।

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

निष्कर्ष

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

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