Geek Answers Handbook

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 that the table clicks on, 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 a breakpoint cannot be inserted?

+5
debugging qt qt4 breakpoints gdb
source share
4 answers

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

+2
source share

Do not use the gdb symbol-file command to load external characters. Breakpoint addresses will be incorrect because they do not move.

Instead, set a breakpoint in main , run the program, and then set a 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.

Be sure to specify a list of parameters in the function in which you want to set a breakpoint, without names of these parameters, only their types.

+11
source share

Actual error:

Error accessing memory address 0x5fc660: I / O error.

It can be caused by 32/64 bit mixes. Check, for example, that you did not connect to a 32-bit binary with a 64-bit process identifier, or vice versa.

+4
source share

Ok for me. I got this when creating using mingw-w64 (native or cross-compiler). I'm not sure what the problem is, but if I build it using gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0, then it creates (finally) debugged assemblies. 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, although sometimes it really worked (very rarely).

gdb 7.8.1 and 7.9.1 seemed to be able to debug the exe created. So this is probably not the gdb version that matters.

My current theory / suspect is either the gcc version, or perhaps sljl vs. dwarf2 "aspect" for the compiler [?] (i686-492-posix-dwarf-rt_v3-rev1 does not work, and cross-compilation with some form of gcc 4.9.2 was also not). Did not try to use other versions of gcc.

update: new gcc (5.1.0), but cross-compiling. I still got this glitch. The reason in this case was the dependency library that my assembly (FFmpeg) used, linking it (in this case libgme), which exports several erroneous "common" characters (when I create a static executable). Because of this, the "general" one creates a brake ( https://trac.ffmpeg.org/ticket/282 ), and somehow it also spins gdb. For example, perhaps linking to the SDL can do this with you. My thought is probably the error ld [?]

+1
source share

More articles:


All Articles