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

पुष्टि करें कि आप ब्रेकपॉइंट की कौन-सी स्थिति देख रहे हैं

एक भरा हुआ लाल घेरा एक सक्षम (enabled) ब्रेकपॉइंट होता है; एक भरा हुआ धूसर घेरा अक्षम (disabled) होता है। एक खाली धूसर घेरे का अर्थ है कि डिबगर ब्रेकपॉइंट को रजिस्टर नहीं कर सका। VS Code का दस्तावेज़ इसके दो सामान्य कारण बताता है: पंक्ति में कोई निष्पादन योग्य (executable) कोड नहीं है, या डिबगर उस स्रोत फ़ाइल (source file) का समर्थन नहीं करता है। जो ब्रेकपॉइंट रजिस्टर नहीं हो सकते, वे सत्र शुरू होने पर भी खाली दिखाई दे सकते हैं; लाइव-एडिट समर्थन के बिना किसी सत्र के दौरान स्रोत कोड में संपादन करने पर भी यही संकेतक दिखाई दे सकता है। सटीक व्यवहार भाषा और डिबगर एक्सटेंशन के आधार पर भिन्न हो सकता है।

macOS पर, Shift–Command–D दबाकर Run and Debug खोलें। इसके BREAKPOINTS अनुभाग में, प्रासंगिक प्रविष्टि ढूंढें और पुष्टि करें कि यह सक्षम है। यह दृश्य आपको ब्रेकपॉइंट प्रबंधित करने की अनुमति देता है, लेकिन यह अपने आप यह स्पष्ट नहीं करता कि किसी डिबगर ने इसे अस्वीकार क्यों किया। चिह्नित पंक्ति पर एडिटर को खुला रखें ताकि आप स्रोत स्थिति की तुलना उस फ़ाइल से कर सकें जिसका उपयोग आपका सत्र कर रहा है। VS Code: Debug code

जांचें कि क्या पंक्ति निष्पादित हो सकती है

ब्रेकपॉइंट को किसी खाली पंक्ति, टिप्पणी (comment) या ब्रेस (brace) के बजाय किसी ऐसी पंक्ति पर ले जाएं जो कोई क्रिया करती हो, जैसे कि किसी फ़ंक्शन के अंदर का कोई स्टेटमेंट। ब्रेकपॉइंट केवल वहीं उपयोगी होता है जहां डिबगर निष्पादन को रोक सकता है। यदि सत्र शुरू करने के बाद प्रतिस्थापित मार्कर एक भरे हुए लाल घेरे में बदल जाता है, तो संभवतः मूल पंक्ति में कोई निष्पादन योग्य कोड नहीं था। यह दस्तावेजी व्यवहार से निकाला गया एक नैदानिक निष्कर्ष (diagnostic inference) है, कोई गारंटी नहीं: समर्थन और ब्रेकपॉइंट बाइंडिंग डिबगर और भाषा पर निर्भर करते हैं।

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

सक्रिय डिबगर और सत्र की जांच करें

VS Code में JavaScript, TypeScript और Node.js के लिए डिबगिंग समर्थन शामिल है। अन्य भाषाओं और रनटाइम्स के लिए आमतौर पर एक उपयुक्त डिबगर एक्सटेंशन की आवश्यकता होती है। पुष्टि करें कि प्रासंगिक एक्सटेंशन इंस्टॉल और सक्रिय है, फिर मेल खाने वाली भाषा या रनटाइम के लिए एक सत्र शुरू करें। यदि VS Code आपको डिबगर चुनने के लिए संकेत देता है, तो वह चुनें जो उस प्रोग्राम से मेल खाता हो जिसे आप चलाना चाहते हैं। किसी एक्सटेंशन का दस्तावेज़ उसकी समर्थित स्रोत फ़ाइलों, ब्रेकपॉइंट व्यवहार और लॉन्च विकल्पों को परिभाषित करता है। VS Code: Debug code

