एक ढेर भ्रष्टाचार खोजने का सबसे अच्छा तरीका क्या है जो केवल प्रदर्शन परीक्षण के तहत होता है?

Question

सॉफ़्टवेयर जो मैं काम करता हूं (सी ++ में लिखा गया है) इस समय भ्रष्टाचार की समस्या है। हमारी परफ टेस्ट टीम WER दोष प्राप्त करती रहती है जब बॉक्स पर लॉग इन किए गए उपयोगकर्ताओं की संख्या एक निश्चित थ्रेशोल्ड तक पहुंच जाती है लेकिन उन्होंने मुझे जो डंप दिए हैं, वे केवल असंगत क्षेत्रों में भ्रष्टाचार दिखाते हैं (जैसे कि std :: string उदाहरण के लिए अंतर्निहित स्मृति को मुक्त करता है) ।

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

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

Answer 1

सबसे अच्छा उपकरण gFlags के साथ संयोजन में एपवर्फायर है लेकिन कई अन्य समाधान हैं जो मदद कर सकते हैं।

उदाहरण के लिए, आप एक ढेर की जांच हर 16 malloc, realloc, नि: शुल्क है, और _msize संचालन निम्न कोड के साथ निर्दिष्ट कर सकते हैं:

#include <crtdbg.h> 
int main() 
{ 
int tmp; 

// Get the current bits 
tmp = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG); 

// Clear the upper 16 bits and OR in the desired freqency 
tmp = (tmp & 0x0000FFFF) | _CRTDBG_CHECK_EVERY_16_DF; 

// Set the new bits 
_CrtSetDbgFlag(tmp); 
} 

Answer 2

आपके पास सहानुभूति है: ट्रैक करने में एक बहुत ही मुश्किल समस्या है।

जैसा कि आप सामान्य रूप से कहते हैं कि यह दुर्घटना से कुछ समय पहले होता है, आम तौर पर एक गलत व्यवहार लिखने के परिणामस्वरूप (उदाहरण के लिए हटाए गए मेमोरी को लिखना, सरणी के अंत से बाहर चलना, एक memcpy में आवंटित स्मृति से अधिक, आदि) ।

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

मैंने डबल डिलीट का पता लगाने के लिए नए ओवरलोड किए हैं और ऑपरेटरों को हटा दिया है, लेकिन यह काफी विशिष्ट स्थिति है।

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

सभी बेहतरीन।

Answer 3

आप क्या अपने सॉफ्टवेयर वास्तव में करता है पर आगे विस्तार से बता देना चाहिए। क्या यह बहु थ्रेडेड है? जब आप "बॉक्स पर लॉग इन किए गए उपयोगकर्ताओं की संख्या" के बारे में बात करते हैं, तो क्या प्रत्येक उपयोगकर्ता एक अलग सत्र में आपके सॉफ़्टवेयर का एक अलग उदाहरण खोलता है? क्या आपका सॉफ्टवेयर एक वेब सेवा है? उदाहरण एक दूसरे से बात करें (नामित पाइप के साथ)?

अपने त्रुटि केवल उच्च लोड पर होता है और नहीं होती जब AppVerifier चल रहा है करता है। केवल दो संभावनाएं (और जानकारी के बिना) है कि मैं के बारे में सोच सकते हैं आप कैसे क्रियान्वित किया है बहु सूत्रण या परीक्षण मशीन एक हार्डवेयर मुद्दा यह है कि केवल भारी बोझ के नीचे प्रकट होता है (अपने परीक्षकों के एक से अधिक मशीन का इस्तेमाल किया है के साथ एक संगामिति मुद्दा है ?)।