डॉकटर कंटेनर के अंदर पीवीएस-स्टूडियो का उपयोग करके लिब्रेपीसीबी परियोजना का सत्यापन

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

LibrePCB

लिबरपीसीबी इलेक्ट्रॉनिक सर्किट और मुद्रित सर्किट बोर्ड को डिजाइन करने के लिए मुफ्त सॉफ्टवेयर है। प्रोग्राम कोड C ++ में लिखा गया है, और Qt5 का उपयोग ग्राफिकल इंटरफ़ेस बनाने के लिए किया जाता है। हाल ही में, इस एप्लिकेशन की पहली आधिकारिक रिलीज़ हुई, जिसने अपने स्वयं के फ़ाइल प्रारूप (* .lp, * .lplib) के स्थिरीकरण को चिह्नित किया। लिनक्स, मैकओएस और विंडोज के लिए तैयार किए गए बाइनरी पैकेज।



LibrePCB एक छोटी परियोजना है जिसमें C और C ++ में कोड की लगभग 300,000 गैर-खाली लाइनें हैं। इसी समय, गैर-रिक्त लाइनों के 25% टिप्पणियां हैं। वैसे, टिप्पणियों के लिए यह एक बड़ा प्रतिशत है। सबसे अधिक संभावना है, यह इस तथ्य के कारण है कि परियोजना में कई छोटी फाइलें हैं, जिनमें से एक महत्वपूर्ण हिस्सा परियोजना की जानकारी और लाइसेंस से टिप्पणियों के शीर्षक द्वारा कब्जा कर लिया गया है। GitHub साइट कोड: LibrePCB ।

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

डाक में काम करनेवाला मज़दूर

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

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

डॉकटर में एक ओपन सोर्स प्रोजेक्ट का परीक्षण करने का पहला अनुभव एज़्योर सर्विस फैब्रिक के साथ था। वहाँ, डेवलपर्स ने कंटेनर में स्रोत फ़ाइल निर्देशिका की स्थापना की और कंटेनर में चल रही स्क्रिप्ट में से एक को संपादित करने के लिए विश्लेषक एकीकरण सीमित था:

diff --git a/src/build.sh b/src/build.sh index 290c57d..2a286dc 100755 --- a/src/build.sh +++ b/src/build.sh @@ -193,6 +193,9 @@ BuildDir() cd ${ProjBinRoot}/build.${DirName} + pvs-studio-analyzer analyze --cfg /src/PVS-Studio.cfg \ + -o ./service-fabric-pvs.log -j4 + if [ "false" = ${SkipBuild} ]; then if (( $NumProc <= 0 )); then NumProc=$(($(getconf _NPROCESSORS_ONLN)+0)) 

लिबरपीसीबी परियोजना के बीच अंतर यह है कि उन्होंने छवि और उस परियोजना के निर्माण के लिए तुरंत डॉकरीफाइल प्रदान किया। यह हमारे लिए और भी सुविधाजनक निकला। यहाँ डॉकर फ़ाइल का एक हिस्सा है जिसमें हम रुचि रखते हैं:

 FROM ubuntu:14.04 # install packages RUN DEBIAN_FRONTEND=noninteractive \ apt-get -q update \ && apt-get -qy upgrade \ && apt-get -qy install git g++ qt5-default qttools5-dev-tools qt5-doc \ qtcreator libglu1-mesa-dev dia \ && apt-get clean # checkout librepcb RUN git clone --recursive https://..../LibrePCB.git /opt/LibrePCB \ && cd /opt/LibrePCB .... # build and install librepcb RUN /opt/LibrePCB/dev/docker/make_librepcb.sh .... 

हम छवि का संयोजन करते समय परियोजना का संकलन और स्थापना नहीं करेंगे। इस प्रकार, हमने एक छवि एकत्र की जिसमें परियोजना का लेखक परियोजना की सफल विधानसभा की गारंटी देता है।

कंटेनर शुरू करने के बाद, विश्लेषक स्थापित किया गया था और परियोजना का निर्माण और विश्लेषण करने के लिए निम्नलिखित कमांड निष्पादित किए गए थे:

 cd /opt/LibrePCB mkdir build && cd build qmake -r ../librepcb.pro pvs-studio-analyzer trace -- make -j2 pvs-studio-analyzer analyze -l /mnt/Share/PVS-Studio.lic -r /opt/LibrePCB \ -o /opt/LibrePCB/LibrePCB.log -v -j4 cp -R -L -a /opt/LibrePCB /mnt/Share 

