我正在尝试在 ARM 系统上使用 Qt 4.7.4，以便在触摸屏上显示图形应用程序。

我的ARM卡内嵌了Linux系统；我们使用Linux framebuffer向屏幕发送信息，tslib+usbtouchscreen驱动获取触摸信息。

我能够交叉编译 Qt 并将库放在我的系统上。但是当我启动我的测试程序时，我每次都在同一时刻遇到段错误(没有逻辑原因)。

首先，这是我的测试程序(你可以看到它非常基础，没有理由出现段错误):

#include <QMessageBox> 
#include <QApplication>

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

    QMessageBox msgBox;
    msgBox.setText( "Hello world !" );
    msgBox.show();

    return app.exec();
}

段错误在 show() 调用期间追加，事实上(感谢一些调试)，我意识到它在加载字体缓存期间追加。此外，在调用 localData() 之后添加一个 printf() 会使段错误消失……片刻!但是，当我关闭应用程序时，无论如何都会出现段错误。

在Qt/gui/text/qfont.cpp第2615行，在theFontCache()->loadData()之后添加了一个printf() > 暂时解决问题:

QFontCache *QFontCache::instance()
{
    QFontCache *&fontCache = theFontCache()->localData();

    if (!fontCache) {
        fontCache = new QFontCache;
    }

return fontCache;
} 

这是我的 ./configure 命令行:

./configure -release -shared -fast -no-largefile -exceptions -no-accessibility -no-STL -no-qt3support -no-xmlpatterns -no-phonon -no-phonon-backend -no- svg -no-webkit -no-declarative -no-declarative-debug -no-glib -no-cups -no-scripttools -no-script -no-audio-backend -no-multimedia -no-nis -embedded arm -xplatform qws/linux-arm-str-g++ -little-endian -no-gfx-multiscreen -prefix/usr -qconfig mbxconfig -nomake examples -nomake demos -depths 16 -qt-mouse-tslib -confirm-license -opensource

我尝试使用-no-freetype 进行配置；没有改变。我也试过强制字体，但都没有成功。我也试过 echo 3 >/proc/cpu/alignment 但我没有发现任何对齐问题。我会尝试的一种解决方案:在没有编译器优化的情况下进行编译 - 但我显然没有更改正确的选项，因为它仍然使用 -O2 进行编译。我的 GCC 版本是 4.2.3。

最后，我在段错误之前的跟踪:

open("/dev/psaux", O_RDWR|O_NONBLOCK)   = -1 ENOENT (No such file or directory)
open("/dev/input/mice", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/tty0", O_RDWR)               = 8
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(8, KDGKBMODE, 0x1a21c)            = 0
ioctl(8, KDSKBMODE, 0x2)                = 0
ioctl(8, SNDCTL_TMR_START or TCSETS, {B0 -opost -isig -icanon -echo ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
rt_sigaction(SIGUSR1, {0x40bb3d68, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {0x40bb3d68, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
ioctl(8, VIDIOC_RESERVED or VT_GETMODE, 0xbedbb598) = 0
ioctl(8, VIDIOC_ENUM_FMT or VT_SETMODE, 0xbedbb598) = 0
ioctl(8, VT_GETSTATE, 0xbedbb588)       = 0
gettimeofday({1321521340, 447374}, NULL) = 0
brk(0x1d000)                            = 0x1d000
open("/proc/self/auxv", O_RDONLY)       = 9
fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
read(9, "\20\0\0\0\3\0\0\0\6\0\0\0\0\20\0\0\21\0\0\0d\0\0\0\3\0\0\0004\200\0\0\4"..., 256) = 128
read(9, ""..., 256)                     = 0
close(9)                                = 0
write(4, "\0"..., 1)                    = 1
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {SIG_DFL, [SEGV], SA_RESTART|0x4000000}, {0x40142d48, [SEGV], SA_RESTART|0x4000000}, 8) = 0
ioctl(8, KDSKBMODE, 0x3)                = 0
ioctl(8, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
close(8)                                = 0
ioctl(7, KDSETMODE, 0)                  = 0
write(7, "\33[9;15]\33[?33h\33[?25h\33[?0c\0"..., 25) = 25
close(7)                                = 0
kill(29810, SIGSEGV)                    = 0
sigreturn()                             = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

在 ARM 系统上，我没有足够的空间来编译调试，所以它直接在发布中。

最佳答案

根据某些页面中链接的错误报告 https://bugreports.qt.io/browse/QTBUG-13441

SEGV 位于 ../3rdparty/harfbuzz/src/harfbuzz-*(发布了两个回溯，均以 ../3rdparty/harfbuzz/src/harfbuzz-gsub.c 结尾)

因此，您应该尝试使用 -g -O2 和 -g -O0 仅重建这个第 3 方库“harfbuzz”。因为它是 3rdparty，它有自己的构建系统，我认为它可以很容易地改变。

当你证明你的错误也在这个库中并且它依赖于 -O2/-O0 标志时，你可以:

• 找到 SEGV 的确切位置并从 GDB 进行回溯；
• 从 GDB 和 info reg 执行 x/i $pc 以查看 SEGV 数据在哪里以及操作是什么。
• 找到一个有 bug 的确切文件/函数，并在 -O0 和 -O2 版本之间进行反汇编函数的差异
• 在这里或在 QT bugtracker 中发布反汇编
• 在 harfbuzz 或 GCC 上提交错误

此外，strace 几乎没有意义，而 gdb 的回溯很有趣。

来自 Jérémy Dutheil 的更新:“只需使用 -Os 选项进行编译:不再有段错误，并且库的大小非常小!”——因此，如果 O2 失败，也应该尝试 O1 和/或 Os。

关于c++ - 在 ARM 上使用 Qt 的简单程序中的段错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8164959/