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

前端 未结 4 921
遥遥无期
遥遥无期 2020-12-11 06:01

I wrote a very simple Qt program here:

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

    QTableView table(&frame         


        
相关标签:
4条回答
  • 2020-12-11 06:20

    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

    0 讨论(0)
  • 2020-12-11 06:20

    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.

    0 讨论(0)
  • 2020-12-11 06:23

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

    0 讨论(0)
  • 2020-12-11 06:37

    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.

    0 讨论(0)
提交回复
热议问题