在Qt中设置断点后,gdb显示:“Error accessing memory address”

发布于 2024-07-20 22:34:12 字数 846 浏览 10 评论 0原文

我在这里编写了一个非常简单的 Qt 程序:

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.

有人知道吗为什么断点无法插入?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

拥有 2024-07-27 22:34:12

不要使用 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.

然后使断点发生。

请确保在要设置断点的函数中指定参数列表,不要指定这些参数的名称,而只指定其类型。

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.

归途 2024-07-27 22:34:12

实际错误:

访问内存地址 0x5fc660 时出错:输入/输出错误。

可能是由 32/64 位混合引起的。 例如,检查您是否未附加到具有 64 位进程 ID 的 32 位二进制文​​件,反之亦然。

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.

去了角落 2024-07-27 22:34:12

如果你想在 main 中自动中断而不设置断点,你也可以使用 start 命令。
如果您需要向程序提供任何参数,您可以使用:
开始参数1参数2

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

十雾 2024-07-27 22:34:12

对我来说好吧,我在使用 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 次消息中有 19 次是这样,尽管有时确实有效(很少)。

gdb 7.8.1和7.9.1似乎能够调试创建的exe。 所以可能不是 gdb 的版本造成了影响。

我目前的理论/怀疑是要么是 gcc 的版本,要么是编译器的 sljl 与 dwarf2“方面”[?](i686-492-posix-dwarf-rt_v3-rev1 不起作用,并且与某种形式的 gcc 4.9.2 也没有)。 没有尝试其他版本的 gcc。

更新:较新的 gcc (5.1.0) 但交叉编译我仍然遇到此失败。 这种情况的原因是我的构建(FFmpeg)通过链接(本例中为 libgme)使用了一个依赖库,该库导出了一些错误的“共享”符号(当我构建静态可执行文件)。 因此,“共享”构建了制动(https://trac.ffmpeg.org/ticket/282) 不知何故它也搞砸了 gdb。 例如,可能链接到 SDL 也可以对您执行此操作。 我的想法可能是一个 ld bug [?]

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文