QSqlQuery 可以让你的程序崩溃

linux平台下。

一个程序总是运行个两三天,或者一两天的时候突然崩溃了,以前发过一个讨论但是也没找到解决办法,使用的数据库是SQLITE

使用GDB跟踪程序,结果找到了崩溃的地方却显示栈被破坏显示不出调用的具体方法,运行了好几次都是这样。定位到了 __memmove_ssse3在libc里面。

为了恢复完整的栈信息在国外大牛那里找来两句话

(gdb)set $pc=*(void **)$esp
(gdb)set $esp=$esp+4

执行完就可以查看堆栈了(32位平台)。注意这个不能由core文件进入gdb,必须只能是运行着的程序崩溃被gdb捕捉到才行。

查看堆栈看到了出错了地点

void xxx::execsql(QString sql)
{
   QMutexLocker locker(&this->readlock);
   QSqlQuery query(this->database);  //运行到这里崩溃了
   if(query.exec(sql)) ...
   ...
}

程序多线程向数据库插入数据,尽管我已经很小心地处理线程了,但是运行到未来某一时刻还是会崩溃。

直到我又等了两三天测试,测试要看机缘啊,有时候它完全正常工作啊,有时候会崩溃。 结果就是这个方法执行的很频繁,而且同一时刻只有一个线程在访问数据库,但是这句话会崩溃。原因我还没有具体知道,我的推测: 因为在堆栈里面显示QSqlQuery里有数据库资源的申请与释放,在申请资源的时候出错了直接崩溃了。

然后我就将query提升为类成员,代码变成如下了。

void xxx::execsql(QString sql)
{
   QMutexLocker locker(&this->readlock);
   if(this->query->exec(sql))
   ...
   ...
}

再运行,好了。

这个问题仅在多线程(即使加了锁)且操作数据库频繁的时候才会出现,其他情况下则运行良好。

时间: 2025-01-01 10:34:21

QSqlQuery 可以让你的程序崩溃的相关文章

升级iOS10之后调用摄像头/麦克风等硬件程序崩溃闪退的问题

在升级到iOS10之后, 开发过程中难免会遇到很多的坑, 下面是一些常见的坑, 我做了一些整理, 希望对大家开发有帮助: &1. 调用视频,摄像头, 麦克风,等硬件程序崩溃闪退的问题: 要注意的问题 iOS10 对隐私权限的管理更为严格 ,比如访问的摄像头.麦克风等硬件,都需要提前请求应用权限.允许后才可以使用,或者现在要提前声明,虽然以往要求不严格. 在iOS10中比如遇到崩溃,日志: *This app has crashed because it attempted to access p

未捕获异常,现实程序崩溃闪退

碰到程序崩溃时,闪退效果,不会提示"xxx程序异常,退出程序".这样的效果就要使用到未捕获异常来实现,这里记录了我的一个写法.其实原理很简单,设置程序的未捕获异常监听,实现监听的一个方法,在该方法中现实直接没有提示的退出程序. 捕获异常工具类 package com.tdh.http; import java.io.PrintWriter; import java.io.StringWriter; import java.lang.Thread.UncaughtExceptionHan

WinCE应用程序崩溃提示框的处理

WinCE的开发人员和WinCE设备的用户应该对下面这两个错误不陌生,"Application encountered a serious error and must shut down"和"出现严重错误,必须被关闭".WinCE下应用程序崩溃就会弹出这样的提示框,还会发出警告的声音.如果是在车里,那声音还是很刺耳的.不过,说实在的,开发人员看到这个可以接受,程序都是会出BUG的.但用户经常看到就不太应该了.我们应该完善代码,尽可能降低出现应用程序崩溃的概率. 很

Linux 使用core file文件快速定位程序崩溃代码行

问题描述 如果在 Linux下编写程序,有时运行程序的时候程序崩溃,比如说只有"Segmentation fault (core dumped) ",程序比较小的话,还可以一行一行查看,但是如果程序很庞大,一行行查询,效率非常低下.Linux下可以程序可以生成core file文件,借助gdb很快能定位到崩溃的代码行. 解决方案 测试程序,除零操作,程序会崩溃 /* test.c */ #include <stdio.h> #include <stdlib.h>

【转】程序崩溃时自动记录minidump的c++类

原帖:程序崩溃时自动记录minidump的c++类 封装了一个C++类,当程序意外崩溃的时候可以生成dump文件,以便确定错误原因. 头文件: //crash_dumper_w32.h #ifndef _CRASH_DUMPER_H_ #define _CRASH_DUMPER_H_ #include <windows.h> class CrashDumper { public: CrashDumper(); ~CrashDumper(); static bool _PlaceHolder()

dll的内存申请和释放问题--Debug程序正常而Release程序崩溃

C++编程中经常遇到这样的需求:主函数需要调用一个功能函数并返回一块大小不定的存储着处理结果的内存,这时容易想到两种选择:一是使用vector类型的引用作为形参,无需考虑内存问题:二是使用指针,在主函数中定义指针,而在功能函数中申请内存.这两种处理方法本来没有问题,但如果功能函数是dll中的函数,那么就需要十分小心了. 下面我们直接上结论: 1. 如果使用vector类型作为dll库函数的形参,那么一定不能在库函数中更改vector的大小,而只能更改vector的内容: 2. 如果使用指针,且在

结合程序崩溃后的core文件分析bug

结合程序崩溃后的core文件分析bug 引言 在<I/O的效率比较>中,我们在修改图1程序的BUF_SIZE为8388608时,运行程序出现崩溃,如下图1: 图1. 段错误 一般而言,导致程序段错误的原因如下: 内存访问出错,这类问题的典型代表就是数组越界. 非法内存访问,出现这类问题主要是程序试图访问内核段内存而产生的错误. 栈溢出, Linux默认给一个进程分配的栈空间大小为8M,因此你的数组开得过大的话会出现这种问题. 首先我们先看一下系统默认分配的资源: $ ulimit -acore

随机颜色,使程序崩溃提醒

// 随机颜色 - (UIColor*)randomColor { CGFloat r = arc4random() % 256 / 255.0; CGFloat g = arc4random() % 256 / 255.0; CGFloat b = arc4random() % 256 / 255.0; return [UIColor colorWithRed:r green:g blue:b alpha:1]; } 调用:[[self randomColor] set]; 使程序崩溃提醒 i

没有网络连接时程序崩溃问题以及动态加载图片问题已解决

经过进一步的研究我们把没有网络连接时程序崩溃的大bug修改掉了,如果是程序打开时没有网络连接会弹出网络连接失败的 对话框,如果在程序运行过程中出现网络异常,在需要连接服务器的时候会抛出网络连接异常: 第二个是动态加载图片问题的解决,我们通过查资料找到方法把bitmap加载进gradeview,用一个线程每次加载一个图片然后 把对应课程位置的图标替换掉,最后实现了动态刷新网络图片. 这两个问题修改过之后,我们的程序中基本的功能已经完善了,最后我们会对UI进行小的修改,让程序更加完美. 下面是新的安