विंडोज सत्यापन के लिए इंटेल आईपीपी नमूने - जारी रखा

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

पिछला लेख "इंटेल आईपीपी सैंपल फॉर विंडोज - वर्क ऑन एरर्स" [ 1 ] 27 जनवरी, 2011 को प्रकाशित हुआ था। लगभग 9 महीने बीत चुके हैं। इस समय के दौरान, लेख में वर्णित कई त्रुटियां आईपीपी नमूने में तय की गई थीं। कई पुस्तकालय अद्यतन जारी किए गए हैं। हालांकि, चूंकि इंटेल डेवलपर्स पीवीएस-स्टूडियो में रुचि नहीं रखते थे, इसलिए परीक्षण एक बार निकला। और अब आप अच्छी तरह से देख सकते हैं कि इसके विकास के 9 महीनों के बाद विश्लेषक कौन सी नई दिलचस्प त्रुटियां पाएंगे।

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

क्लासिक अपरिभाषित व्यवहार

template<typename T, Ipp32s size> void HadamardFwdFast(..., Ipp16s* pDst) { Ipp32s *pTemp; ... for(j=0;j<4;j++) { a[0] = pTemp[0*4] + pTemp[1*4]; a[1] = pTemp[0*4] - pTemp[1*4]; a[2] = pTemp[2*4] + pTemp[3*4]; a[3] = pTemp[2*4] - pTemp[3*4]; pTemp = pTemp++; pDst[0*4] = (Ipp16s)(a[0] + a[2]); pDst[1*4] = (Ipp16s)(a[1] + a[3]); pDst[2*4] = (Ipp16s)(a[0] - a[2]); pDst[3*4] = (Ipp16s)(a[1] - a[3]); pDst = pDst++; } ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V567 अपरिभाषित व्यवहार। अनुक्रम बिंदुओं के बीच दो बार उपयोग किए जाने के दौरान 'pTemp' चर को संशोधित किया जाता है। मुझे umc_me_cost_func.h 168

V567 अपरिभाषित व्यवहार। अनुक्रम बिंदुओं के बीच दो बार उपयोग किए जाने के दौरान 'pDst' चर को संशोधित किया जाता है। मुझे umc_me_cost_func.h 174

बस एक विहित उदाहरण, जो अनिश्चित व्यवहार को प्रदर्शित करने के लिए लेखों में दिया गया है [ 2 ]। यह कहना असंभव है कि चर pTemp और pDst में वृद्धि होगी या नहीं, क्योंकि वे एक ही अनुक्रम बिंदु के भीतर दो बार बदलते हैं। परिणाम संकलक और अनुकूलन सेटिंग्स पर निर्भर करता है।

एक और समान कोड स्निपेट है:

 void VC1BRC_I::CompleteFrame(ePType picType) { ... m_Quant.LimIQuant = m_Quant.LimIQuant--; ... m_Quant.IQuant = m_Quant.IQuant--; ... } 

अपरिभाषित व्यवहार और उपसर्ग वृद्धि

 bool MoveOnNextFrame() { if (m_nFrames>0) { m_pFrame[m_curIndex] = 0; m_curIndex = (++m_curIndex)%m_maxN; m_nFrames--; return true; } return false; } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V567 अपरिभाषित व्यवहार। अनुक्रम बिंदुओं के बीच दो बार उपयोग किए जाने के दौरान 'm_curIndex' चर को संशोधित किया जाता है। vc1_enc umc_vc1_enc_planes.h 630

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

ए = m_curIndex + 1;

बी = ए% m_maxN;

m_curIndex = B;

m_curIndex = A;

व्यवहार में, ऐसा होने की संभावना नहीं है, और चर तुरंत बढ़ाया जाएगा, लेकिन आप किसी भी तरह से इस पर भरोसा नहीं कर सकते।

ऑब्जेक्ट नाम में टाइपो

 IPLFUN(void, iplMpyRCPack2D, (IplImage* srcA, IplImage* srcB, IplImage* dst)) { ... if( (srcA->depth == IPL_DEPTH_8U ) || (srcB->depth == IPL_DEPTH_8U ) || (srcB->depth == IPL_DEPTH_16U) || (srcB->depth == IPL_DEPTH_16U) || (srcA->depth == IPL_DEPTH_1U ) || (srcB->depth == IPL_DEPTH_1U ) ) ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V501 समान उप-अभिव्यक्तियाँ हैं (srcB-> गहराई == 16) 'बाईं ओर और' '' के दाईं ओर || ऑपरेटर। ipl iplmpy2d.c 457

यदि आप कोड को करीब से देखते हैं, तो आप एक रेंगने वाले टाइपो को देखेंगे। चेक खो गया: "(srcA-> गहराई == IPL_DEPTH_16U)"।

अधूरा बफर सफाई

 UMC::Status VC1EncoderADV::SetMEParams_I_Field(UMC::MeParams* MEParams) { UMC::Status umcSts UMC::UMC_OK; memset(MEParams,0,sizeof(MEParams)); ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V512 'मेमसेट' फ़ंक्शन के कॉल से बफर 'MEParams' का बहिर्वाह होगा। vc1_enc umc_vc1_enc_adv.cpp 1767

बफर का केवल एक हिस्सा साफ हो गया है, क्योंकि "sizeof (MEParams)" पॉइंटर के आकार को लौटाता है, संरचना को नहीं। सही आकार की गणना करने के लिए, पॉइंटर को डिरेल किया जाना चाहिए: "sizeof (* MEParams)"।

कॉपी-पेस्ट त्रुटि

 Status VC1VideoDecoder::ResizeBuffer() { ... if(m_pContext && m_pContext->m_seqLayerHeader && m_pContext->m_seqLayerHeader->heightMB && m_pContext->m_seqLayerHeader->heightMB) ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V501 समान उप-अभिव्यक्तियाँ हैं 'm_pContext-> m_seqLayerHeader-> heightMB' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। vc1_dec umc_vc1_video_decoder.cpp 1351

सबसे अधिक संभावना है, प्रतिलिपि बनाई गई रेखा को सरल बनाने के लिए, लेकिन इसे ठीक करना भूल गया। ऐसा लगता है कि यह इस तरह होना चाहिए था:

 if(m_pContext && m_pContext->m_seqLayerHeader && m_pContext->m_seqLayerHeader->heightMB && m_pContext->m_seqLayerHeader->widthMB) 

किसी व्यूह की सीमा से परे जाना

 Ipp32f pa_nb_long[NUM_CHANNELS][2][MAX_PPT_LONG]; MP3Status mp3enc_psychoacousticInit(...) { ... for (ch = 0; ch < NUM_CHANNELS; ch++) for (i = 0; i < MAX_PPT_LONG; i++) { for (j = 0; j < 3; j++) state->pa_nb_long[ch][j][i] = (Ipp32f)1.0e30; } ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V557 ऐरे ओवररन संभव है। 'J' इंडेक्स का मान 2. mp3_enc mp3enc_psychoacoustic_fp.c 361 तक पहुंच सकता है

यह कोड एक विभाजन त्रुटि की ओर जाता है। चर 'जे' मान ले सकता है 2. हालांकि, केवल संख्या 0 और 1 वैध सूचकांक हैं। सबसे अधिक संभावना है, लूप को इस तरह होना चाहिए:

 for (j = 0; j < 2; j++) 

अन्य छोरों को पाया गया है जो सरणियों से परे ले जाने की संभावना है।

 typedef Ipp32f samplefbout[2][18][32]; samplefbout fbout_data[NUM_CHANNELS]; static void mp3enc_scale_factor_calc_l2(MP3Enc *state) { ... for (ch = 0; ch < stereo + state->com.mc_channel; ch++) { for (t = 0; t < 3; t++) { for (sb = 0; sb < sblimit_real; sb++){ for (j = 0; j < 12; j++) fbout[j] = state->fbout_data[ch][0][t * 12 + j][sb]; ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V557 ऐरे ओवररन संभव है। 'T * 12 + j' इंडेक्स का मान 35 तक पहुंच सकता है। mp3_enc mp3enc_quantization_12_fp.c 275

यदि एक स्थिति संभव है कि t == 2, और j == 11, तो सरणी सीमाओं से परे जाएगी। इस कोड को किस तरह देखा जाना चाहिए, मैं जवाब देने के नुकसान में हूं।

सरणी 'नमूनाफाउट' का उपयोग आसानी से नहीं हो रहा है। कोड का एक और टुकड़ा:

 typedef Ipp32f samplefbout[2][18][32]; samplefbout fbout_data[NUM_CHANNELS]; static void mp3enc_join_LR_l2(MP3Enc *state) { Ipp32s sb, j; Ipp32s sblimit_real = state->com.sblimit_real; for (sb = 0; sb < sblimit_real; sb++) for (j = 0; j < 36; j++) state->fbout_data[2][0][j][sb] = 0.5f * (state->fbout_data[0][0][j][sb] + state->fbout_data[1][0][j][sb]); } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V557 ऐरे ओवररन संभव है। 'J' इंडेक्स का मान 35 तक पहुंच सकता है। mp3_enc mp3enc_quantization_12_fp.c 639

V557 ऐरे ओवररन संभव है। 'J' इंडेक्स का मान 35 तक पहुंच सकता है। mp3_enc mp3enc_quantization_12_fp.c 640

दो छोरों के लिए एक चर का उपयोग करना

 JERRCODE CJPEGDecoder::DecodeScanBaselineNI(void) { ... for(c = 0; c < m_scan_ncomps; c++) { block = m_block_buffer + (DCTSIZE2*m_nblock*(j+(i*m_numxMCU))); // skip any relevant components for(c = 0; c < m_ccomp[m_curr_comp_no].m_comp_no; c++) { block += (DCTSIZE2*m_ccomp[c].m_nblocks); } ... } ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V535 चर 'c' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। jpegcodec jpegdec.cpp 4652

इस कोड के साथ समस्या यह है कि चर 'c' बाहरी और नेस्टेड छोरों में एक साथ प्रयोग किया जाता है। छोरों के सीमा मूल्यों के आधार पर, यह कोड सभी डेटा को संसाधित नहीं कर सकता है या एक अनंत लूप तक ले जा सकता है।

अनारक्षित त्रुटियां

पहले लेख में वर्णित कई त्रुटियां तय की गई हैं। लेकिन IPP नमूने के कुछ डेवलपर्स ने या तो ध्यान नहीं दिया या उन्हें लगा कि ये गलतियाँ नहीं हैं। उदाहरण के लिए, इस टुकड़े के साथ एक समान स्थिति:

 vm_file* vm_file_fopen(const vm_char* fname, const vm_char* mode) { ... mds[3] = FILE_ATTRIBUTE_NORMAL | (islog == 0) ? 0 : FILE_FLAG_NO_BUFFERING; ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' की तुलना में ऑपरेटर की प्राथमिकता कम है। ऑपरेटर। vm vm_file_win.c 393

अजीब कोड

कोड के कई खंड हैं जिनके बारे में कहना मुश्किल है, असली गलती यह है या केवल अनावश्यक कोड है। मैं कुछ उदाहरण दूंगा।

 int ec_fb_GetSubbandNum(void* stat) { _fbECState* state = (_fbECState*)stat; return (state->freq - state->freq); } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V501 बाईं ओर और '-' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति हैं: राज्य-> freq - राज्य-> freq भाषण ec_fb.c 253

बहुत अजीब सुविधा। यहां, अप्रयुक्त चर के साथ या तो अजीब तरह से संघर्ष किया गया है, या 'वापसी' बयान को दूसरी अभिव्यक्ति का परिणाम लौटना चाहिए।

 AACStatus alsdecGetFrame(...) { ... if (state->msbFirst == 0) { for (i = 0; i < num; i++) { *tmpPtr = *srcPrt; tmpPtr += state->numChannels; srcPrt++; } } else { for (i = 0; i < num; i++) { *tmpPtr = *srcPrt; tmpPtr += state->numChannels; srcPrt++; } } ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। aac_dec als_dec_api.c 923

वैसे मैं क्या कह सकता हूं? संदिग्ध! हमें विभिन्न परिस्थितियों में दो समान चक्रों की आवश्यकता क्यों है?

 void rrGetNextBunch_Spiral(...) { int x,y; ... if(x < 0) if(x < 0) goto _begine; ... if(y < 0) if(y < 0) goto _begine; ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V571 आवर्ती जाँच। 'If (x <0)' स्थिति पहले से ही लाइन 1025 में सत्यापित की गई थी। 3 डी-दर्शक rrdemosupport.capp 1026

V571 आवर्ती जाँच। 'If (y <0)' स्थिति पहले से ही लाइन 1028 में सत्यापित थी। 3 डी-दर्शक rrdemosupport.capp 1029

अजीब तरह से डुप्लीकेट चेक।

 Status H264ENC_MAKE_NAME(H264CoreEncoder_UpdateRefPicMarking) (void* state) { ... // set frame_num to zero for this picture, for correct // FrameNumWrap core_enc->m_pCurrentFrame->m_FrameNum = 0; core_enc->m_pCurrentFrame->m_FrameNum = 0; ... } 

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

V519 'core_enc-> m_pCurrentFrame-> m_FrameNum' चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 1804, 1805. h264_enc umc_h264_video_encoder_tmpl.cpp.h 1805

गलती से एक स्ट्रिंग की नकल की? या आप एक और चर रीसेट करना चाहते थे? यह स्पष्ट नहीं है।

निष्कर्ष

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

ग्रंथ सूची

1. एंड्री कार्पोव। विंडोज के लिए इंटेल आईपीपी नमूने - बग पर काम करते हैं। http://www.viva64.com/go.php?url=741
2. एलेना सगलायेवा। अनुक्रम अंक http://www.viva64.com/go.php?url=665