在ARM上使用Qt的简单程序中的Segfault

Jér*_*eil 6 c++ qt arm segmentation-fault

我试图在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();
}
Run Code Online (Sandbox Code Playgroud)

show()事实上,在调用期间追加了段错误(由于一些调试),我意识到它在加载字体缓存期间会附加.而且,printf()在调用之后添加一个刚才localData()会使segfault消失...片刻!但是,当我关闭应用程序时,无论如何我都会得到段错误.

Qt/gui/text/qfont.cpp线路2615,加入printf()theFontCache()->loadData()暂时解决此问题:

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

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

return fontCache;
} 
Run Code Online (Sandbox Code Playgroud)

这是我的./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.

最后,我在segfault之前的strace:

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 +++
Run Code Online (Sandbox Code Playgroud)

在ARM系统上,我没有足够的空间来使用调试进行编译,这就是为什么它直接在发布时.

osg*_*sgx 3

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

\n\n

SEGV 位于 ../3rdparty/harfbuzz/src/harfbuzz-* (发布了两个回溯,并且都以 ../3rdparty/harfbuzz/src/harfbuzz-gsub.c

\n\n

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

\n\n

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

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

另外,strace 几乎没什么意思,而 gdb 的回溯却很有趣。

\n\n

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

\n

  • 最后,我们成功实现了我们想要的目标:小的库并且没有段错误。只需使用 -Os 选项进行编译即可:不再出现段错误,并且库的大小非常小!如果我今天有时间,我会尝试理解之前的错误,但现在它已经解决了......:) 谢谢! (2认同)