QT UI线程错误(Backtrace stopped: previous frame identical to this frame (corrupt stack?))

最新推荐文章于 2025-05-18 12:28:29 发布
原创 最新推荐文章于 2025-05-18 12:28:29 发布 · 4.8k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#qt #ui主线程

在Qt程序中出现Backtrace stopped错误致程序崩溃，原因是在QT线程接收消息后刷新主界面，该动作不在主线程进行。修改方法是将界面操作放在主界面类的信号槽函数中，由消息线程接收消息后发信号通知主界面，问题得以解决。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1. 简述

在qt程序中出现了Backtrace stopped: previous frame identical to this frame (corrupt stack?)错误，导致程序崩溃，gdb查看如下图：
在这里插入图片描述

2. 原因分析

自己是在一个QT线程中接收别的线程的消息，接收到消息后刷新主界面，所以刷新主界面的动作并不是在主线程做的，这有可能会导致Qt程序发生错误，后面做出了修改，界面的操作放在了主界面类的信号槽函数中，消息线程接收到消息后发送信号来通知主界面，由此解决了此问题，关于这个问题的具体原因可以参考以下博客：

https://blog.csdn.net/qq_40732350/article/details/102873901

http://www.360doc.com/content/19/1212/13/7551_879262313.shtml

函数调用栈帧回溯
sunshineywz的博客
05-15 1641
本文以Linux + arm64平台上的测试程序为例，讲解函数调用的栈帧回溯基本原理。 1. Overview 2. Demo 2.1 堆栈 Thread 9 (LWP 1386): #0 0x0000007faec8fd28 in ?? () #1 0x0000007faf208190 in osal_memcpy (dst=0x7f0e6cc727, src=0x7f08024180, count=32477) at vdi/linux/vdi_osal.c:335 #2 0x0000007fa
GDB调试之栈指针破坏
明何
09-14 1万+
记录一个因为栈上非法操作导致栈指针被破坏的例子。 源代码如下： #include #include char name[] = "aabbccddeeffgghhiijjkkllmmnnooppqqrrsstt"; void fun() { char buf[3]; strcpy(buf, name); } int main(void) { fun();
gdb 环境问题：Backtrace stopped: previous frame identical to this frame (corrupt stack?)
点滴路程
04-06 7643
若您与我遇到了相似的问题，不妨试试将以上三个库重新编译一份，替换成具备debug_info,以及not stripped。若依旧不能解决，坚决一点，就是供应商的问题，让他们去解决。若我的内容对您有所帮助，还请关注我的公众号。不定期分享干活,剖析案例，也可以一起讨论分享。踩完您工作中的所有坑并分享给您，让你的工作无bug，人生尽是坦途。
Backtrace stopped: previous frame identical to this frame (corrupt stack?)错误
u010949023的博客
07-27 2万+
gdb调试出现这个错误. 这个一般是内存出现错误，我遇到的是，cv::Mat image从vio传给pose_graph,但是我没有clone，也就是vio和pose_graph使用的是同一片内存，而vio又在改变这片内存，导致pose_graph使用时出现错误。 ...
QT线程引发Backtrace stopped: previous frame identical to this frame (corrupt stack?)
热门推荐
QtHalcon
11-02 2万+
1.简介 由于在主线程以及多线程中对GUI进行绘画刷新，导致了出现莫名其妙的问题。例如： 1、在程序运行了一段时间后，程序UI不会刷新，运行的获取当前程序时间的程序一直在运行，但是不会将当前时间显示到界面上，其他后台显示信息，一切正常。经过鼠标的再次点击，程序会暂时恢复正常或者是直接程序终止退出。 2、出现QT gui界面假死现象（即是后台显示程序运行正常，结果是界面一直不刷新，并且top...
利用gdb定位线程栈被破坏场景: Backtrace stopped
pkyang2004的博客
05-18 1427
在调试RK3399模块时，开发人员遇到程序启动时小概率异常的问题。使用gdb调试时，发现主线程被挂死，且线程栈信息被破坏，无法完整查看。通过gdb的x命令分析寄存器信息和内存信息，最终定位到问题根源：公共日志函数Kb_LogStr中的日志长度判断不足，导致vfprintf内存溢出，进而引发系统异常和死锁。解决方案包括修复Kb_LogStr中的日志长度判断问题，并修改信号量处理回调函数ITP_Handle_Sig中的日志调用逻辑，避免死锁。
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
10-20
"Backtrace stopped: previous frame identical to this frame (corrupt stack?)"是一个gdb调试错误信息，它表示在调试过程中出现了堆栈损坏的情况，即调用栈中的前一帧与当前帧相同，导致调用栈无法继续回溯。这种...
thread apply all bt Thread 13 (Thread 0xab8f9380 (LWP 1787) "FileInfoThread"): #0 0xb5aa15e8 in ?? () from /lib/libc.so.6 #1 0xb5aa4d48 in pthread_cond_wait () from /lib/libc.so.6 #2 0xb5ddf38c in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 #3 0xb5ddf4d8 in QWaitCondition::wait(QMutex*, unsigned long) () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 #4 0xad03eea8 in ?? () from /home/txj/ut0712/qt5.12/qml/Qt/labs/folderlistmodel/libqmlfolderlistmodelplugin.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 12 (Thread 0xae1fc380 (LWP 1752) "ptl_lgprov"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 11 (Thread 0xae9fd380 (LWP 1751) "ucf_thread_sfq"): #0 0xb5b1a20c in syscall () from /lib/libc.so.6 #1 0xb5ddaefc in ?? () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 10 (Thread 0xaf1fe380 (LWP 1750) "ucf_thread_eng"): #0 0xb5adca7c in __clock_nanosleep_time64 () from /lib/libc.so.6 #1 0xb5aa10bc in ?? () from /lib/libc.so.6 #2 0xb62660ec in ?? () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 9 (Thread 0xaf9ff380 (LWP 1749) "ucf_thread_tcp"): #0 0xb5adca7c in __clock_nanosleep_time64 () from /lib/libc.so.6 #1 0xb5aa10bc in ?? () from /lib/libc.so.6 #2 0xb62660ec in ?? () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 8 (Thread 0xb03ff380 (LWP 1748) "ucf_thread_chnl"): #0 0xb5adca7c in __clock_nanosleep_time64 () from /lib/libc.so.6 #1 0xb5aa10bc in ?? () from /lib/libc.so.6 #2 0xb62660ec in ?? () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 7 (Thread 0xb0dfe380 (LWP 1747) "UIPDataSource"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 6 (Thread 0xb15ff380 (LWP 1746) "UCF_Tick"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 5 (Thread 0xb21bd380 (LWP 1745) "UIPComm_Rx"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 0xb29be380 (LWP 1744) "UIPComm_Tx"): #0 0xb5b1a20c in syscall () from /lib/libc.so.6 #1 0xb5ddaefc in ?? () from /home/txj/ut0712/UI/..//qt5.12/lib/libQt5Core.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 0xb3bff380 (LWP 1743) "QQmlThread"): --Type <RET> for more, q to quit, c to continue without paging-- #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 0xb4600380 (LWP 1742) "QEvdevTouchScre"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 0xb6fb7220 (LWP 1741) "UI_Loader"): #0 0xb5b11218 in poll () from /lib/libc.so.6 #1 0xb58e71d0 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) (gdb)
07-30
我们正在处理一个关于如何分析GDB输出的多线程堆栈信息以定位线程阻塞或死锁问题的问题。根据用户提供的引用，特别是引用[1][2][3][4][5]，我们可以总结出以下关键点： 1. 使用`pstack`或`gdb`的`thread apply all ...
(gdb) bt #0 0x76f12b74 in __clone () from /lib/ld-musl-arm.so.1 #1 0x76f136ac in ?? () from /lib/ld-musl-arm.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
最新发布
08-07
我们正在处理一个关于GDB调试中出现的堆栈跟踪问题，特别是涉及`__clone`和musl libc在ARM架构上的错误，以及栈损坏（stack corruption）的问题。根据用户提供的引用，我们可以分析如下： 引用[1]给出了一个GDB的...
bt full #0 0x00009d00 in pthread_mutex_lock () No symbol table info available. #1 0x0002c050 in OsalDequeue () No symbol table info available. #2 0x0000f734 in PackToHostTask () No symbol table info available. #3 0x2ab50b60 in ?? () from /lib/libpthread.so.0 No symbol table info available. #4 0x2ab50b60 in ?? () from /lib/libpthread.so.0 No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?)
05-07
(gdb) symbol-file /path/to/debug_binary # 手动指定带符号的可执行文件 (gdb) sharedlibrary # 重新加载所有动态库符号 ``` 2. **使用`debuginfod`自动获取符号** ```bash export DEBUGINFOD_URLS=...
嵌入式Linux应用崩溃调试-难以追踪的栈信息
飞翔de刺猬
06-04 5954
在进行嵌入式Linux应用程序开发时，经常会用到gdb对崩溃日志进行分析，一般情况下，可以直接定位到崩溃的位置。但有时分析core文件时，却看不到有意义的崩溃栈，这时问题就有点复杂了，出现这种现象的原因可能有这么几个： 应用程序在编译时没有指定-g选项，导致可执行程序没有调试信息。 应用程序所依赖的动态库和静态库没有调试信息。 应用程序的运行时环境没有调试信息，比如libc等。 嵌入式Linux系统应用程序运行时环境和交叉编译工具链的运行时环境版本不一致，比如，嵌入式Linux环境中所使用的libc库和交
gdb调试coredump文件，函数名称是问号
xqhrs232的专栏
10-19 5000
原文地址::http://blog.csdn.net/wannew/article/details/17736013 google key: gdb问号 http://blog.csdn.net/yudingding6197/article/details/5528989 今天总算解决了一个大的bug,爽！ 我的程序crash,有了coredum
gdb 调试COREDUMP方法
一杯咖啡的专栏
09-26 7163
COREDUMP是NE进程的内存现场， 其中包含了出现NE时的局部变量， 全局变量等信息， 这些信息有助于我们结合代码分析问题。 gdb路径 ：prebuilts/gdb/linux-x86/bin/gdb 建议在源码根目录下执行， 可以通过gdb查看源码和打印变量成员. 常用指令说明帮助指令cmd 为对应命令， 会显示该命令所支持的参数和功能。 1.help [cmd] cmd 为对应命令...
Linux程序内存越界定位分析总结
qq_15762939的博客
01-30 5287
问题描述：最近在工作中遇到这样一个奇葩问题，程序里面需要使用到一个.so库，同一份源码用我的电脑编译出来的库放到程序使用出现各种异常问题，其他同事编译出来的没啥问题。刚开始以为是编的方式有问题，思来想去发现并不是，GNU也不可能无知到换个系统编的代码就不行了。后面定位才发现是库里面的一个数组踩到其他变量的地址了。 问题1：定位踩内存的地方 现象为触发某个业务条件，会导致程序其他业务运行不正常，异...
内存问题，使用核心转储的方法找Bug，GDB+Coredump分析
weixin_46777776的博客
04-11 494
发现有两种方法，一种是在makefile文件中取消Strip的优化，这个Strip的优化会导致没有符号表，取消掉之后，发现文件大小和使用Strip的大小一样，使用objdump查看后，确实存在符号表这些信息。设置ulimit -c unlimited，使得程序崩溃，产生core文件，core文件没有设置就在当前程序目录中，core。产生core文件后，我使用编译链里面的gdb + 源程序 + core 文件打开。接着解决栈崩溃没有符号表的问题。但是依然显示上面这个问题。
linux中非法内存,Linux下数组非法访问导致内存破坏 —— 引发segmentation fault的原因...
weixin_39765869的博客
05-07 312
2012-02-05 wcdj1, 调试时必需的栈知识2, 数组非法访问导致内存破坏调试时必需的栈知识栈(stack)是程序存放数据的内存区域之一，其特征是LIFO(Last In First Out, 后进先出)式数据结构，即后放进的数据最先备取出。向栈中存储数据的操作称为PUSH(压入)，从栈中取出数据称为POP(弹出)。在保存动态分配的自动变量时要使用栈。此外在函数调用时，栈还用于传递函数参...
backtrace of probe function
tuyerv的博客
06-29 261
Breakpoint 1, smc_drv_probe (pdev=0xcb828608) at drivers/net/smc91x.c:21282128 struct smc91x_platdata *pd = pdev->dev.platform_data;(gdb) bt#0 smc_drv_probe (pdev=0xcb828608) at driv...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值