[gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[James Beddek]

As part of transitioning to using Clang as my system compiler, I have been running tests on most
packages to determine if they still properly function. However, this has introduced a problem where
some KDE package tests segfault.
Unfortunately, this launches DrKonqi in the virtx display to display a backtrace.

This results in the test phase hanging as DrKonqi is presumably waiting for user input.
See below for an instance of a test phase hanging as seen through `top -b -c -n 1 -u portage`:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
3441869 portage   30  10    2360   1560   1400 S   0.0   0.0   0:00.00 [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test
3441870 portage   30  10   12896   7688   3592 S   0.0   0.0   0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
3441886 portage   30  10   13036   6296   2064 S   0.0   0.0   0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
3441908 portage   30  10  150436  59128  44836 S   0.0   0.1   0:00.03 /usr/bin/Xvfb :16 -screen 0 1280x1024x24 +extension RANDR
3441936 portage   30  10   55000  15512  13416 S   0.0   0.0   0:00.02 ctest -j 16 --test-load 999
3441938 portage   30  10  487364  58044  46480 T   0.0   0.1   0:00.20 /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarchivetest
3442262 portage   30  10    9176   2336   1600 S   0.0   0.0   0:00.00 dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 --binary-syntax --close-stderr
3442279 portage   30  10    9460   4180   3408 S   0.0   0.0   0:00.00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
3444712 portage   30  10  350068  94032  78820 S   0.0   0.1   0:00.15 /usr/lib64/libexec/drkonqi --platform xcb --display :16 --appname addtoarchivetest
___

As far as I can tell, without sending SIGKILL to the test being traced (addtoarchivetest in this instance), the test phase never exits.

KDE provides a variable, KDE_DEBUG [1], which when set disables the DrKonqi crash handler.
Using this results in the tests segfaulting and the test phase simply failing, rather than hanging.

Most of the crashing tests are a result of kde-frameworks/kjs being built with Clang.
I have opened a bug report about this on bugs.kde.org [2].

Hopefully this is an acceptable solution. I have submitted a corresponding GitHub PR [3].
Cheers

[1]: https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG
[2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5
[3]: https://github.com/gentoo/gentoo/pull/22643

James Beddek (1):
  ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

 eclass/ecm.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.33.1

[gentoo-dev] [PATCH 1/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[James Beddek]

The KDE_DEBUG variable [1] prevents crash handlers such as DrKonqi from launching
if a test were to segfault.

This prevents a hanging test phase where DrKonqi has launched and is waiting
for input on the virtx display.

[1]: https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG

Signed-off-by: James Beddek <telans@posteo.de>
---
 eclass/ecm.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/ecm.eclass b/eclass/ecm.eclass
index a2c8ed1c954..5ae6e73401e 100644
--- a/eclass/ecm.eclass
+++ b/eclass/ecm.eclass
@@ -508,7 +508,8 @@ ecm_src_test() {
 			export $(dbus-launch)
 		fi
 
-		cmake_src_test
+		# KDE_DEBUG stops crash handlers from launching and hanging the test phase
+		KDE_DEBUG=1 cmake_src_test
 	}
 
 	# When run as normal user during ebuild development with the ebuild command,
-- 
2.33.1

Re: [gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[Alexey Sokolov]

20.10.2021 09:40, James Beddek пишет:
> As part of transitioning to using Clang as my system compiler, I have been running tests on most
> packages to determine if they still properly function. However, this has introduced a problem where
> some KDE package tests segfault.
> Unfortunately, this launches DrKonqi in the virtx display to display a backtrace.
> 
> This results in the test phase hanging as DrKonqi is presumably waiting for user input.
> See below for an instance of a test phase hanging as seen through `top -b -c -n 1 -u portage`:
> 
>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
> 3441869 portage   30  10    2360   1560   1400 S   0.0   0.0   0:00.00 [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test
> 3441870 portage   30  10   12896   7688   3592 S   0.0   0.0   0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
> 3441886 portage   30  10   13036   6296   2064 S   0.0   0.0   0:00.01 /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
> 3441908 portage   30  10  150436  59128  44836 S   0.0   0.1   0:00.03 /usr/bin/Xvfb :16 -screen 0 1280x1024x24 +extension RANDR
> 3441936 portage   30  10   55000  15512  13416 S   0.0   0.0   0:00.02 ctest -j 16 --test-load 999
> 3441938 portage   30  10  487364  58044  46480 T   0.0   0.1   0:00.20 /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarchivetest
> 3442262 portage   30  10    9176   2336   1600 S   0.0   0.0   0:00.00 dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 --binary-syntax --close-stderr
> 3442279 portage   30  10    9460   4180   3408 S   0.0   0.0   0:00.00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
> 3444712 portage   30  10  350068  94032  78820 S   0.0   0.1   0:00.15 /usr/lib64/libexec/drkonqi --platform xcb --display :16 --appname addtoarchivetest
> ___
> 
> As far as I can tell, without sending SIGKILL to the test being traced (addtoarchivetest in this instance), the test phase never exits.
> 
> KDE provides a variable, KDE_DEBUG [1], which when set disables the DrKonqi crash handler.
> Using this results in the tests segfaulting and the test phase simply failing, rather than hanging.

Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the
reason to add this variable only to ecm.eclass?

> 
> Most of the crashing tests are a result of kde-frameworks/kjs being built with Clang.
> I have opened a bug report about this on bugs.kde.org [2].
> 
> Hopefully this is an acceptable solution. I have submitted a corresponding GitHub PR [3].
> Cheers
> 
> [1]: https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG
> [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5
> [3]: https://github.com/gentoo/gentoo/pull/22643
> 
> James Beddek (1):
>   ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
> 
>  eclass/ecm.eclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[James Beddek]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]

On Wednesday, 20 October 2021 10:34:47 PM NZDT Alexey Sokolov wrote:
> 20.10.2021 09:40, James Beddek пишет:
> > As part of transitioning to using Clang as my system compiler, I have been
> > running tests on most packages to determine if they still properly
> > function. However, this has introduced a problem where some KDE package
> > tests segfault.
> > Unfortunately, this launches DrKonqi in the virtx display to display a
> > backtrace.
> > 
> > This results in the test phase hanging as DrKonqi is presumably waiting
> > for user input.> 
> > See below for an instance of a test phase hanging as seen through `top -b 
-c -n 1 -u portage`:
> >     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
> >     COMMAND
> > 
> > 3441869 portage   30  10    2360   1560   1400 S   0.0   0.0   0:00.00
> > [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test
> > 3441870 portage   30  10   12896   7688   3592 S   0.0   0.0   0:00.01
> > /bin/bash /usr/lib/portage/python3.9/ebuild.sh test 3441886 portage   30 
> > 10   13036   6296   2064 S   0.0   0.0   0:00.01 /bin/bash
> > /usr/lib/portage/python3.9/ebuild.sh test 3441908 portage   30  10 
> > 150436  59128  44836 S   0.0   0.1   0:00.03 /usr/bin/Xvfb :16 -screen 0
> > 1280x1024x24 +extension RANDR 3441936 portage   30  10   55000  15512 
> > 13416 S   0.0   0.0   0:00.02 ctest -j 16 --test-load 999 3441938 portage
> >   30  10  487364  58044  46480 T   0.0   0.1   0:00.20
> > /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarc
> > hivetest 3442262 portage   30  10    9176   2336   1600 S   0.0   0.0  
> > 0:00.00 dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6
> > --binary-syntax --close-stderr 3442279 portage   30  10    9460   4180  
> > 3408 S   0.0   0.0   0:00.00 /usr/bin/dbus-daemon --syslog-only --fork
> > --print-pid 5 --print-address 7 --session 3444712 portage   30  10 
> > 350068  94032  78820 S   0.0   0.1   0:00.15 /usr/lib64/libexec/drkonqi
> > --platform xcb --display :16 --appname addtoarchivetest ___
> > 
> > As far as I can tell, without sending SIGKILL to the test being traced
> > (addtoarchivetest in this instance), the test phase never exits.
> > 
> > KDE provides a variable, KDE_DEBUG [1], which when set disables the
> > DrKonqi crash handler. Using this results in the tests segfaulting and
> > the test phase simply failing, rather than hanging.
> Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the
> reason to add this variable only to ecm.eclass?
> 

As far as I can tell only packages that use ecm.eclass trigger DrKonqi upon a 
test segfault. However, this may just be to me not experiencing crashes in 
other test suites. To the best of my knowledge it's purely the KDE/ecm 
packages.

Cheers

> > Most of the crashing tests are a result of kde-frameworks/kjs being built
> > with Clang. I have opened a bug report about this on bugs.kde.org [2].
> > 
> > Hopefully this is an acceptable solution. I have submitted a corresponding
> > GitHub PR [3]. Cheers
> > 
> > [1]:
> > https://userbase.kde.org/KDE_System_Administration/Environment_Variables#
> > KDE_DEBUG [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5
> > [3]: https://github.com/gentoo/gentoo/pull/22643
> > 
> > James Beddek (1):
> >   ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
> >  
> >  eclass/ecm.eclass | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[Duncan]

James Beddek posted on Wed, 20 Oct 2021 09:42:14 +0000 as excerpted:

>> > KDE provides a variable, KDE_DEBUG [1], which when set disables the
>> > DrKonqi crash handler. Using this results in the tests segfaulting
>> > and the test phase simply failing, rather than hanging.
>> Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the
>> reason to add this variable only to ecm.eclass?
>> 
> As far as I can tell only packages that use ecm.eclass trigger DrKonqi
> upon a test segfault. However, this may just be to me not experiencing
> crashes in other test suites. To the best of my knowledge it's purely
> the KDE/ecm packages.

DrKonqi is part of kde's plasma, in gentoo as kde-plasma/drkonqi .  As 
such it depends on various kde-frameworks/* including kde-frameworks/
extra-cmake-modules, shortened in kde-dev lingo to ECM, thus ecm.eclass.  
And ECM is the way they handle kde-specific cmake detection so basically 
any app that cares about drkonqi is going to be using ecm.eclass as well.

Tho the reverse doesn't necessarily hold -- ECM as a framework is far 
more basic than drkonqi as a plasma component, and while my kde/plasma 
installation is somewhat lite, nothing's actually pulling in drkonqi and 
it's not merged, while a quick equery d extra-cmake-modules | wc -l 
suggests 151 packages depend on extra-cmake-modules and a look at the 
list confirms they're all kde related, tho a few like media-libs/phonon 
are not kde-*.

And without drkonqi I get segfaults.  Which suggests another possible 
workaround, unmerging drkonki.  If the only thing pulling it in is a set 
or metapackage the alternative would be either a local-overlay null-
package, or commenting that entry in a local copy of the set/metapackage.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman