Debugging failures in KIO when using custom CI environment

2014-12-06 Thread Jan Kundrát 

Hi,
I'm working on a testing setup which plugs into Gerrit to add info whether 
a proposed change still builds and tests continue to pass. This is using a 
modified version of KDE's own Jenkins' CI scripts, but the environment is 
very likely much different. It runs within a sanitized environment on a 
CentOS7 VM using Qt 5.3.2 from EPEL.


I'm seeing quite a few timeouts during the execution of these tests. A full 
build log is at [1], the failures start at 2014-12-06 14:48:57,448.


This is how a backtrace from a debugger attached to one of the stuck tests 
looked like:


(gdb) bt
#0  0x7f2c668eba4d in poll () from /lib64/libc.so.6
#1  0x7f2c629c8dd4 in g_main_context_iterate.isra.22 () from 
/lib64/libglib-2.0.so.0
#2  0x7f2c629c8efc in g_main_context_iteration () from 
/lib64/libglib-2.0.so.0
#3  0x7f2c676d333b in 
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) 
() from /lib64/libQt5Core.so.5
#4  0x7f2c676776fb in 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from 
/lib64/libQt5Core.so.5
#5  0x7f2c67d7611c in KJob::exec (this=0x1aa30f0) at 
/home/turbo-hipster/git/3d0386f34adf/kcoreaddons/src/lib/jobs/kjob.cpp:188
#6  0x00407e36 in MkpathJobTest::shouldCreateOneDirectory 
(this=0x7fffc9943e80) at 
/home/turbo-hipster/git/0c50b62535fe/kio/autotests/mkpathjobtest.cpp:68
#7  0x00406888 in MkpathJobTest::qt_static_metacall 
(_o=0x7fffc9943e80, _c=QMetaObject::InvokeMetaMethod, _id=3, 
_a=0x7fffc9943440) at 
/home/turbo-hipster/jobs/0c50b62535fe/01/201/1/check/check-kf5qt5-generic-test-el7/b840c48/build/autotests/mkpathjobtest.moc:100
#8  0x7f2c676840fc in QMetaMethod::invoke(QObject*, Qt::ConnectionType, 
QGenericReturnArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) 
const ()

  from /lib64/libQt5Core.so.5
#9  0x7f2c676885cc in QMetaObject::invokeMethod(QObject*, char const*, 
Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument) ()

  from /lib64/libQt5Core.so.5
#10 0x7f2c6881eff2 in QTest::qInvokeTestMethod(char const*, char 
const*) () from /lib64/libQt5Test.so.5
#11 0x7f2c6881fa48 in QTest::qExec(QObject*, int, char**) () from 
/lib64/libQt5Test.so.5
#12 0x004067d9 in main (argc=1, argv=0x7fffc9943fa8) at 
/home/turbo-hipster/git/0c50b62535fe/kio/autotests/mkpathjobtest.cpp:145


For comparison, the tests went much further when I simply used a `su -` 
environment to run them, see [2]. (That was also against a different 
commit, but I don't see any relevant changes in there.)


- Do you see some obvious problem in what I'm doing?

With kind regards,
Jan

[1] 
http://ci-logs.kde.flaska.net/01/201/1/check/check-kf5qt5-generic-test-el7/b840c48/shell_output.log

[2] http://ci-logs.kde.flaska.net/manual/rebuilddep/0022/shell_output.log

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Debugging failures in KIO when using custom CI environment

2014-12-06 Thread Jan Kundrát 
It seems that the problem is related to how a kioslave is launched along 
with using different installation dirs. Here's what got me to the right 
path:


13032 
execve(/home/turbo-hipster/target/el7-x86_64-gcc/kf5-qt5/frameworks/kio/inst/lib64/libexec/kf5/kioslave, 
[/home/turbo-hipster/target/el7-x..., 
/home/turbo-hipster/jobs/7f0e670..., file, , 
local:/tmp/runtime-turbo-hipster...], [/* 41 vars */]) = -1 ENOENT (No 
such file or directory)


There was a bug in error checking within kioslave, see [1] for a fixes.

The real problem with CI is that the CI environment configures the build 
with an expected install prefix being 
/home/turbo-hipster/target/el7-x86_64-gcc/kf5-qt5/frameworks/kio/inst, but 
the actual installation goes somewhere else, into a temporary directory. 
This problem is masked by Jenkins on build.kde.org because it will always 
attempt to deploy the build to that directory and rsync to some shared 
depot afterwards. The checks of _proposed_ changes within Gerrit/Zuul, 
however, do not perform the rsync step, and that means that the kioslave 
executable was there.


- I have stuff to fix in the CI environment.

With kind regards,
Jan

[1] https://gerrit.vesnicky.cesnet.cz/r/202

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel