2019 में जावा प्रोजेक्ट्स में शीर्ष 10 कीड़े मिले

2019 समाप्त हो रहा है, और पीवीएस-स्टूडियो टीम इस वर्ष की उपलब्धियों को देख रही है। 2019 की शुरुआत में, हमने जावा समर्थन को जोड़कर हमारे विश्लेषक की नैदानिक ​​क्षमताओं को बढ़ाया, जिसने हमें जावा परियोजनाओं की भी जांच और समीक्षा करने में सक्षम बनाया। हमें इस वर्ष बहुत सारे बग मिले हैं, और यहाँ जावा प्रोजेक्ट्स में हमारे शीर्ष 10 कीड़े पाए गए हैं।

नहीं। 10: हस्ताक्षरित बाइट

स्रोत: पीवीएस-स्टूडियो स्टेटिक कोड एनालाइजर द्वारा अपाचे डब्बू आरपीसी फ्रेमवर्क का विश्लेषण

V6007 अभिव्यक्ति 'endKey [i] <0xff' हमेशा सच होती है। OptionUtil.java (32)

public static final ByteSequence prefixEndOf(ByteSequence prefix) { byte[] endKey = prefix.getBytes().clone(); for (int i = endKey.length - 1; i >= 0; i--) { if (endKey[i] < 0xff) { // <= endKey[i] = (byte) (endKey[i] + 1); return ByteSequence.from(Arrays.copyOf(endKey, i + 1)); } } return ByteSequence.from(NO_PREFIX_END); } 

कई प्रोग्रामर मानते हैं कि बाइट प्रकार अहस्ताक्षरित है। यह वास्तव में कई प्रोग्रामिंग भाषाओं में मामला है। उदाहरण के लिए, यह C # के लिए सही है। लेकिन जावा में ऐसा नहीं है।

EndKey [i] <0xff स्थिति में, टाइप बाइट के एक चर की तुलना हेक्साडेसिमल रूप में दर्शाई गई 255 (0xff) संख्या से की जाती है। डेवलपर शायद यह भूल गया कि जावा बाइट प्रकार की सीमा [-128, 127] है। यह स्थिति हमेशा सत्य होगी, और लूप के लिए हमेशा एंडके सरणी के अंतिम तत्व का ही प्रसंस्करण होगा।

नहीं। 9: दो में एक

स्रोत: जावा के लिए पीवीएस-स्टूडियो सड़क को हिट करता है। अगला पड़ाव है एलीटेसर्च

V6007 अभिव्यक्ति '(int) x <0' हमेशा गलत है। BCrypt.java (429)

V6025 संभवतः सूचकांक '(int) x' सीमा से बाहर है। BCrypt.java (431)

 private static byte char64(char x) { if ((int)x < 0 || (int)x > index_64.length) return -1; return index_64[(int)x]; } 

डिस्काउंट! एक विधि - दो कीड़े! पहले चार प्रकार के साथ करना होगा: चूंकि यह जावा में अहस्ताक्षरित है, इसलिए (int) x <0 स्थिति हमेशा झूठी होगी। दूसरी बग इंडेक्स_64 सरणी की सीमा से परे साधारण इंडेक्सिंग है जब (int) x == index_64.length । यह स्थिति (int) x> index_64.length के कारण होता है। बग को '>' ऑपरेटर को '> =' में बदलकर ठीक किया जा सकता है: (int) x> = index_64.length ।

नहीं। 8: एक समाधान और इसके निहितार्थ

स्रोत: पीवीएस-स्टूडियो के साथ सीयूबीए प्लेटफार्म के कोड का विश्लेषण

V6007 अभिव्यक्ति 'पिछले MenuItemFlatIndex > = 0' हमेशा सच होता है। क्यूबासाइडमेन्यूविजेट.जावा (328)

 protected MenuItemWidget findNextMenuItem(MenuItemWidget currentItem) { List<MenuTreeNode> menuTree = buildVisibleTree(this); List<MenuItemWidget> menuItemWidgets = menuTreeToList(menuTree); int menuItemFlatIndex = menuItemWidgets.indexOf(currentItem); int previousMenuItemFlatIndex = menuItemFlatIndex + 1; if (previousMenuItemFlatIndex >= 0) { // <= return menuItemWidgets.get(previousMenuItemFlatIndex); } return null; } 

FindNextMenuItem विधि के लेखक जब menuItemWidgets सूची में currentItem नहीं होता है, तो indexOf विधि द्वारा दिए गए मान -1 से छुटकारा पाना चाहता था। ऐसा करने के लिए, प्रोग्रामर indexOf ( menuItemFlatIndex वैरिएबल) के परिणाम में 1 जोड़ रहा है और परिणामी मान को वेरिएबल पिछले MenuItemFlatIndex पर लिख रहा है, जो तब विधि में उपयोग किया जाता है। -1 का जोड़ना एक खराब समाधान साबित होता है क्योंकि यह एक ही बार में कई त्रुटियों को जन्म देता है:

• रिटर्न नल स्टेटमेंट को कभी भी निष्पादित नहीं किया जाएगा क्योंकि पिछलेमेनु इटेमफ्लैटइंडेक्स> = 0 अभिव्यक्ति हमेशा सच होगी; इसलिए, ifNextMenuItem विधि हमेशा if स्टेटमेंट के भीतर से वापस आ जाएगी;
• एक indexOutOfBoundsException तब उठाया जाएगा जब मेनूइटेमविडेट्स सूची खाली हो गई है क्योंकि प्रोग्राम खाली सूची के पहले तत्व तक पहुंचने का प्रयास करेगा;
• एक indexOutOfBoundsException चालू किया जाएगा जब currentItem तर्क मेनू के अंतिम तत्व बन गया है ।Wemgetget सूची।

नहीं। 7: किसी भी चीज़ से फ़ाइल बनाना

स्रोत: हुआवेई क्लाउड: पीवीएस-स्टूडियो टुडे में बादल छाए रहेंगे

V6008 'डेटाटेम्पाइल' के संभावित अशक्तता। कैचेमनगर.जावा (91)

 @Override public void putToCache(PutRecordsRequest putRecordsRequest) { .... if (dataTmpFile == null || !dataTmpFile.exists()) { try { dataTmpFile.createNewFile(); // <= } catch (IOException e) { LOGGER.error("Failed to create cache tmp file, return.", e); return; } } .... } 

PutToCache विधि लिखते समय, प्रोग्रामर ने डेटा में एक टाइपो बनाया TTFile == null || एक नई फ़ाइल dataTmpFile.createNewFile () बनाने से पहले? उन्होंने लिखा: '==' के बजाय '=' ऑपरेटर। यह टाइपो createNewFile पद्धति को कॉल करते समय NullPointerException को फेंकने का नेतृत्व करेगा। यह वही है जो हालत तय किए गए टाइपो के साथ दिखता है:

 if (dataTmpFile != null || !dataTmpFile.exists()) 

आप सोच सकते हैं, "ठीक है, ठीक है, हम अब आराम कर सकते हैं।" अभी तक नहीं!

अब जबकि एक बग को ठीक कर दिया गया है, एक और दिखाया गया है। DataTmpFile.exists () विधि को कॉल करते समय एक NullPointerException को फेंक दिया जा सकता है। इसे ठीक करने के लिए, हमें '' को बदलने की आवश्यकता है। '&&' के साथ ऑपरेटर। यह सभी फ़िक्सेस के बाद स्थिति का अंतिम संस्करण है:

 if (dataTmpFile != null && !dataTmpFile.exists()) 

नहीं। 6: एक बहुत ही अजीब तर्क त्रुटि

स्रोत: जावा के लिए पीवीएस-स्टूडियो

V6007 [CWE-570] अभिव्यक्ति '"0"। असमान (पाठ)' हमेशा गलत है। ConvertIntegerToDecimalPredicate.java 46

 public boolean satisfiedBy(@NotNull PsiElement element) { .... @NonNls final String text = expression.getText().replaceAll("_", ""); if (text == null || text.length() < 2) { return false; } if ("0".equals(text) || "0L".equals(text) || "0l".equals(text)) {// <= return false; } return text.charAt(0) == '0'; } 

इस पद्धति के बारे में दिलचस्प बात यह है कि इसमें एक स्पष्ट तर्क त्रुटि शामिल है। यदि संतोषजनक विधि पहले कथन के बाद वापस नहीं आती है, तो इसका मतलब होगा कि पाठ स्ट्रिंग कम से कम दो वर्ण लंबा है। इसका अर्थ यह भी है कि यदि कथन निरर्थक है, तो पहले 0 "।" (। पाठ) की जाँच करें। प्रोग्रामर का वास्तव में क्या मतलब है यह एक रहस्य बना हुआ है।

नहीं। 5: क्या एक मोड़!

स्रोत: पीवीएस-स्टूडियो ने अपाचे हाइव का दौरा किया

V6034 'बिटश शिफ्टइन्वायर - 1' के मान से शिफ्ट प्रकार के आकार के साथ असंगत हो सकता है: 'बिटश शिफ्ट्सवर्ल्ड - 1' = [-1 ... 30]। अनसाइन्टइंटेंट २००s.जावा (१igned ९ १)

 private void shiftRightDestructive(int wordShifts, int bitShiftsInWord, boolean roundUp) { if (wordShifts == 0 && bitShiftsInWord == 0) { return; } assert (wordShifts >= 0); assert (bitShiftsInWord >= 0); assert (bitShiftsInWord < 32); if (wordShifts >= 4) { zeroClear(); return; } final int shiftRestore = 32 - bitShiftsInWord; // check this because "123 << 32" will be 123. final boolean noRestore = bitShiftsInWord == 0; final int roundCarryNoRestoreMask = 1 << 31; final int roundCarryMask = (1 << (bitShiftsInWord - 1)); // <= .... } 

इनपुट तर्कों के साथ शब्दशः = 3 और बिटशिफ्टइवॉर्ड = 0 , राउंडकार्रीमास्क चर, जो बिटवाइड शिफ्ट के परिणाम को संग्रहीत करता है (1 << (bitShiftsInWord - 1)) , एक ऋणात्मक संख्या बन जाएगी। डेवलपर को शायद यह उम्मीद नहीं थी।

नहीं। 4: क्या हम अपवादों को देख सकते हैं?

स्रोत: पीवीएस-स्टूडियो ने अपाचे हाइव का दौरा किया

V6051 'अंत' ब्लॉक में 'रिटर्न' स्टेटमेंट के उपयोग से अनचाहे अपवादों का नुकसान हो सकता है। ObjectStore.java (9080)

 private List<MPartitionColumnStatistics> getMPartitionColumnStatistics(....) throws NoSuchObjectException, MetaException { boolean committed = false; try { .... /*some actions*/ committed = commitTransaction(); return result; } catch (Exception ex) { LOG.error("Error retrieving statistics via jdo", ex); if (ex instanceof MetaException) { throw (MetaException) ex; } throw new MetaException(ex.getMessage()); } finally { if (!committed) { rollbackTransaction(); return Lists.newArrayList(); } } } 

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

नहीं। 3: Hocus-pocus, या एक नया मुखौटा प्राप्त करने की कोशिश कर रहा है

स्रोत: पीवीएस-स्टूडियो ने अपाचे हाइव का दौरा किया

V6034 शिफ्ट 'जे' के मान से आकार के अनुसार असंगत हो सकता है: 'जे' = [0 ... 63]। IoTrace.java (272)

 public void logSargResult(int stripeIx, boolean[] rgsToRead) { .... for (int i = 0, valOffset = 0; i < elements; ++i, valOffset += 64) { long val = 0; for (int j = 0; j < 64; ++j) { int ix = valOffset + j; if (rgsToRead.length == ix) break; if (!rgsToRead[ix]) continue; val = val | (1 << j); // <= } .... } .... } 

इस बग को भी एक बिटवाइज़ शिफ्ट के साथ करना होगा, लेकिन इतना ही नहीं। J वैरिएबल का उपयोग लूप के लिए आंतरिक में सीमा [0 ... 63] पर एक काउंटर के रूप में किया जाता है। यह काउंटर एक बिटवाइज़ शिफ्ट 1 << j में भाग लेता है। सब कुछ ठीक लगता है, लेकिन यहाँ पर पूर्णांक शाब्दिक '1' प्रकार का इंट (एक 32-बिट मान) खेलने में आता है। इसकी वजह से, बिट वाइट शिफ्ट में जे वेरिएबल की वैल्यू 31 से अधिक हो जाने पर पहले से लौटाए गए मानों को वापस करना शुरू कर देगा। यदि यह व्यवहार प्रोग्रामर नहीं चाहता है, तो मान 1 को लंबे समय तक दर्शाना चाहिए: 1L << j या (लंबा) 1 << j ।

नहीं। 2: प्रारंभिक आदेश

स्रोत: हुआवेई क्लाउड: पीवीएस-स्टूडियो टुडे में बादल छाए रहेंगे

V6050 क्लास आरंभीकरण चक्र मौजूद है। 'लॉग' के आरंभीकरण से पहले 'INSTANCE' का प्रारंभ दिखाई देता है। अनट्रस्टेडएसएसएल.जावा (32), अनट्रस्टिएसएसएल.जवा (59), अनट्रिस्वर्डएसएसएल.जावा (33)

 public class UntrustedSSL { private static final UntrustedSSL INSTANCE = new UntrustedSSL(); private static final Logger LOG = LoggerFactory.getLogger(UntrustedSSL.class); .... private UntrustedSSL() { try { .... } catch (Throwable t) { LOG.error(t.getMessage(), t); // <= } } } 

जिस क्रम में किसी वर्ग में फ़ील्ड घोषित किए जाते हैं, उनमें फर्क होता है, क्योंकि वे उसी क्रम में आरम्भ किए जाते हैं, जिस क्रम में उन्हें घोषित किया जाता है। इस तथ्य को भूल जाने से ऊपर की तरह मायावी कीड़े हो जाते हैं।

विश्लेषक बताता है कि स्टैटिक फील्ड लॉग को उस समय कंस्ट्रक्टर में डिरेल्ड किया जाता है जब इसे वैल्यू नल के लिए इनिशियलाइज़ किया जाता है, जो अपवादों की एक श्रृंखला को फेंकने की ओर ले जाता है NullPointerException -> ExceptionInInterizerError ।

लेकिन स्थैतिक क्षेत्र लॉग में कंस्ट्रक्टर को कॉल करने के समय मूल्य शून्य क्यों है?

ExceptionInInitializerError सुराग है। कंस्ट्रक्टर स्थैतिक फ़ील्ड INSTANCE को इनिशियलाइज़ कर रहा है, जिसे लॉग फ़ील्ड से पहले घोषित किया गया है। यही कारण है कि जब निर्माणकर्ता को बुलाया जाता है तो लॉग फ़ील्ड को अभी तक आरंभ नहीं किया जाता है। इस कोड को ठीक से काम करने के लिए, कॉल से पहले लॉग फ़ील्ड को आरंभीकृत किया जाना चाहिए।

पहला: कॉपी-पेस्ट ओरिएंटेड प्रोग्रामिंग

स्रोत: अपाचे Hadoop कोड गुणवत्ता: उत्पादन वी.एस. टेस्ट

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'लोकलफेयर' के बजाय 'लोकलफाइल्स' चर का उपयोग किया जाना चाहिए। LocalDistributedCacheManager.java (183), LocalDistributedCacheManager.java (178), LocalDistributedCacheManager.java (176), LocalDistributedCacheManager.java (181)

 public synchronized void setup(JobConf conf, JobID jobId) throws IOException { .... // Update the configuration object with localized data. if (!localArchives.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALARCHIVES, StringUtils .arrayToString(localArchives.toArray(new String[localArchives // <= .size()]))); } if (!localFiles.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALFILES, StringUtils .arrayToString(localFiles.toArray(new String[localArchives // <= .size()]))); } .... } 

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

• localArchives को स्थानीय फ़ाइल में बदल दिया गया था;
• MRJobConfig.CACHE_LOCALARCHIVES को MRJobConfig.CACHE_LOCALFILES में बदल दिया गया।

लेकिन प्रोग्रामर इस सरल ऑपरेशन में भी एक गलती करने में कामयाब रहा: अगर विश्लेषक द्वारा बताई गई लाइन में दिए गए स्टेटमेंट अभी भी स्पष्ट रूप से इच्छित लोकलफाइल्स वेरिएबल के बजाय लोकल आर्च चर का उपयोग कर रहे हैं।

निष्कर्ष

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

हम उस पर नहीं रुकने वाले हैं और अपने टूल में सुधार और वृद्धि करते रहने की योजना बना रहे हैं। अगले वर्ष और भी अधिक दिलचस्प बग के साथ नए निदान और लेखों के लिए बने रहें।

मैं तुम्हें रोमांच पसंद करता हूँ! सबसे पहले, आपने 2019 में C # प्रोजेक्ट में शीर्ष 10 बगों को हराया और अब आपने जावा के साथ भी मुकाबला किया! अगले स्तर पर आपका स्वागत है - 2019 में C ++ प्रोजेक्ट्स में सर्वश्रेष्ठ त्रुटियों के बारे में लेख।