All geek questions in one place

Segfault in a simple program using Qt on ARM

I am trying to use Qt 4.7.4 on an ARM system to display a graphical application on a touch screen.

My ARM card implements a Linux system; we use the Linux framebuffer to send information to the screen and the tslib + usbtouchscreen drivers to get touch information.

I can cross-compile Qt and put the library on my system. But when I run my test program, I get segfault every time at the same moment (for no logical reason).

To get started, here is my test program (you can see it is very simple, for no reason segfault):

#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(); }

Segfault is added during the show() call, in fact (thanks to some debugging), I realized that it is added during font cache loading. Moreover, adding a printf() immediately after calling localData() causes segfault to disappear ... for a moment! However, when I close the application, I still get segfault.

On line Qt/gui/text/qfont.cpp line 2615, adding printf() after theFontCache()->loadData() temporarily resolves the problem:

 QFontCache *QFontCache::instance() { QFontCache *&fontCache = theFontCache()->localData(); if (!fontCache) { fontCache = new QFontCache; } return fontCache; }

Here is my ./configure line:

./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

I tried to configure using -no-freetype ; Nothing changed. I also tried to force the font, but did not achieve anything. I also tried echo 3 > /proc/cpu/alignment , but I did not find problems with alignment this way. One solution I would try: to compile without compiler optimization, but I apparently did not change the correct parameters, since it is still compiling with -O2 . My version of GCC is 4.2.3.

Finally, my stratum before segfault:

 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 +++

In the ARM system, I don’t have enough space to compile with debugging, so why is this right in the release.

+6
source share
1 answer

According to the error message related on some pages https://bugreports.qt.io/browse/QTBUG-13441

SEGV is in .. / 3rdparty / harfbuzz / src / harfbuzz- * (two segments are sent and both end with ../3rdparty/harfbuzz/src/harfbuzz-gsub.c )

So, you should try to rebuild only this third-party harfbuzz library with -g -O2 and -g -O0 . Since this is 3rdparty, it has its own build system, and I think it can be easily changed.

When you prove that your error is also in this library and that it depends on the -O2 / -O0 flag, you can:

  • Find the exact SEGV location and backtrack from GDB;
  • run x/i $pc from GDB and info reg to see where the SEGV data is and what the action is.
  • find the exact file / function with an error and parse the disassembly between versions -O0 and -O2
  • post both disassembly here and in QT bugtracker
  • point the error to harfbuzz or gcc

In addition, strace is almost not interesting, but gdb backtracking.

Update from Jérémy Dutheil: "Just by compiling with the -Os option: no more than segfault and very small size for libs!" - So, if O2 fails, O1 and / or Os should also be tried.

+3
source

Source: https://habr.com/ru/post/901702/

More articles:


All Articles