[arch-general] Debugging a kde app

Myra Nelson myra.nelson at hughes.net
Tue Feb 7 18:12:24 EST 2012


Caveat: I know this is probably an upstream bug so I'm just looking
for some general info. This is my first try at debugging. I'm using
the wiki articles for my guidance.

I some questions about debugging a KDE app, kshisen which is included
in the kdeames package. The best I can describe the behavior is "it
hangs at random intervals. Either when you select a tile it takes
several seconds to highlight it, after the first selection the
matching selection takes 5 to 10 seconds, then continues without
crashing". I've tried to get a screenshot but an unable to when
kshisen is hung up. I've recompiled the dependencies and kshisen like
this and built the packages in a clean chroot with extra-x86_64-build.

options=('!strip')

build() {
    export CFLAGS="-fbuiltin -g -march=native -O1 -pipe
-fstack-protector-all --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
    export CXXFLAGS="-fbuiltin -g -march=native -O1 -pipe
-fstack-protector-all --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
    export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu"

	cd $srcdir
	mkdir build
	cd build
	cmake ../../${pkgbase}-${pkgver} -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_SKIP_RPATH=ON  -DCMAKE_INSTALL_PREFIX=/usr
-DPYTHON_EXECUTABLE=/usr/bin/python2
	make
}

Next I ran [ valgrind --leak-check=full --track-origins=yes
--time-stamp=yes /usr/bin/kshisen ]. Valgrind reports several memory
leaks. As an example:

==00:00:07:20.414 32628== 24 bytes in 1 blocks are definitely lost in
loss record 139 of 425
==00:00:07:20.414 32628==    at 0x4C2993D: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:07:20.414 32628==    by 0xBA3A75A: FcPatternCreate (in
/usr/lib/libfontconfig.so.1.4.4)
==00:00:07:20.414 32628==    by 0xBA3861D: FcFontRenderPrepare (in
/usr/lib/libfontconfig.so.1.4.4)
==00:00:07:20.414 32628==    by 0xBA3883C: FcFontMatch (in
/usr/lib/libfontconfig.so.1.4.4)
==00:00:07:20.414 32628==    by 0x60BB2D7:
QFontDatabase::load(QFontPrivate const*, int) (in
/usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x6098586:
QFontPrivate::engineForScript(int) const (in
/usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x60AC187: QFontMetrics::height()
const (in /usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x62E1949: QStatusBar::reformat() (in
/usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x62E1C59:
QStatusBar::setSizeGripEnabled(bool) (in /usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x62E2007:
QStatusBar::QStatusBar(QWidget*) (in /usr/lib/libQtGui.so.4.8.0)
==00:00:07:20.414 32628==    by 0x515E55D:
KStatusBar::KStatusBar(QWidget*) (in /usr/lib/libkdeui.so.5.8.0)
==00:00:07:20.414 32628==    by 0x513F989: KMainWindow::statusBar()
(in /usr/lib/libkdeui.so.5.8.0)


Next I ran [ strace -eopen /usr/bin/kshisen ], which spits out quite a
few missing/not found files. As and example:

open("/usr/lib/tls/x86_64/libjson.so.0", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/usr/lib/tls/libjson.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open("/usr/lib/x86_64/libjson.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)

There is no directory /usr/lib/tls.

Then I ran [ readelf -a /usr/bin/kshisen | grep interp ] with the
following results.

  [ 1] .interp           PROGBITS         0000000000400238  00000238
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym
.dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt
.text .fini .rodata .eh_frame_hdr .eh_frame

Then I ran [ LD_DEBUG=files /usr/bin/kshisen > kshisen-lddebug.log
2>&1 ] which produces a long log.

If it would help I can put all the files in a pastebin.

I may be into overload but was trying to have enough info up front.

First question. Would a backtrace do any good?

Second question (sort of). I would like to bisect this app by cloning
the svn repo then compiling a previous version. Will I (my belief is
yes) need to set up a virtual environment to work on say the 4.7.9
version?

Any help or suggestions would be appreciated.

Myra

--
Life's fun when your sick and psychotic!


More information about the arch-general mailing list