रिलीज़ और डिबग के बीच के अंतर के बारे में कहानियों की एक जोड़ी

सभी डेवलपर्स जानते हैं कि रिलीज़ संस्करण डीबग संस्करण से भिन्न हो सकता है। इस लेख में मैं आपको जीवन के कुछ मामले बताऊंगा जब इस तरह के मतभेदों के कारण कार्यक्रम को गलत तरीके से अंजाम दिया गया। उदाहरण बहुत मुश्किल नहीं हैं, लेकिन वे आपको एक रेक पर कदम रखने से बचा सकते हैं।

कहानी १

दरअसल, यह सब इस तथ्य से शुरू हुआ था कि एक बग आया था कि एप्लिकेशन कुछ संचालन के साथ क्रैश हो जाता है। ऐसा अक्सर होता है। बग डिबग संस्करण में खेलना नहीं चाहता था। ऐसा कभी-कभी होता है। चूँकि आवेदन में कुछ पुस्तकालयों को C ++ में लिखा गया था, इसलिए पहला विचार कुछ ऐसा था "कहीं वे चर को प्रारंभ करना भूल गए या ऐसा कुछ"। लेकिन वास्तव में, बग का सार प्रबंधित कोड में कवर किया गया था, हालांकि यह अप्रबंधित कोड के बिना भी संभव था।

और कोड कुछ इस तरह निकला:

class Wrapper : IDisposable
{
public IntPtr Obj { get ; private set ;};

public Wrapper()
{
this .Obj = CreateUnmObject();
}

~Wrapper()
{
this .Dispose( false );
}

protected virtual void Dispose( bool disposing)
{
if (disposing)
{
}

this .ReleaseUnmObject( this .Obj);
this .Obj = IntPtr .Zero;
}

public void Dispose()
{
this .Dispose( true );
GC.SuppressFinalize( this );
}
}

* This source code was highlighted with Source Code Highlighter .

सिद्धांत रूप में, आईडीसॉर्पोरेट टेम्पलेट ("व्यावहारिक रूप से" का लगभग कैनोनिकल कार्यान्वयन है - क्योंकि कोई निपटारा चर नहीं है, इसके बजाय सूचक को शून्य पर रीसेट करने के लिए) एक अप्रबंधित संसाधन का पूरी तरह से मानक आवरण वर्ग है।

वर्ग का उपयोग लगभग इस प्रकार किया गया था:

{
Wrapper wr = new Wrapper();
calc.DoCalculations(wr.Obj);
}

* This source code was highlighted with Source Code Highlighter .

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

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

यदि आप DoCalculations कॉल को (Wrapper wr = new Wrapper ()) {...} का उपयोग करते हुए लपेटते हैं, तो यह समस्या को हल कर देगा, क्योंकि अंत में ब्लॉक में कॉल कॉल लालची कचरा संग्रहकर्ता को समय से पहले ऑब्जेक्ट "खाने" की अनुमति नहीं देगा। यदि किसी कारण से हम Dispose को कॉल नहीं कर सकते हैं या नहीं करना चाहते हैं (उदाहरण के लिए, WPF इस टेम्पलेट का पक्ष नहीं लेता है), तो हमें DoCalculations को कॉल करने के बाद GC.KeepAlive (wr) डालना होगा।

निश्चित रूप से, वास्तविक कोड अधिक कठिन था और इसमें त्रुटि को उजागर करना उदाहरण के रूप में सरल नहीं था।

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

कहानी २

एक बार एक परियोजना थी जहां एक प्रबंधक संसाधनों का उपयोग करने के लिए इस्तेमाल किया गया था, जो एक स्ट्रिंग कुंजी का उपयोग करके, दिए गए विधानसभा से एक अलग प्रकार के संसाधनों को निकालता है। लेखन कोड को सुविधाजनक बनाने के लिए, निम्नलिखित विधि लिखी गई:

public string GetResource( string key)
{
Assembly assembly = Assembly .GetCallingAssembly();
return this .GetResource(assembly, key);
}

* This source code was highlighted with Source Code Highlighter .

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

"अंतर महसूस करने के लिए" निम्नलिखित उदाहरण प्रस्तावित है:

dll1:
public class Class1
{
public void Method1()
{
Console .WriteLine( new StackTrace());
}
}

dll2:
public class Class2
{
public void Method21()
{
this .Method22();
}

public void Method22()
{
( new Class1()).Method1();
}
}

dll3:
class Program
{
static void Main( string [] args)
{
( new Class3()).Method3();
}
}
class Class3
{
public void Method3()
{
( new Class2()).Method21();
}
}

* This source code was highlighted with Source Code Highlighter .

यदि आप इसे बैच कॉन्फ़िगरेशन (या यदि आप स्टूडियो से प्रक्रिया शुरू करते हैं) में संकलित करते हैं, तो हमें एक ईमानदार कॉल स्टैक मिलता है:
in ClassLibrary1.Class1.Method1 ()
in ClassLibrary2.Class2.Method22 ()
in ClassLibrary2.Class2.Method21 ()
ConsoleApplication1.Class3.Method3 () में
ConsoleApplication1.Program.Main (स्ट्रिंग [] args) में

यदि आप .Net संस्करण को जारी में 3.5 समावेशी के तहत बनाते हैं:
in ClassLibrary1.Class1.Method1 ()
in ClassLibrary2.Class2.Method21 ()
ConsoleApplication1.Program.Main (स्ट्रिंग [] args) में

और .Net 4 रिलीज कॉन्फ़िगरेशन में हम सभी पर मिलेगा:
ConsoleApplication1.Program.Main (स्ट्रिंग [] args) में

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

बस मामले में, यह याद रखने योग्य है कि आप कंपाइलर को किसी तरीके को एम्बेड करने से रोक सकते हैं [MethodImpl (MethodImplOptions.NoInlining)] विशेषता के साथ, VC ++ में __decspecec (noinline) एनालॉग का एक प्रकार।

एक निष्कर्ष के बजाय

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