前言

  本篇就适合代码崩溃的方法，可以定位到代码崩溃原因，测试Demo。

使用gdb定位Qt的release（国产麒麟系统）

步骤一：新建立一个简单的应用

步骤二：造崩溃代码

DumpWidget::DumpWidget(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::DumpWidget),
    _pTimer(0)
{
    ui->setupUi(this);
    LOG << _pTimer;
#if 0
    if(!_pTimer)
    {
        _pTimer = new QTimer(this);
    }
#endif
    LOG << _pTimer;
    connect(_pTimer, SIGNAL(timeout()), this, SLOT(slot_timeout()));
    LOG << _pTimer;
    _pTimer->setInterval(1000);
LOG << _pTimer;
}

步骤三：运行崩溃

步骤四：为了更好的看到效果，加3s延迟

步骤五：定位到coredump文件

  默认目录/var/lib/system/coredump

  没有，怎么弄国产麒麟系统都不会有得，因为生成在/tmp目录下了，查看“入坑一”：

步骤六：定位位置

  因为Demo堆栈不多，就一层，所以很容易定位，而实际程序可能达到几兆，几十兆，几百兆甚至1~2个GB。

  这里为了再次确认，gdb调试release版本没有添加任何额外pro语句尝试了一次：

  （注意：不知道ubuntu是否这样可以，目前通过其他方法都需要加g或者qmake，这个持保留意见，后续进一步了解再补充了）

  （注意：后续通过“模拟实战”，发现能定位给到错误的函数，但是没有行号。）

模拟实战

  先加了一句代码：

  运行崩溃：

  定位coredump文件：

  然后使用gdb的方法：

  定位不到，这个时候再按一下回车：

（注意：发现能定位给到错误的函数，但是没有行号。）

现场另外一种情况

  这个情况结合很早之前烤机的bug，QDateTime::currentDataTime().toString(“yyyy-MM-dd hh:mm:ss:zzz”)出现乱码，跑起来偶尔出现乱码，就会一直乱码，启动非乱码则非乱码，这个是qt和麒麟的兼容性问题，后续再议。

入坑

入坑一：没有生成coredump文件

问题

  默认目录/var/lib/system/coredump，目录为空，试了其他方法也不行。

原理

  默认生成在了/tmp目录下了，而不是coredump目录下。

  使用其他ulimit -c unlimited也不会，国产麒麟系统是对系统很多默认配置和路径做了强制修改的。

解决

  默认生成在了/tmp目录下了