डिबगिंग शुरू करने के लिए F5 दबाएं, या कॉन्फ़िगरेशन चुनने के लिए Run and Debug का उपयोग करें। एक सरल प्रोग्राम सक्रिय फ़ाइल से चल सकता है, लेकिन एक विशिष्ट एंट्री पॉइंट, आर्ग्युमेंट्स, एनवायरनमेंट वेरिएबल्स या अटैच टारगेट वाले एप्लिकेशन को launch.json कॉन्फ़िगरेशन की आवश्यकता हो सकती है। अटैच सेटअप के लिए, सुनिश्चित करें कि लक्षित प्रोसेस पहले से ही डिबग मोड में चल रहा है और कनेक्शन विवरण मेल खाते हैं। प्रोग्राम के लोड किए गए स्रोत से भिन्न फ़ाइल में सही ढंग से रखा गया ब्रेकपॉइंट भी अनवेरीफाइड रह सकता है। VS Code: Configure debugging

एक संक्षिप्त क्रम के साथ कारण को सीमित करें

इस क्रम का उपयोग करें, और एक बार में केवल एक ही चीज़ बदलें ताकि परिणाम जानकारीपूर्ण हो:

  1. BREAKPOINTS में, सत्यापित करें कि ब्रेकपॉइंट सक्षम है और उसकी फ़ाइल तथा पंक्ति पर ध्यान दें।
  2. इसे उस फ़ाइल में किसी निष्पादन योग्य स्टेटमेंट पर ले जाएं।
  3. F5 के साथ अभीष्ट डिबग कॉन्फ़िगरेशन शुरू करें और देखें कि क्या मार्कर रजिस्टर होता है।
  4. यदि यह खाली ही रहता है, तो सत्यापित करें कि चयनित डिबगर फ़ाइल का समर्थन करता है और उसका एक्सटेंशन इंस्टॉल और सक्रिय है।
  5. जांचें कि क्या कॉन्फ़िगरेशन उस प्रोग्राम को लॉन्च या उससे अटैच करता है जो आपके द्वारा देखे जा रहे स्रोत से बनाया गया है। इसके एंट्री पॉइंट, वर्किंग डायरेक्टरी, और आपके प्रोजेक्ट से प्रासंगिक किसी भी बिल्ड या प्री-लॉन्च टास्क की समीक्षा करें।
  6. यदि एप्लिकेशन स्रोत कोड को रूपांतरित करता है, तो एडिटर फ़ाइलों को रनटाइम कोड से मैप करने के लिए भाषा डिबगर के निर्देशों का संदर्भ लें।

एक सफल जांच यह साबित नहीं करती कि किसी प्रोजेक्ट का प्रत्येक ब्रेकपॉइंट मान्य है; विशेष स्रोत स्थान पर जांच दोहराएं। यदि डिबगर किसी कॉन्फ़िगरेशन या रजिस्ट्रेशन त्रुटि की रिपोर्ट करता है, तो उस संदेश और एक्सटेंशन के दस्तावेज़ का उपयोग करके अगला बदलाव करें। किसी भिन्न डिबगर की सेटिंग्स कॉपी करने से बचें: VS Code बताता है कि कॉन्फ़िगरेशन गुण और क्षमताएं चयनित डिबगर और अनुरोध प्रकार पर निर्भर करती हैं। VS Code: Configure debugging

संकेतक क्या बता सकता है और क्या नहीं

खाली घेरा आपको यह बताता है कि डिबगर ने उस ब्रेकपॉइंट को रजिस्टर नहीं किया है। यह अपने आप में किसी गैर-निष्पादन योग्य पंक्ति, असमर्थित स्रोत, एडिटर और रनटाइम कोड के बीच बेमेल, या अन्य डिबगर-विशिष्ट सीमाओं के बीच अंतर नहीं कर सकता है। सबसे उपयोगी अगला कदम अभीष्ट सत्र में स्पष्ट रूप से निष्पादन योग्य पंक्ति का परीक्षण करना है, फिर यदि रजिस्ट्रेशन अभी भी विफल रहता है तो डिबगर और सोर्स मैपिंग को सत्यापित करना है। Mac पर, मुख्य नियंत्रण वही VS Code एडिटर गटर, Run and Debug दृश्य, F5, और Shift–Command–D हैं; डिबगर-विशिष्ट सुधार एक्सटेंशन या रनटाइम दस्तावेज़ से ही प्राप्त होने चाहिए।

स्रोत