我正在尝试在 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/