[CRITICAL] KIO Test "threadtest" can enter into infinite loop
Hi all, It appears the test running with the binary name of "threadtest" in kio has a grave bug which can lead to it entering into an infinite loop. This was consuming virtually the entire resources of one builder with old hung processes, and the whole core of another builder - drastically limiting the capabilities of the CI system (even though KIO was not being built at the time). Can someone please investigate? Manual intervention (with kill -9) is needed to remove these hung processes. Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > Hi all, > > It appears the test running with the binary name of "threadtest" in > kio has a grave bug which can lead to it entering into an infinite > loop. > > This was consuming virtually the entire resources of one builder with > old hung processes, and the whole core of another builder - > drastically limiting the capabilities of the CI system (even though > KIO was not being built at the time). > > Can someone please investigate? Manual intervention (with kill -9) is > needed to remove these hung processes. It of course works fine on my own machine. And I just tried running it on LinuxNode2, in ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env which I just generated), and it ran fine (multiple times). Any suggestion on how / where to hit the issue? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Saturday 07 November 2015 10:36:18 David Faure wrote: > On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > > Hi all, > > > > It appears the test running with the binary name of "threadtest" in > > kio has a grave bug which can lead to it entering into an infinite > > loop. > > > > This was consuming virtually the entire resources of one builder with > > old hung processes, and the whole core of another builder - > > drastically limiting the capabilities of the CI system (even though > > KIO was not being built at the time). > > > > Can someone please investigate? Manual intervention (with kill -9) is > > needed to remove these hung processes. > > It of course works fine on my own machine. > > And I just tried running it on LinuxNode2, in > ~/builds/kio/stable-kf5-qt5/build/autotests > (after sourcing ~/kio.env which I just generated), and it ran fine (multiple > times). > > Any suggestion on how / where to hit the issue? OK, it happens in kf5-qt5 rather than in stable-kf5-qt5 One of the KIO-using threads seems stuck in QProcess smells like a Qt bug? Or is there a reason why starting a new process or creating a new pipe would sometimes fail (some ulimit?) Context: this test starts 20 threads at once, each of which starts a QProcess (using startDetached) (for the kioslave binary). It works most of the time, but sometimes hangs with the bt below. (gdb) bt #0 0x74bdd49d in read () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x76f27637 in read () from /usr/lib/x86_64-linux-gnu/libasan.so.1 #2 0x7565a2ed in qt_safe_read (fd=43, data=0x7fffddf14cc0, maxlen=1) at ../../include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:265 #3 0x7565e2b4 in QProcessPrivate::startDetached (program=..., arguments=..., workingDirectory=..., pid=0x0) at io/qprocess_unix.cpp:1246 #4 0x7560142d in QProcess::startDetached (program=..., arguments=...) at io/qprocess.cpp:2461 #5 0x7652f1f5 in KIO::Slave::createSlave (protocol=..., url=..., error=@0x7fffddf15260: 214848, error_text=...) at /home/jenkins/builds/kio/kf5-qt5/src/core/slave.cpp:499 #6 0x7658ec6d in KIO::ProtoQueue::createSlave (this=0x611db8c0, protocol=..., job=0x6032e330, url=...) at /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:529 #7 0x7658fc60 in KIO::ProtoQueue::startAJob (this=0x611db8c0) at /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:616 #8 0x76599711 in KIO::ProtoQueue::qt_static_metacall (_o=0x611db8c0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffddf154b0) at /home/jenkins/builds/kio/kf5-qt5/build/src/core/moc_scheduler_p.cpp:250 #9 0x7571273e in QMetaObject::activate (sender=0x611db918, signalOffset=3, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3713 #10 0x75711f2a in QMetaObject::activate (sender=0x611db918, m=0x75a45420 , local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3578 #11 0x757b6b49 in QTimer::timeout (this=0x611db918) at .moc/moc_qtimer.cpp:197 #12 0x7571e420 in QTimer::timerEvent (this=0x611db918, e=0x7fffddf158c0) at kernel/qtimer.cpp:247 #13 0x7570b77b in QObject::event (this=0x611db918, e=0x7fffddf158c0) at kernel/qobject.cpp:1220 #14 0x756d0782 in QCoreApplicationPrivate::notify_helper (this=0x60f0ef50, receiver=0x611db918, event=0x7fffddf158c0) at kernel/qcoreapplication.cpp:1093 #15 0x756d0409 in QCoreApplication::notify (this=0x7fff7570, receiver=0x611db918, event=0x7fffddf158c0) at kernel/qcoreapplication.cpp:1038 #16 0x756d02f1 in QCoreApplication::notifyInternal (this=0x7fff7570, receiver=0x611db918, event=0x7fffddf158c0) at kernel/qcoreapplication.cpp:965 #17 0x756d42a5 in QCoreApplication::sendEvent (receiver=0x611db918, event=0x7fffddf158c0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224 #18 0x7574cac1 in QTimerInfoList::activateTimers (this=0x60f8e6c0) at kernel/qtimerinfo_unix.cpp:637 #19 0x7574dfc0 in timerSourceDispatch (source=0x60f8e660) at kernel/qeventdispatcher_glib.cpp:177 Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) debug build; by GCC 4.9.2) After many tries I got it to hang under strace -f as well. Here's the log: http://www.davidfaure.fr/2015/strace.output.bz2 pipe2() succeeds 40 times, so that's not the problem... Process 7389 (which works) does set_robust_list, close(43), execve(kioslave). Process 7391 (which hangs) does set_robust_list, close(43) ... and nothing else. Overall I see 60 calls to clone(), 40 calls to pipe2(), but only 16 calls to execve(kioslave). Help? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.or
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Sat, Nov 7, 2015 at 11:23 PM, David Faure wrote: > On Saturday 07 November 2015 10:36:18 David Faure wrote: >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: >> > Hi all, >> > >> > It appears the test running with the binary name of "threadtest" in >> > kio has a grave bug which can lead to it entering into an infinite >> > loop. >> > >> > This was consuming virtually the entire resources of one builder with >> > old hung processes, and the whole core of another builder - >> > drastically limiting the capabilities of the CI system (even though >> > KIO was not being built at the time). >> > >> > Can someone please investigate? Manual intervention (with kill -9) is >> > needed to remove these hung processes. >> >> It of course works fine on my own machine. >> >> And I just tried running it on LinuxNode2, in >> ~/builds/kio/stable-kf5-qt5/build/autotests >> (after sourcing ~/kio.env which I just generated), and it ran fine (multiple >> times). >> >> Any suggestion on how / where to hit the issue? > > OK, it happens in kf5-qt5 rather than in stable-kf5-qt5 > > One of the KIO-using threads seems stuck in QProcess smells like a Qt bug? > Or is there a reason why starting a new process or creating a new pipe would > sometimes fail (some ulimit?) It working in stable-kf5-qt5 but failing in kf5-qt5 would support the theory of a Qt bug - the only difference is the version of Qt... > > Context: this test starts 20 threads at once, each of which starts a QProcess > (using startDetached) (for the kioslave binary). It works most of the time, > but sometimes > hangs with the bt below. > > (gdb) bt > #0 0x74bdd49d in read () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x76f27637 in read () from /usr/lib/x86_64-linux-gnu/libasan.so.1 > #2 0x7565a2ed in qt_safe_read (fd=43, data=0x7fffddf14cc0, maxlen=1) > at > ../../include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:265 > #3 0x7565e2b4 in QProcessPrivate::startDetached (program=..., > arguments=..., workingDirectory=..., pid=0x0) at io/qprocess_unix.cpp:1246 > #4 0x7560142d in QProcess::startDetached (program=..., > arguments=...) at io/qprocess.cpp:2461 > #5 0x7652f1f5 in KIO::Slave::createSlave (protocol=..., url=..., > error=@0x7fffddf15260: 214848, error_text=...) at > /home/jenkins/builds/kio/kf5-qt5/src/core/slave.cpp:499 > #6 0x7658ec6d in KIO::ProtoQueue::createSlave (this=0x611db8c0, > protocol=..., job=0x6032e330, url=...) at > /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:529 > #7 0x7658fc60 in KIO::ProtoQueue::startAJob (this=0x611db8c0) at > /home/jenkins/builds/kio/kf5-qt5/src/core/scheduler.cpp:616 > #8 0x76599711 in KIO::ProtoQueue::qt_static_metacall > (_o=0x611db8c0, _c=QMetaObject::InvokeMetaMethod, _id=0, > _a=0x7fffddf154b0) > at /home/jenkins/builds/kio/kf5-qt5/build/src/core/moc_scheduler_p.cpp:250 > #9 0x7571273e in QMetaObject::activate (sender=0x611db918, > signalOffset=3, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3713 > #10 0x75711f2a in QMetaObject::activate (sender=0x611db918, > m=0x75a45420 , local_signal_index=0, argv=0x0) > at kernel/qobject.cpp:3578 > #11 0x757b6b49 in QTimer::timeout (this=0x611db918) at > .moc/moc_qtimer.cpp:197 > #12 0x7571e420 in QTimer::timerEvent (this=0x611db918, > e=0x7fffddf158c0) at kernel/qtimer.cpp:247 > #13 0x7570b77b in QObject::event (this=0x611db918, > e=0x7fffddf158c0) at kernel/qobject.cpp:1220 > #14 0x756d0782 in QCoreApplicationPrivate::notify_helper > (this=0x60f0ef50, receiver=0x611db918, event=0x7fffddf158c0) at > kernel/qcoreapplication.cpp:1093 > #15 0x756d0409 in QCoreApplication::notify (this=0x7fff7570, > receiver=0x611db918, event=0x7fffddf158c0) at > kernel/qcoreapplication.cpp:1038 > #16 0x756d02f1 in QCoreApplication::notifyInternal > (this=0x7fff7570, receiver=0x611db918, event=0x7fffddf158c0) at > kernel/qcoreapplication.cpp:965 > #17 0x756d42a5 in QCoreApplication::sendEvent > (receiver=0x611db918, event=0x7fffddf158c0) at > ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224 > #18 0x7574cac1 in QTimerInfoList::activateTimers > (this=0x60f8e6c0) at kernel/qtimerinfo_unix.cpp:637 > #19 0x7574dfc0 in timerSourceDispatch (source=0x60f8e660) at > kernel/qeventdispatcher_glib.cpp:177 > > Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 > shared (dynamic) debug build; by GCC 4.9.2) > > After many tries I got it to hang under strace -f as well. > Here's the log: http://www.davidfaure.fr/2015/strace.output.bz2 > pipe2() succeeds 40 times, so that's not the problem... > > Process 7389 (which works) does set_robust_list, close(43), execve(kioslave). > Process 7391 (which hangs) does set_robust_list, close(43)
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
2015-11-07 7:23 GMT-03:00 David Faure : > On Saturday 07 November 2015 10:36:18 David Faure wrote: >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: >> > Hi all, >> > >> > It appears the test running with the binary name of "threadtest" in >> > kio has a grave bug which can lead to it entering into an infinite >> > loop. >> > >> > This was consuming virtually the entire resources of one builder with >> > old hung processes, and the whole core of another builder - >> > drastically limiting the capabilities of the CI system (even though >> > KIO was not being built at the time). >> > >> > Can someone please investigate? Manual intervention (with kill -9) is >> > needed to remove these hung processes. >> >> It of course works fine on my own machine. >> >> And I just tried running it on LinuxNode2, in >> ~/builds/kio/stable-kf5-qt5/build/autotests >> (after sourcing ~/kio.env which I just generated), and it ran fine (multiple >> times). >> >> Any suggestion on how / where to hit the issue? > > OK, it happens in kf5-qt5 rather than in stable-kf5-qt5 > > One of the KIO-using threads seems stuck in QProcess smells like a Qt bug? > Or is there a reason why starting a new process or creating a new pipe would > sometimes fail (some ulimit?) > > Context: this test starts 20 threads at once, each of which starts a QProcess > (using startDetached) (for the kioslave binary). It works most of the time, > but sometimes > hangs with the bt below. > > (gdb) bt > #0 0x74bdd49d in read () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x76f27637 in read () from /usr/lib/x86_64-linux-gnu/libasan.so.1 > #2 0x7565a2ed in qt_safe_read (fd=43, data=0x7fffddf14cc0, maxlen=1) > at > ../../include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:265 Could it be an asan bug? Have you tried compiling this without address sanitizer? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: > On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > > Hi all, > > > > It appears the test running with the binary name of "threadtest" in > > kio has a grave bug which can lead to it entering into an infinite > > loop. > > > > This was consuming virtually the entire resources of one builder with > > old hung processes, and the whole core of another builder - > > drastically limiting the capabilities of the CI system (even though > > KIO was not being built at the time). > > > > Can someone please investigate? Manual intervention (with kill -9) is > > needed to remove these hung processes. > > It of course works fine on my own machine. > > And I just tried running it on LinuxNode2, in > ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env which > I just generated), and it ran fine (multiple times). > > Any suggestion on how / where to hit the issue? I too have serious problems being able to reproduce the same results on the build nodes than CI has :( I guess we're most probably missing some step (e.g. kdelibs failing test always work when i try to reproduce it, rocs compiles fine, etc) Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Mon, Nov 9, 2015 at 10:26 AM, Albert Astals Cid wrote: > El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: >> > Hi all, >> > >> > It appears the test running with the binary name of "threadtest" in >> > kio has a grave bug which can lead to it entering into an infinite >> > loop. >> > >> > This was consuming virtually the entire resources of one builder with >> > old hung processes, and the whole core of another builder - >> > drastically limiting the capabilities of the CI system (even though >> > KIO was not being built at the time). >> > >> > Can someone please investigate? Manual intervention (with kill -9) is >> > needed to remove these hung processes. >> >> It of course works fine on my own machine. >> >> And I just tried running it on LinuxNode2, in >> ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env which >> I just generated), and it ran fine (multiple times). >> >> Any suggestion on how / where to hit the issue? > > I too have serious problems being able to reproduce the same results on the > build nodes than CI has :( > > I guess we're most probably missing some step (e.g. kdelibs failing test > always work when i try to reproduce it, rocs compiles fine, etc) Albert, did you try with the kf5-qt5 or stable-kf5-qt5 branch group? It seems this is a Qt regression (and the version differs). > > Cheers, > Albert Regards, Ben > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Monday 09 November 2015 19:36:09 Ben Cooksley wrote: > On Mon, Nov 9, 2015 at 10:26 AM, Albert Astals Cid wrote: > > El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: > >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > >> > Hi all, > >> > > >> > It appears the test running with the binary name of "threadtest" in > >> > kio has a grave bug which can lead to it entering into an infinite > >> > loop. > >> > > >> > This was consuming virtually the entire resources of one builder with > >> > old hung processes, and the whole core of another builder - > >> > drastically limiting the capabilities of the CI system (even though > >> > KIO was not being built at the time). > >> > > >> > Can someone please investigate? Manual intervention (with kill -9) is > >> > needed to remove these hung processes. > >> > >> It of course works fine on my own machine. > >> > >> And I just tried running it on LinuxNode2, in > >> ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env which > >> I just generated), and it ran fine (multiple times). > >> > >> Any suggestion on how / where to hit the issue? > > > > I too have serious problems being able to reproduce the same results on the > > build nodes than CI has :( > > > > I guess we're most probably missing some step (e.g. kdelibs failing test > > always work when i try to reproduce it, rocs compiles fine, etc) > > Albert, did you try with the kf5-qt5 or stable-kf5-qt5 branch group? > It seems this is a Qt regression (and the version differs). Now I'm not sure if you guys are talking about kio's threadtest or about other things (kdelibs, rocs). To get back to the kio threadtest topic, it passes in a loop here, even with Qt 5.6. -> sorry Oswald, false alert. So I think Nicolás Alvarez is right, this is more likely a bug in asan. I forgot that we had that enabled in the CI - which makes one more difference between our local setups and the CI ;) Ben, Albert, do we have a way to turn off asan for kio's threadtest? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
On Mon, Nov 9, 2015 at 8:30 PM, David Faure wrote: > On Monday 09 November 2015 19:36:09 Ben Cooksley wrote: >> On Mon, Nov 9, 2015 at 10:26 AM, Albert Astals Cid wrote: >> > El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: >> >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: >> >> > Hi all, >> >> > >> >> > It appears the test running with the binary name of "threadtest" in >> >> > kio has a grave bug which can lead to it entering into an infinite >> >> > loop. >> >> > >> >> > This was consuming virtually the entire resources of one builder with >> >> > old hung processes, and the whole core of another builder - >> >> > drastically limiting the capabilities of the CI system (even though >> >> > KIO was not being built at the time). >> >> > >> >> > Can someone please investigate? Manual intervention (with kill -9) is >> >> > needed to remove these hung processes. >> >> >> >> It of course works fine on my own machine. >> >> >> >> And I just tried running it on LinuxNode2, in >> >> ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env >> >> which >> >> I just generated), and it ran fine (multiple times). >> >> >> >> Any suggestion on how / where to hit the issue? >> > >> > I too have serious problems being able to reproduce the same results on the >> > build nodes than CI has :( >> > >> > I guess we're most probably missing some step (e.g. kdelibs failing test >> > always work when i try to reproduce it, rocs compiles fine, etc) >> >> Albert, did you try with the kf5-qt5 or stable-kf5-qt5 branch group? >> It seems this is a Qt regression (and the version differs). > > Now I'm not sure if you guys are talking about kio's threadtest or about other > things (kdelibs, rocs). > > To get back to the kio threadtest topic, it passes in a loop here, even with > Qt 5.6. > -> sorry Oswald, false alert. > > So I think Nicolás Alvarez is right, this is more likely a bug in asan. > I forgot that we had that enabled in the CI - which makes one more difference > between > our local setups and the CI ;) > > Ben, Albert, do we have a way to turn off asan for kio's threadtest? Only for all of KIO, which I have now done. Please file a bug against ASAN support (compiler bug I assume?) Regards, Ben > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
El Monday 09 November 2015, a les 08:30:14, David Faure va escriure: > On Monday 09 November 2015 19:36:09 Ben Cooksley wrote: > > On Mon, Nov 9, 2015 at 10:26 AM, Albert Astals Cid wrote: > > > El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: > > >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > > >> > Hi all, > > >> > > > >> > It appears the test running with the binary name of "threadtest" in > > >> > kio has a grave bug which can lead to it entering into an infinite > > >> > loop. > > >> > > > >> > This was consuming virtually the entire resources of one builder with > > >> > old hung processes, and the whole core of another builder - > > >> > drastically limiting the capabilities of the CI system (even though > > >> > KIO was not being built at the time). > > >> > > > >> > Can someone please investigate? Manual intervention (with kill -9) is > > >> > needed to remove these hung processes. > > >> > > >> It of course works fine on my own machine. > > >> > > >> And I just tried running it on LinuxNode2, in > > >> ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env > > >> which > > >> I just generated), and it ran fine (multiple times). > > >> > > >> Any suggestion on how / where to hit the issue? > > > > > > I too have serious problems being able to reproduce the same results on > > > the > > > build nodes than CI has :( > > > > > > I guess we're most probably missing some step (e.g. kdelibs failing test > > > always work when i try to reproduce it, rocs compiles fine, etc) > > > > Albert, did you try with the kf5-qt5 or stable-kf5-qt5 branch group? > > It seems this is a Qt regression (and the version differs). > > Now I'm not sure if you guys are talking about kio's threadtest or about > other things (kdelibs, rocs). I was talking about how hard is for me to reproduce the test failures even when running on CI, I thought you had this too, ended up being a different thing. Cheers, Albert > > To get back to the kio threadtest topic, it passes in a loop here, even with > Qt 5.6. -> sorry Oswald, false alert. > > So I think Nicolás Alvarez is right, this is more likely a bug in asan. > I forgot that we had that enabled in the CI - which makes one more > difference between our local setups and the CI ;) > > Ben, Albert, do we have a way to turn off asan for kio's threadtest? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [CRITICAL] KIO Test "threadtest" can enter into infinite loop
El Tuesday 10 November 2015, a les 19:57:50, Ben Cooksley va escriure: > On Mon, Nov 9, 2015 at 8:30 PM, David Faure wrote: > > On Monday 09 November 2015 19:36:09 Ben Cooksley wrote: > >> On Mon, Nov 9, 2015 at 10:26 AM, Albert Astals Cid wrote: > >> > El Saturday 07 November 2015, a les 10:36:18, David Faure va escriure: > >> >> On Saturday 07 November 2015 11:17:31 Ben Cooksley wrote: > >> >> > Hi all, > >> >> > > >> >> > It appears the test running with the binary name of "threadtest" in > >> >> > kio has a grave bug which can lead to it entering into an infinite > >> >> > loop. > >> >> > > >> >> > This was consuming virtually the entire resources of one builder > >> >> > with > >> >> > old hung processes, and the whole core of another builder - > >> >> > drastically limiting the capabilities of the CI system (even though > >> >> > KIO was not being built at the time). > >> >> > > >> >> > Can someone please investigate? Manual intervention (with kill -9) > >> >> > is > >> >> > needed to remove these hung processes. > >> >> > >> >> It of course works fine on my own machine. > >> >> > >> >> And I just tried running it on LinuxNode2, in > >> >> ~/builds/kio/stable-kf5-qt5/build/autotests (after sourcing ~/kio.env > >> >> which > >> >> I just generated), and it ran fine (multiple times). > >> >> > >> >> Any suggestion on how / where to hit the issue? > >> > > >> > I too have serious problems being able to reproduce the same results on > >> > the > >> > build nodes than CI has :( > >> > > >> > I guess we're most probably missing some step (e.g. kdelibs failing > >> > test > >> > always work when i try to reproduce it, rocs compiles fine, etc) > >> > >> Albert, did you try with the kf5-qt5 or stable-kf5-qt5 branch group? > >> It seems this is a Qt regression (and the version differs). > > > > Now I'm not sure if you guys are talking about kio's threadtest or about > > other things (kdelibs, rocs). > > > > To get back to the kio threadtest topic, it passes in a loop here, even > > with Qt 5.6.> > > -> sorry Oswald, false alert. > > > > So I think Nicolás Alvarez is right, this is more likely a bug in asan. > > I forgot that we had that enabled in the CI - which makes one more > > difference between our local setups and the CI ;) > > > > Ben, Albert, do we have a way to turn off asan for kio's threadtest? > > Only for all of KIO, which I have now done. > Please file a bug against ASAN support (compiler bug I assume?) Given how "old" is the compiler we use I am not convinced it makes sense unless we have a small testcase to attach to the bug. Cheers, Albert > > Regards, > Ben > > > -- > > David Faure, fa...@kde.org, http://www.davidfaure.fr > > Working on KDE Frameworks 5 > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