वैसे, सभी क्रियाएं विंडोज 10 में की गई थीं। यह बहुत ही मनभावन है कि सभी लोकप्रिय ऑपरेटिंग सिस्टम के डेवलपर्स भी इस दिशा में विकास कर रहे हैं। दुर्भाग्य से, विंडोज के साथ कंटेनर इतने सुविधाजनक नहीं हैं। विशेष रूप से असंभव की वजह से भी आसानी से सॉफ्टवेयर स्थापित करने के लिए।

कीड़े मिले

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

1. पीवीएस-स्टूडियो में जीएनयू आर्म एंबेडेड टूलचिन के लिए समर्थन शामिल है ;
2. PVS-Studio: MISRA C और MISRA C ++ कोडिंग मानकों का समर्थन करता है ।

शुद्धिपत्र

 SymbolPreviewGraphicsItem::SymbolPreviewGraphicsItem( const IF_GraphicsLayerProvider& layerProvider, const QStringList& localeOrder, const Symbol& symbol, const Component* cmp, const tl::optional<Uuid>& symbVarUuid, const tl::optional<Uuid>& symbVarItemUuid) noexcept { if (mComponent && symbVarUuid && symbVarItemUuid) .... if (mComponent && symbVarItemUuid && symbVarItemUuid) // <= .... } 

PVS-Studio चेतावनी: V501 CWE-571 बाईं और 'ऑपरेटर' के दाईं ओर समान समरूप अभिव्यक्तियाँ 'symbVarItemUuid' हैं। सिंबलव्यूग्राफिक्सिटेम। सीपी 74

क्लासिक टाइपो: वेरिएबल सिम्ब्रायटिम्यूड को एक पंक्ति में दो बार जांचा जाता है। ऊपर एक समान चेक है, और इसे देखते हुए, यह स्पष्ट हो जाता है कि चेक किए जाने वाले दूसरे वेरिएबल को symbVarUuid होना चाहिए।

निम्नलिखित टाइपो कोड स्निपेट:

 void Clipper::DoMaxima(TEdge *e) { .... if (e->OutIdx >= 0) { AddOutPt(e, e->Top); e->OutIdx = Unassigned; } DeleteFromAEL(e); if (eMaxPair->OutIdx >= 0) { AddOutPt(eMaxPair, e->Top); // <= eMaxPair->OutIdx = Unassigned; } DeleteFromAEL(eMaxPair); .... } 

PVS-Studio चेतावनी: V778 CWE-682 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'eMaxPair' वेरिएबल का उपयोग 'e' के बजाय किया जाना चाहिए। क्लिपर 29pp 2999

सबसे अधिक संभावना है, कोड कॉपी-पेस्ट का उपयोग करके लिखा गया था। पाठ के दूसरे ब्लॉक में निरीक्षण के कारण, वे e- axPair-> शीर्ष के साथ e-> शीर्ष को बदलना भूल गए।

अतिरिक्त जांच

 static int rndr_emphasis(hoedown_buffer *ob, const hoedown_buffer *content, const hoedown_renderer_data *data) { if (!content || !content->size) return 0; HOEDOWN_BUFPUTSL(ob, "<em>"); if (content) hoedown_buffer_put(ob, content->data, content->size); HOEDOWN_BUFPUTSL(ob, "</em>"); return 1; } 

PVS-Studio चेतावनी: V547 CWE-571 अभिव्यक्ति 'सामग्री' हमेशा सच होती है। html.c 162

यह शायद अभी भी एक त्रुटि नहीं है, लेकिन केवल अनावश्यक कोड है। कंटेंट पॉइंटर को दोबारा चेक करने की जरूरत नहीं। यदि यह शून्य है, तो फ़ंक्शन तुरंत अपना काम पूरा करता है।

इसी तरह की स्थिति:

 void Clipper::DoMaxima(TEdge *e) { .... else if( e->OutIdx >= 0 && eMaxPair->OutIdx >= 0 ) { if (e->OutIdx >= 0) AddLocalMaxPoly(e, eMaxPair, e->Top); DeleteFromAEL(e); DeleteFromAEL(eMaxPair); } .... } 

PVS-Studio चेतावनी : V547 CWE-571 अभिव्यक्ति 'e-> OutIdx> = 0' हमेशा सच होता है। क्लिपर 29pp 2983

रीचेकिंग (e-> OutIdx> = 0) का कोई मतलब नहीं है। हालाँकि, शायद यह एक गलती है। उदाहरण के लिए, हम मान सकते हैं कि चर e-> शीर्ष की जाँच की जानी चाहिए। हालाँकि, यह केवल एक कूबड़ है। हम परियोजना कोड से परिचित नहीं हैं और अनावश्यक कोड से त्रुटियों को अलग नहीं कर सकते हैं :)।

और एक और मामला:

 QString SExpression::toString(int indent) const { .... if (child.isLineBreak() && nextChildIsLineBreak) { if (child.isLineBreak() && (i > 0) && mChildren.at(i - 1).isLineBreak()) { // too many line breaks ;) } else { str += '\n'; } } .... } 

PVS-Studio चेतावनी: V571 CWE-571 आवर्ती जाँच। 'Child.isLineBreak ()' स्थिति पहले से ही लाइन 208 में सत्यापित की गई थी। sexpression.cpp 209

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

 void FootprintPreviewGraphicsItem::paint(....) noexcept { .... for (const Circle& circle : mFootprint.getCircles()) { layer = mLayerProvider.getLayer(*circle.getLayerName()); if (!layer) continue; // <= if (layer) { // <= pen = QPen(....); painter->setPen(pen); } else painter->setPen(Qt::NoPen); .... } .... } 

PVS-Studio चेतावनी: V547 CWE-571 अभिव्यक्ति 'परत' हमेशा सच होती है। footprintpreviewgraphicsitem.cpp 177

चूंकि दूसरे में स्थिति हमेशा कथन सत्य होती है, इसलिए दूसरी शाखा कभी संतुष्ट नहीं होती है।

भूल गए पॉइंटर चेक

 extern int ZEXPORT unzGetGlobalComment ( unzFile file, char * szComment, uLong uSizeBuf) { .... if (uReadThis>0) { *szComment='\0'; if (ZREAD64(s->z_filefunc,s->filestream,szComment,uReadThis)!=uReadThis) return UNZ_ERRNO; } if ((szComment != NULL) && (uSizeBuf > s->gi.size_comment)) *(szComment+s->gi.size_comment)='\0'; .... } 

PVS-Studio चेतावनी: V595 CWE-476 'szComment' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 2068, 2073। unzip.c 2068

यदि uReadThis> 0 है , तो szComment पॉइंटर को डिरेल किया जाता है । यह खतरनाक है क्योंकि यह सूचक शून्य हो सकता है। विश्लेषक इस तथ्य के आधार पर ऐसा निष्कर्ष निकालता है कि आगे इस सूचक को समानता NULL के लिए जांचा जाता है।

अनारक्षित वर्ग के सदस्य

 template <class T> class Edge { public: using VertexType = Vector2<T>; Edge(const VertexType &p1, const VertexType &p2, T w=-1) : p1(p1), p2(p2), weight(w) {}; // <= Edge(const Edge &e) : p1(e.p1), p2(e.p2), weight(e.weight), isBad(false) {}; Edge() : p1(0,0), p2(0,0), weight(0), isBad(false) {} VertexType p1; VertexType p2; T weight=0; bool isBad; }; 

PVS-Studio चेतावनी: V730 CWE-457 निर्माणकर्ता के अंदर एक वर्ग के सभी सदस्यों को आरंभिक नहीं किया गया है। निरीक्षण करने पर विचार करें: किनारे। १४

पहले को छोड़कर सभी कंस्ट्रक्टर, आइसबैड क्लास के क्षेत्र को इनिशियलाइज़ करते हैं। सबसे अधिक संभावना है, पहला निर्माणकर्ता बस गलती से यह आरंभीकरण करना भूल गया था। नतीजतन, पहला निर्माणकर्ता एक अपूर्ण प्रारंभिक ऑब्जेक्ट बनाता है, जिससे अपरिभाषित कार्यक्रम व्यवहार हो सकता है।

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

स्मृति रिसाव

 template <typename ElementType> void ProjectLibrary::loadElements(....) { .... ElementType* element = new ElementType(elementDir, false); // can throw if (elementList.contains(element->getUuid())) { throw RuntimeError( __FILE__, __LINE__, QString(tr("There are multiple library elements with the same " "UUID in the directory \"%1\"")) .arg(subdirPath.toNative())); } .... } 

PVS-Studio चेतावनी: V773 CWE-401 अपवाद को 'तत्व' पॉइंटर जारी किए बिना फेंक दिया गया था। एक स्मृति रिसाव संभव है। Projectlibrary.cpp 245

यदि कोई तत्व पहले से ही सूची में है, तो एक अपवाद फेंक दिया जाएगा। लेकिन यह पहले से बनाई गई वस्तु को नष्ट नहीं करता है, जो सूचक तत्व चर में संग्रहीत है।

अमान्य अपवाद प्रकार

 bool CmdRemoveSelectedSchematicItems::performExecute() { .... throw new LogicError(__FILE__, __LINE__); .... } 

PVS-Studio चेतावनी: V1022 CWE-755 एक अपवाद सूचक द्वारा फेंका गया था। इसके बजाय मूल्य द्वारा फेंकने पर विचार करें। cmdremoveselectedschematicitems.cpp 143

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

सामान्य तौर पर, नया ऑपरेटर दुर्घटना द्वारा यहां लिखा जाता है और इसे हटा दिया जाना चाहिए। यह एक गलती है कि इस तथ्य से पुष्टि की जाती है कि अन्य सभी स्थानों पर यह कहता है:

 throw LogicError(__FILE__, __LINE__); 

डायनामिक_कास्ट का खतरनाक उपयोग

 void GraphicsView::handleMouseWheelEvent( QGraphicsSceneWheelEvent* event) noexcept { if (event->modifiers().testFlag(Qt::ShiftModifier)) .... } bool GraphicsView::eventFilter(QObject* obj, QEvent* event) { .... handleMouseWheelEvent(dynamic_cast<QGraphicsSceneWheelEvent*>(event)); .... } 

PVS-Studio चेतावनी: V522 CWE-628 अशक्त सूचक 'घटना' की Dereferencing हो सकती है। संभावित नल पॉइंटर को 'handleMouseWheelEvent' फंक्शन में पास किया जाता है। पहले तर्क का निरीक्षण करें। चेक लाइनें: 143, 252. ग्राफिक्सव्यू.पीसी 143

डायनामिक_कास्ट ऑपरेटर से उत्पन्न पॉइंटरमाउथव्हीलवेंट फ़ंक्शन को पास किया जाता है। इसमें, इस सूचक को पूर्व सत्यापन के बिना dereferenced है।

यह खतरनाक है क्योंकि डायनेमिक_कास्ट ऑपरेटर nullptr वापस कर सकता है। यह पता चला है कि यह कोड सिर्फ तेज static_cast का उपयोग करने से बेहतर नहीं है।

उपयोग से पहले एक स्पष्ट पॉइंटर चेक को इस कोड में जोड़ा जाना चाहिए।

इसके अलावा, इस तरह का कोड बहुत आम है:

 bool GraphicsView::eventFilter(QObject* obj, QEvent* event) { .... QGraphicsSceneMouseEvent* e = dynamic_cast<QGraphicsSceneMouseEvent*>(event); Q_ASSERT(e); if (e->button() == Qt::MiddleButton) .... } 

PVS-Studio चेतावनी: V522 CWE-690 एक संभावित नल पॉइंटर 'e' की ड्रीफरिंग हो सकती है। graphicsview.cpp 206

सूचक को Q_ASSERT मैक्रो का उपयोग करके चेक किया गया है। यहाँ उसका वर्णन है:

यदि परीक्षण झूठा है तो स्रोत कोड फ़ाइल नाम और लाइन नंबर युक्त चेतावनी संदेश प्रिंट करता है। Q_ASSERT () विकास के दौरान पूर्व और बाद की स्थितियों के परीक्षण के लिए उपयोगी है। यह कुछ भी नहीं है अगर संकलन के दौरान QT_NO_DEBUG को परिभाषित किया गया था।

Q_ASSERT उपयोग करने से पहले पॉइंटर्स की जांच करने का एक बुरा तरीका है। एक नियम के रूप में, रिलीज़ संस्करण में QT_NO_DEBUG परिभाषित नहीं है। मुझे नहीं पता कि लिब्रेपीसी प्रोजेक्ट में चीजें कैसी हैं। हालाँकि, यदि QT_NO_DEBUG को रिलीज़ में परिभाषित किया गया है, तो यह एक अजीब और गैर-मानक समाधान है।

यदि मैक्रो शून्य में फैलता है, तो यह पता चला है कि कोई सत्यापन नहीं है। और फिर यह स्पष्ट नहीं है कि डायनेमिक_कास्ट का उपयोग क्यों करें। Static_cast का उपयोग क्यों नहीं करते हैं?

सामान्य तौर पर, यह कोड गंधहीन होता है और सभी समान कोड अंशों की समीक्षा के लायक होता है। और वहाँ, वैसे भी, उनमें से एक बहुत हैं। मैंने ऐसे ही cases२ मामले गिनाए!

निष्कर्ष

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

यदि आप इस लेख को अंग्रेजी बोलने वाले श्रोताओं के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: एंड्री कारपोव, सियावेटोस्लाव रेज़मस्लोव। एक डॉकटर कंटेनर के अंदर PVS-Studio के साथ LibrePCB की जाँच करना ।