2010-07-19 15 views
9

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

(gdb) thread apply all where 

मुझे रूप में आश्चर्यजनक बेकार जानकारी दे रहा है:

#0 0x004ab410 in __kernel_vsyscall() 
#1 0x05268996 in nanosleep() from /lib/libc.so.6 
#2 0x052a215c in usleep() from /lib/libc.so.6 
#3 0x082ee313 in frame_clock_frame_end (clock=0xb4bfd2f8) 
    at frame_clock.c:143 
#4 0x003a349a in ??() 
#5 0x00b5cfde in thread_proxy() 
    from /cets_development_libraries/install/lib/libboost_thread-gcc41-mt-1_38.so.1.38.0 
#6 0x02c1f5ab in start_thread() from /lib/libpthread.so.0 
#7 0x052a8cfe in clone() from /lib/libc.so.6 
9 प्रक्रियाओं की

, 7 या तो मेरे लगभग ठीक है कि उत्पादन दे रहे हैं, और पिछले 2 प्रतिसाद नहीं के बारे में जानकारी वास्तव में बहुत अधिक सहायक नहीं है (कॉल स्टैक के बहुत नीचे के कार्यों को पहचानने योग्य नाम हैं, लेकिन हाल ही में # 0- # 4 कार्य पहचानने योग्य नहीं हैं)।

(gdb) gdb 
(gdb) gdb attach <processid> 
(gdb) thread apply all 'XML_File_Data::XML_File_Data()' 

और (के बाद ब्रेकप्वाइंट मारा जाता है)

(gdb) thread apply all where 

किसी भी अनुभवी डिबगर मुझे मैं गलत है या क्या क्या कर रहा हूँ पर कुछ संकेत की पेशकश कर सकते हैं:

यह वही है मैं अब तक किया है आमतौर पर इस स्थिति में किया जाता है?

चीयर्स, चार्ली

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

उत्तर

14

आप आदेश का उपयोग कर सकते हैं धागा या जानकारी धागे वर्तमान धागा संख्या पता लगाने के लिए के बाद ब्रेकप्वाइंट gdb धागा संख्या के बाईं ओर

(gdb) thread 
[Current thread is 1 (Thread 0xb790d6c0 (LWP 2519))] 
(gdb) 

(gdb) info threads 
    17 Thread 0xb789cb90 (LWP 2536) 0xb7fc6402 in __kernel_vsyscall() 
    16 Thread 0xb769bb90 (LWP 2537) 0xb7fc6402 in __kernel_vsyscall() 
    15 Thread 0xb749ab90 (LWP 2543) 0xb7fc6402 in __kernel_vsyscall() 
    14 Thread 0xb7282b90 (LWP 2544) 0xb7fc6402 in __kernel_vsyscall() 
    13 Thread 0xb5827b90 (LWP 2707) 0xb7fc6402 in __kernel_vsyscall() 
    12 Thread 0xb5626b90 (LWP 2708) 0xb7fc6402 in __kernel_vsyscall() 
    11 Thread 0xb5425b90 (LWP 2709) 0xb7fc6402 in __kernel_vsyscall() 
    10 Thread 0xb5161b90 (LWP 2713) 0xb7fc6402 in __kernel_vsyscall() 
    9 Thread 0xb4ef9b90 (LWP 2715) 0xb7fc6402 in __kernel_vsyscall() 
    8 Thread 0xb4af7b90 (LWP 2717) 0xb7fc6402 in __kernel_vsyscall() 
    7 Thread 0xb46ffb90 (LWP 2718) 0xb7fc6402 in __kernel_vsyscall() 
    6 Thread 0xb44feb90 (LWP 2726) 0xb7fc6402 in __kernel_vsyscall() 
    5 Thread 0xb42fdb90 (LWP 2847) 0xb7fc6402 in __kernel_vsyscall() 
    4 Thread 0xb40fcb90 (LWP 2848) 0xb7fc6402 in __kernel_vsyscall() 
    3 Thread 0xb3efbb90 (LWP 2849) 0xb7fc6402 in __kernel_vsyscall() 
    2 Thread 0xb3cfab90 (LWP 2850) 0xb7fc6402 in __kernel_vsyscall() 
* 1 Thread 0xb790d6c0 (LWP 2519) 0xb7fc6402 in __kernel_vsyscall() 
(gdb) 

तारांकन `* 'हिट वर्तमान धागा इंगित करता है । here देखें।

14

मुझे लगता है अपने आप को यह सब समय कर:

> t a a f 

लघु के लिए:

> thread apply all frame 
बेशक

, अन्य वेरिएंट संभव हो रहे हैं:

> t a a bt 3 

कौन सा नीचे 3 प्रिंट प्रत्येक थ्रेड के ढेर के फ्रेम। (आप स्टैक के शीर्ष एन फ्रेम प्राप्त करने के लिए नकारात्मक संख्याओं का भी उपयोग कर सकते हैं)