संकलन कुछ तरीकों में तय ब्लॉक के बाद कोड को छोड़ देता है

Question

हम हमारी परियोजनाओं में से एक में एक कक्षा में निम्न विधि:

private unsafe void SomeMethod() 
{ 
    // Beginning of the method omitted for brevity 

    var nv = new Vector4[x]; 

    fixed (Vector4* vp = nv) 
    { 
     fixed (float* tp = /* Source float ptr */) 
     { 
      fixed (double* ap = /* Source double ptr */) 
      { 
       for (var i = atlArray.Length - 1; i >= 0; --i) 
       { 
        vp[((i + 1) << 3) - 2] = new Vector4(tp[i], btt, 0.0f, 1.0f); 
        // Additional Vector4 construction omitted for brevity 

        nttp[i] = new Vector2(tp[i], this.ttvp); 
        nts[i] = string.Format(ap[i], /* etc. */); 
       } 
      } 
     } 
    } 

    this.ts = nts; 
    this.ttp = nttp; 
    this.V = nv; // <- This is a property setter 
} 

मैं इस अंधेरा करना पड़ा है, लेकिन उम्मीद है कि यह अभी भी काफी स्पष्ट एक पाने के लिए है क्या हो रहा है इसका विचार।

डीबग बिल्ड में हमारे डेवलपर्स मशीनों में से एक पर, सी # कंपाइलर fixed ब्लॉक बंद होने के बाद होने वाले तीन असाइनमेंट को हटा देता है। यदि हम इन पंक्तियों पर ब्रेकपॉइंट डालने का प्रयास करते हैं, तो एप्लिकेशन प्रारंभ होने पर विधि के अंत में ब्रेसपॉइंट छोड़ देता है। कोड जो fixed ब्लॉक के बीच प्रकट होता है और किसी विधि के अंत को अन्य विधियों में भी हटा दिया जाता है, लेकिन परेशान रूप से, उन सभी में नहीं।

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

डिबग प्रभावित मशीन पर बनाया गया DLL में (अनुकूलन के साथ बंद कर दिया), एक वापसी सेशन सीधे दिखाई देने के बाद ap ढेर बंद पॉपअप है:

IL_03a1: nop 
IL_03a2: ldc.i4.0 
IL_03a3: conv.u 
IL_03a4: stloc.s ap 
IL_03a6: ret 

यही कारण है stloc से पहले तीन कार्य आगे बढ़ निर्देश काम करता है। डिबग मेरी मशीन पर बनाया गया DLL में वापसी की उम्मीद सेशन जगह में होता है तीन कार्य के बाद:

IL_03a5: nop 
IL_03a6: ldc.i4.0 
IL_03a7: conv.u 
IL_03a8: stloc.s ap 
IL_03aa: nop 
IL_03ab: ldc.i4.0 
IL_03ac: conv.u 
IL_03ad: stloc.s tp 
IL_03af: nop 
IL_03b0: ldc.i4.0 
IL_03b1: conv.u 
IL_03b2: stloc.s vp 
IL_03b4: ldarg.0 
IL_03b5: ldloc.s nts 
IL_03b7: stfld  string[] N.B.E.B::ts 
IL_03bc: ldarg.0 
IL_03bd: ldloc.s nttp 
IL_03bf: stfld  valuetype [SharpDX]SharpDX.Vector2[] N.B.E.B::ttp 
IL_03c4: ldarg.0 
IL_03c5: ldloc.s nv 
IL_03c7: call  instance void N.B.E.B::set_V(valuetype [SharpDX]SharpDX.Vector4[]) 
IL_03cc: nop 
IL_03cd: ret 

हम अब तक एक SSCCE उत्पादन करने में विफल रहा है - यह केवल बहुत विशिष्ट परिस्थितियों में प्रकट करने के लिए लगता है , और केवल हमारी परियोजनाओं में से एक में। हमने जांच की है कि विजुअल स्टूडियो, .NET फ्रेमवर्क के समान संस्करण, सी # कंपाइलर और एमएसबिल्ड दोनों मशीनों पर उपयोग किए जा रहे हैं। हमने ओएस संस्करण और अपडेट जैसे अन्य संभावित मतभेदों की जांच की है। दोनों मशीनों पर चीजें समान होती हैं (वे लैपटॉप का एक ही मॉडल हैं)। हम स्पष्ट रूप से थोड़ा परेशान हैं। कोई भी सहायताकाफी प्रशंसनीय होगी।

Answer 1

मेरे सहयोगी, डेवलपर जिसकी मशीन यह प्रभावित कर रही थी, निर्माण से नैदानिक ​​आउटपुट में एक अंतर पाया - यह सी # कंपाइलर था। हमने सोचा था कि एमएसबिल्ड अपेक्षित स्थान (सी: \ प्रोग्राम फ़ाइलें (x86) \ MSBuild \ 12.0 \ Bin) में csc.exe का उपयोग कर रहा था, लेकिन विचित्र रूप से, यह वास्तव में C: \ उपयोगकर्ताओं में csc.exe निष्पादित कर रहा था \ [उपयोगकर्ता] \ AppData \ Local \ Microsoft \ VisualStudio \ 12.0 \ एक्सटेंशन, जिसमें एक पूरी तरह से अलग संस्करण था। हम नहीं जानते कि कैसे कंपाइलर निष्पादन योग्य था, या एमएसबिल्ड द्वारा इसका संदर्भ कैसे दिया जा रहा था, लेकिन एक बार इसे हटा दिए जाने के बाद, एमएसबिल्ड अपने घर बिन निर्देशिका में csc.exe के संस्करण का उपयोग करने के लिए वापस लौटा, और कोड हो रहा है अभी सही बनाया गया है।