जावा में हेइसेनबग के संभावित और संभावित कारण?

Question

मुझे एक हेज़ेनबग का क्लासिक उदाहरण मिला है जो कि एक शर्त से ट्रिगर हुआ है जिसे मैंने पहले नहीं देखा था। मेरा विरासत अनुप्रयोग (पुराने कोड के लगभग 100 के स्लोक) एक विशिष्ट उदाहरण में ठीक से काम करने में विफल रहता है और केवल जेपीडीए को रिमोट डीबग करने के लिए पर्याप्त व्यवहार को बदलता है, जिससे एप्लिकेशन सही तरीके से काम कर सकता है: "-Xdebug -Xnoagent -Xrunjdwp जोड़ने के अलावा कुछ भी नहीं कर रहा है: परिवहन = dt_socket, server = y, suspend = n, पता = 6666 "vm की कमांड लाइन में बग को छुपाता है (वास्तविक कनेक्शन के साथ या उसके बिना)। यह देखते हुए कि मेरे पास पूरी तरह से दोहराया जाने वाला टेस्ट केस है, मैं इसे छिपाने में वापस जाने के मामले में कोड परिवर्तनों के साथ बहुत परेशान करने से नफरत करता हूं। और निश्चित रूप से, यह केवल उत्पादन में हो रहा है।

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

Heisenbugs:

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

अन्वेषण के लायक किसी भी अन्य मामले?

संपादित करता:

• हाँ, JPDA कोड सक्षम पुराने सिंटैक्स का उपयोग करता। मैंने यह देखने के लिए परीक्षण नहीं किया है कि आधुनिक वाक्यविन्यास का उपयोग व्यवहार को भी बदलता है या नहीं।
• इस विशिष्ट मशीन JRE के लिए उपयोग कर रहा है 1.8.0_45-b14, और हॉटस्पॉट 64-बिट सर्वर वी एम (निर्माण 25.45-B02)
• जबकि प्रश्न सामान्य होना है, भड़काने मुद्दा वास्तविक और वर्तमान है। चूंकि समस्या एक तैनात प्रणाली में प्रकट हो रही है, इसलिए मैं इसे एक वर्कअराउंड के रूप में -Xdebug के साथ चलने के लिए छोड़ने के बीच फटा हुआ हूं ताकि यह परिचालन में रह सके और अंतर्निहित बग को ट्रैक करना और उसे मारना चाहते हैं।
• प्रश्न में खराब कार्यप्रणाली एक बहु-चरण डेटा प्रोसेसिंग पाइपलाइन का हिस्सा है - विवरणों से कोई फर्क नहीं पड़ता है, लेकिन एक स्टैंडअलोन एप्लिकेशन के रूप में सबसे अच्छा समझा जा सकता है जो डेटाबेस से कुछ जानकारी प्राप्त करता है, फिर कुछ फ़ाइलों को संशोधित करने के लिए इसका उपयोग करता है ।टूटने वाली प्रणाली का हिस्सा यह प्रतीत होता है कि डेटाबेस से जानकारी का सही ढंग से व्याख्या नहीं किया जा रहा है - टूटी ऑब्जेक्ट ओआरएम या कैश से कुछ भी। जब यह "टूटा हुआ" होता है, तो एप्लिकेशन तर्क यह निर्धारित करता है कि क्या यह करने के लिए काम किया गया है (डीबी की सामग्री के आधार पर) सभी पुनरावृत्तियों के लिए गलत विकल्प बनाता है (प्रोग्राम के एकाधिक आमंत्रण सहित हजारों पुनरावृत्तियों)। जब यह "काम कर रहा है" (केवल अंतर यह है कि वीएम -Xdebug के साथ चल रहा है या नहीं), एप्लिकेशन सभी पुनरावृत्तियों के लिए सही विकल्प बनाता है। यह इस विन्यास में पूरी तरह से संगत है। अलग-अलग डेटाबेस के खिलाफ चलने वाला एक ही कोड विफल नहीं होता है। कुछ सबूत (इस कोड के साथ मेरी भागीदारी predating) कि समान व्यवहार अतीत कि रहस्यमय तरीके से मालूम होता है नाबालिग कोड-परिवर्तन के बाद काम करना शुरू किया में देखा गया है नहीं है ... देख "heisenbug"

Answer 1

मैं एक मामले में जहां था विफलता को उस हार्डवेयर पर ऊर्जा बचत सुविधा द्वारा उकसाया गया था जिसे बग अध्ययन के दौरान सक्रिय नहीं किया गया था।

Answer 2

-Xdebug एक व्यवहार बदलने स्विच की तरह लगता है। What are Java command line options to set to allow JVM to be remotely debugged? दावा करता है कि यह आपको जेआईटी से सभी व्याख्याओं में बदल देता है। अन्य ऑरैकल जावा डॉक्स (for jrocket admittedly) यह इंगित करते हैं कि यह कुछ अनिर्दिष्ट कारणों के लिए धीमा है और यह तैनात सिस्टम के लिए उपयुक्त नहीं है।

मैं कल्पना कर सकता हूं कि विभिन्न जीसी योजनाएं शायद बदलाव कर रही हैं।