क्यूटी में एक ब्रेकपाइंट करने के बाद, gdb कहते हैं: "त्रुटि स्मृति पता तक पहुँचने"

Question

मैं यहाँ एक बहुत ही सरल क्यूटी कार्यक्रम ने लिखा है:

int main(int argc, char* argv[]) 
{ 
    QApplication app(argc, argv); 

    QTableView table(&frame); 
    table.resize(100, 100); 
    table.show(); 

    return app.exec(); 
} 

और जब मैं जहां मेज हो जाता है एक ब्रेकपाइंट सेट करने का प्रयास क्लिक किया, मैं gdb से इस त्रुटि मिलती है:

(gdb) symbol-file /usr/lib/libQtGui.so.4.4.3.debug 
Load new symbol table from "/usr/lib/libQtGui.so.4.4.3.debug"? (y or n) y 
Reading symbols from /usr/lib/libQtGui.so.4.4.3.debug...done. 
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)' 
Breakpoint 1 at 0x5fc660: file .moc/release-shared/moc_qabstractitemview.cpp, line 313. 
(gdb) run 
Starting program: ./qt-test 
Warning: 
Cannot insert breakpoint 1. 
Error accessing memory address 0x5fc660: Input/output error. 

क्या किसी को पता है कि क्यों ब्रेकप्वाइंट सम्मिलित नहीं किया जा सकता है?

Answer 1

यदि आप ब्रेकपॉइंट सेट किए बिना मुख्य रूप से मुख्य रूप से तोड़ना चाहते हैं तो आप start कमांड का भी उपयोग कर सकते हैं।
आप उपयोग कर सकते हैं आप इस कार्यक्रम के लिए किसी भी तर्क प्रदान करने के लिए की जरूरत है:
start argument1 argument2

Answer 2

बाहरी प्रतीकों को लोड करने के लिए gdb कमांड symbol-file का उपयोग न करें। ब्रेकपॉइंट पते गलत होंगे क्योंकि उन्हें स्थानांतरित नहीं किया गया है।

इसके बजाय, main में एक ब्रेकपाइंट शब्दों में कहें, कार्यक्रम चलाने, और फिर अपने ब्रेकपाइंट सेट:

gdb ./program 
GNU gdb 6.8-debian blah blah blah 
(gdb) br main 
Breakpoint 1 at 0x80489c1 
(gdb) run 
Starting program: ./program 
Breakpoint 1, 0x080489c1 in main() 
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)' 
Breakpoint 2 at 0xb7d24664 
(gdb) continue 
Continuing. 

फिर अपने ब्रेकप्वाइंट ऐसा करने के।

उस पैरामीटर में पैरामीटर सूची निर्दिष्ट करना सुनिश्चित करें, जिसमें आप उन पैरामीटरों के नामों के बिना ब्रेकपॉइंट सेट करना चाहते हैं, बस उनके प्रकार।

Answer 3

वास्तविक त्रुटि:

Error accessing memory address 0x5fc660: Input/output error.

32/64 बिट उलझनों की वजह से हो सकता है। उदाहरण के लिए, जांचें कि आपने 32-बिट बाइनरी से 64-बिट प्रक्रिया आईडी के साथ संलग्न नहीं किया है, या इसके विपरीत।

Answer 4

मेरे लिए ठीक है मुझे यह मिला है जब mingw-w64 (मूल या क्रॉस कंपाइलर) के साथ निर्माण करते हैं। मुझे यकीन नहीं है कि सटीक समस्या क्या थी, लेकिन अगर मैं इसे gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 का उपयोग करके बना देता हूं तो यह डिबगबल बनाता है (अंत में) डिबग करने योग्य बनाता है। अन्यथा

(gdb) break main 
... 
(gdb) r 
... 
Cannot insert breakpoint 1. 
Cannot access memory at address 0x42445c 
<process basically hangs> 

संदेश 20 में से 1 9 बार, हालांकि कभी-कभी यह वास्तव में काम करता था (बहुत ही कम)।

जीडीबी 7.8.1 और 7.9.1 बनाए गए एक्सई को डीबग करने में सक्षम होना प्रतीत होता था। तो शायद यह जीडीबी का संस्करण नहीं है जो एक फर्क पड़ता है।

मेरा वर्तमान सिद्धांत/संदिग्ध या तो यह जीसीसी का संस्करण था या संभवतः कंपाइलर [?] (I686-492-posix-dwarf-rt_v3-rev1) के लिए sljl बनाम dwarf2 "पहलू" का संस्करण था, और जीसीसी 4.9.2 के कुछ रूपों के साथ संकलित क्रॉस या तो नहीं था)। जीसीसी के अन्य संस्करणों का प्रयास नहीं किया।

अद्यतन: नया जीसीसी (5.1.0) लेकिन संकलन पार करना मुझे अभी भी यह विफलता मिली है। में यह कारण केस एक निर्भरता लाइब्रेरी साबित हुआ है कि मेरा निर्माण (एफएफएमपीईजी) इस मामले में libgme (इस मामले में libgme) के साथ लिंक करके उपयोग कर रहा था जो कुछ गलती "साझा" प्रतीकों को निर्यात कर रहा है (जब मैं स्थिर निष्पादन योग्य बना रहा हूं) । इस वजह से, "साझा" ब्रेक बनाता है (https://trac.ffmpeg.org/ticket/282) और किसी भी तरह से यह gdb को भी खराब करता है।उदाहरण के लिए संभवतः एसडीएल के खिलाफ जोड़ने से आप यह भी कर सकते हैं। मेरा विचार संभवतः ld बग [?]