2010-05-20 11 views
7

मेरे पास मेरी प्रोजेक्ट में एक स्रोत फ़ाइल है, जिसमें 65,536 से अधिक कोड लाइनें हैं (112,444 सटीक होने के लिए)। मैं एक "स्क्लाइट समामेलन" का उपयोग कर रहा हूं, जो एक विशाल स्रोत फ़ाइल में आता है।विशाल सी फ़ाइल डीबगिंग समस्या

मैं एमएसवीसी 2005 का उपयोग कर रहा हूं। समस्याएं डिबगिंग के दौरान आती हैं। सब कुछ संकलित और ठीक है लिंक। लेकिन फिर जब मैं डीबगर के साथ एक फ़ंक्शन में कदम उठाने का प्रयास कर रहा हूं - यह गलत कोड लाइन दिखाता है।

दिलचस्प बात यह है कि सही रेखा संख्या और डीबगर शो के बीच का अंतर बिल्कुल 65536 है। इससे मुझे कुछ हस्ताक्षरित लघु ओवरफ़्लो पर संदेह होता है (लगभग सुनिश्चित हो जाता है)।

मुझे यह भी संदेह है कि यह एमएसवीसी में एक बग नहीं है। शायद यह डीबग सूचना प्रारूप की सीमा है। यही है, एमएसवीसी द्वारा उपयोग किए गए डीबग सूचना प्रारूप में लाइन नंबर 2-बाइट शॉर्ट्स के रूप में स्टोर किए जाते हैं।

क्या इस बारे में कुछ भी किया जा सकता है (विशाल फ़ाइल को कई छोटे में बदलने के अलावा)?

+4

एसक्लाइट समामेलन क्यों डीबग करें? एसक्लाइट का उचित वितरण है जो कई अलग-अलग फाइलें हैं। –

+0

यदि यह तोड़ा नहीं गया है, तो इसे समेकित न करें। –

उत्तर

8

एक एमएस मॉडरेटर के मुताबिक, यह केवल डीबगर के साथ एक ज्ञात मुद्दा है (संकलक इसे ठीक से संभालने के लिए लगता है जैसा आपने बताया)। कम स्रोत फ़ाइलों का उपयोग करने के अलावा स्पष्ट रूप से कोई कामकाज नहीं है। बहुत ही समान प्रश्न here

0

यदि आप प्रतीकात्मक डीबगिंग जानकारी के लिए प्रलेखन को देखते हैं, तो आपको लाइन संख्याओं के लिए उपयोग किए जाने वाले प्रकार को देखेंगे। उदाहरण के लिए, line और columnIDiaSession::findLinesByLinenum दोनों पैरामीटर DWORD के प्रकार हैं।

संपादित करें: @ वाल्डो बताते हैं, इसका मतलब यह नहीं है कि डीबगर बड़ी लाइन संख्याओं के साथ ठीक से काम करता है। तो आपको छोटी फाइलों का उपयोग करना होगा। यह दुर्भाग्यपूर्ण है कि ऐसी सीमा मौजूद है, लेकिन अगर वहां नहीं था तो भी मैं आपको अपने स्रोत को विभाजित करने की सिफारिश करता हूं।

+0

ठीक है, मुझे असहमत होने दें। यहां तक ​​कि तथ्य यह है कि IDWSession/IDialSession इंटरफेस को DWORD पैरामीटर के साथ घोषित किया गया है इसका मतलब यह नहीं है कि * वास्तविक * डीबग जानकारी DWORD लाइन संख्याओं के साथ संग्रहीत है। इंटरफ़ेस को केवल बड़ी लाइन संख्याओं का समर्थन करने के लिए डिज़ाइन किया जा सकता है, जरूरी नहीं कि यह लागू हो। – valdo

0

जब तक आप SQLite को संशोधित नहीं कर रहे हैं, आपको बस भरोसा करना चाहिए कि यह अपना काम कर रहा है। बिल्कुल कदम उठाने की जरूरत नहीं है। SQLite रिलीज से पहले परीक्षण की एक बड़ी बैटरी के माध्यम से चलाया जाता है।

+2

इस तरह के संपादकीयकरण शायद इस सवाल पर एक टिप्पणी होनी चाहिए। यह ओपी के प्रश्न, या इसमें निहित सामान्य समस्या का उत्तर देने का प्रयास नहीं करता है। –

0

क्या आपने इसके बजाय WinDBG का उपयोग करने में देखा है? यह बहुत सक्षम है क्योंकि विंडोज टीम ओ/एस को डीबग करने के लिए इसका इस्तेमाल करती है और वहां कुछ बायिग फाइलें हैं, या कम से कम जब मैंने पिछली बार देखा था।

+0

अभी तक नहीं। हालांकि, जैसा कि मैंने कहा था, यह डीबग जानकारी प्रारूप की सीमा प्रतीत होता है, डीबगर – valdo

1

ठीक है, जब मैं देखना चाहता था कि स्क्लाइट कैसे काम करता है, मैंने पिछले 60000 या तो लाइनें लीं, उन्हें दूसरी फ़ाइल में ले जाया गया और फिर # इसे शामिल किया गया। यह आसान था और मेरे लिए चाल थी। इसके अलावा, अगर आप ऐसा करते हैं, तो सावधान रहें #ifdef के अंदर विभाजित न करें।

+1

में कुछ बग नहीं है पोस्ट "(विशाल फ़ाइल को कई छोटे लोगों में काटने के अलावा)"। –

+0

पोस्ट वास्तव में यह कहता है, लेकिन यह सुझाव देना बिल्कुल ठीक है कि पोस्टर की पूर्व शर्त या धारणाओं को संशोधित किया जाना चाहिए। फ़ाइल को तीन हिस्सों में काटना (अब आवश्यक है कि समामेलन 2 * 2^16 लाइनों से अधिक हो) वास्तविक समस्या का एक सही समाधान है, जो प्रतीकात्मक डीबगर का उपयोग करके SQLite कोड में डीबग करना है। मुझे बस ऐसा करने की ज़रूरत है (क्यों? क्योंकि मुझे कारण पता लगाने की आवश्यकता है, SQLite दस्तावेज़ों में कहीं भी अनियंत्रित और कहीं भी मुझे अनियंत्रित किया गया है, मुझे पता चल सकता है कि एक निश्चित SQLite फ़ंक्शन विफल हो रहा था; मुझे 5 मिनट में पता चला)। –

0

किसी को भी फ़ाइलों के लिए गलत लाइन नंबर के साथ मुद्दों कर < 65536 लाइनों के लिए: मैंने पाया मेरी मुद्दा था की वजह से असंगत लाइन अंत स्रोत फ़ाइल में। 12 9 \r न्यूलाइन थे जहां बाकी की फाइल \r\n शैली थी। डीबगर लाइन और सही रेखा के बीच का अंतर भी 12 9 था।

संबंधित मुद्दे