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

Question

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?

Solution 1

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

Solution 2

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.

Solution 3

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.

Solution 4

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 [?]

View more solutions

Comments

[Neil]

Thanks to pholklore in #gdb in irc.freenode.net for this answer.

[Neil]

You can also merely set a breakpoint on whatever you like without breaking on main() first, and gdb will ask you if you want to set a pending breakpoint. However, this way you can never be sure if that function actually exists, or if you made a typo. So the method illustrated in the answer is safer.

[froginvasion]

I have this problem, but I can't figure out how to make it use gdb correctly :(

[Nathan Kidd]

And bitness-mismatch isn't the problem?

[froginvasion]

Appears that I had to add the -g option to the makefile, and that fixed the problem. Found it somewhere on stackoverflow, but I don't know what it does.

[Gabriel Luci]

I'm running into this too while debugging VLC 3 (it doesn't happen with 4). You can't use start since that will automatically put a breakpoint on main. A work around is, when it halts at "Cannot access memory", tell it delete 1, then continue.

[tjwrona1992]

@froginvasion, -g compiles with debug symbols so it allows the debugger to see into the source code and provide useful feedback.