CODEWITHSUNDEEP
debuggingqtqt4gdbbreakpoints
Neil
Neil

Reputation: 25825

After setting a breakpoint in Qt, gdb says: "Error accessing memory address"

I wrote a very simple Qt program here:

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

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

    return app.exec();
}

And when I try to set a breakpoint where the table gets clicked, I get this error from 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.

Does anyone know why the breakpoint can't be inserted?

Upvotes: 8

Views: 21089

Answers (4)

rogerdpack
rogerdpack

Reputation: 66741

OK for me I got this when building with mingw-w64 (native or cross compiler). I'm not sure what the exact problem was, but if I build it using gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 then it creates (finally) debuggable builds. Otherwise 

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

message 19 times out of 20, though sometimes it did actually work (very rarely).

gdb 7.8.1 and 7.9.1 seemed to be able to debug the created exe. So it's probably not the version of gdb that makes a difference.

My current theory/suspect is either it was the version of gcc or possibly the sljl vs. dwarf2 "aspect" to the compiler [?] (i686-492-posix-dwarf-rt_v3-rev1 didn't work, and cross compiling with some form of gcc 4.9.2 didn't either). Didn't try other versions of gcc.

update: newer gcc (5.1.0) but cross compiling I still got this failure. The cause in this case turned out to be a dependency library that my build (FFmpeg) was using by linking against (libgme in this case) which is exporting a few errant "shared" symbols (when I am building a static executable). Because of this, "shared" builds brake (https://trac.ffmpeg.org/ticket/282) and somehow it screws up gdb as well. For instance possibly linking against SDL can do this to you as well. My thought is possibly an ld bug [?]

Upvotes: 2

Nathan Kidd
Nathan Kidd

Reputation: 2959

The actual error:

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

Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.

Upvotes: 4

Andy
Andy

Reputation: 3854

If you want to automatically break in main without setting a breakpoint you can also use the start command.
If you need to provide any arguments to the program you can use:
start argument1 argument2

Upvotes: 2

Neil
Neil

Reputation: 25825

Don't use the gdb command symbol-file to load external symbols. The breakpoint addresses will be wrong since they're not relocated.

Instead, put a breakpoint in main, run the program, and then set your breakpoint:

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.

Then make your breakpoint happen.

Make sure to specify the parameter list in the function you want to set a breakpoint in, without the names of those parameters, just their types.

Upvotes: 12

Related Questions