powerdevil kde restarting endlessly

[Randommist]

When upgrading to ddcutil-2.1.0-1 in arch I get powerdevil kde restarting endlessly. After rollback to ddcutil-2.0.0-1 via cache and pacman everything works fine. Why is this happening?

error message

Process 21108 (org_kde_powerde) of user 1000 dumped core.

Stack trace of thread 21109: #0 0x0000778d6dcac83c n/a (libc.so.6 + 0x8e83c) #1 0x0000778d6dc5c668 raise (libc.so.6 + 0x3e668) #2 0x0000778d6f19c88f _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x788f) #3 0x0000778d6dc5c710 n/a (libc.so.6 + 0x3e710) #4 0x0000778d6dcac83c n/a (libc.so.6 + 0x8e83c) #5 0x0000778d6dc5c668 raise (libc.so.6 + 0x3e668) #6 0x0000778d6dc5c710 n/a (libc.so.6 + 0x3e710) #7 0x0000778d6dd20f6f __poll (libc.so.6 + 0x102f6f) #8 0x0000778d6d16c2b6 n/a (libglib-2.0.so.0 + 0xb82b6) #9 0x0000778d6d10c162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162) #10 0x0000778d6e4ead2f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ead2f) #11 0x0000778d6e49ac04 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x29ac04) #12 0x0000778d6e2f7576 _ZN7QThread4execEv (libQt5Core.so.5 + 0xf7576) #13 0x0000778d6ef25a9a n/a (libQt5DBus.so.5 + 0x18a9a) #14 0x0000778d6e2f379a n/a (libQt5Core.so.5 + 0xf379a) #15 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #16 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc)

Stack trace of thread 21108: #0 0x0000778d6dd20f6f __poll (libc.so.6 + 0x102f6f) #1 0x0000778d6f19bbca n/a (libKF5Crash.so.5 + 0x6bca) #2 0x0000778d6f19c82c _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x782c) #3 0x0000778d6dc5c710 n/a (libc.so.6 + 0x3e710) #4 0x0000778d6dcac83c n/a (libc.so.6 + 0x8e83c) #5 0x0000778d6dc5c668 raise (libc.so.6 + 0x3e668) #6 0x0000778d6dc444b8 abort (libc.so.6 + 0x264b8) #7 0x0000778d6dc443dc n/a (libc.so.6 + 0x263dc) #8 0x0000778d6dc54d26 __assert_fail (libc.so.6 + 0x36d26) #9 0x0000778d67a742b9 n/a (libddcutil.so.5 + 0x4c2b9) #10 0x0000778d67a76f35 n/a (libddcutil.so.5 + 0x4ef35) #11 0x0000778d67a771f5 n/a (libddcutil.so.5 + 0x4f1f5) #12 0x0000778d67a9b16b n/a (libddcutil.so.5 + 0x7316b) #13 0x0000778d67aa28a2 ddca_get_display_info_list2 (libddcutil.so.5 + 0x7a8a2) #14 0x0000778d67b48d37 n/a (powerdevilupowerbackend.so + 0x11d37) #15 0x0000778d67b4a62e _ZN23PowerDevilUPowerBackend18initWithBrightnessEb (powerdevilupowerbackend.so + 0x1362e) #16 0x0000778d6e4d0e27 n/a (libQt5Core.so.5 + 0x2d0e27) #17 0x0000778d67b3f634 _ZN23PowerDevilUPowerBackend24brightnessSupportQueriedEb (powerdevilupowerbackend.so + 0x8634) #18 0x0000778d6e4d0e27 n/a (libQt5Core.so.5 + 0x2d0e27) #19 0x0000778d6efec56a _ZN4KJob6resultEPS_NS_14QPrivateSignalE (libKF5CoreAddons.so.5 + 0x5e56a) #20 0x0000778d6eff253c n/a (libKF5CoreAddons.so.5 + 0x6453c) #21 0x0000778d6e4d0e27 n/a (libQt5Core.so.5 + 0x2d0e27) #22 0x0000778d67b607bd n/a (kauth_helper_plugin.so + 0xa7bd) #23 0x0000778d67b610a1 n/a (kauth_helper_plugin.so + 0xb0a1) #24 0x0000778d6ef2e76e n/a (libQt5DBus.so.5 + 0x2176e) #25 0x0000778d6e4c3964 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2c3964) #26 0x0000778d6e49bef8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x29bef8) #27 0x0000778d6e4a0e5b _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x2a0e5b) #28 0x0000778d6e4e6ec8 n/a (libQt5Core.so.5 + 0x2e6ec8) #29 0x0000778d6d10df69 n/a (libglib-2.0.so.0 + 0x59f69) #30 0x0000778d6d16c367 n/a (libglib-2.0.so.0 + 0xb8367) #31 0x0000778d6d10c162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162) #32 0x0000778d6e4ead0c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ead0c) #33 0x0000778d6e49ac04 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x29ac04) #34 0x0000778d6e49c0a3 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x29c0a3) #35 0x000062a49f66655b n/a (org_kde_powerdevil + 0x655b) #36 0x0000778d6dc45cd0 n/a (libc.so.6 + 0x27cd0) #37 0x0000778d6dc45d8a __libc_start_main (libc.so.6 + 0x27d8a) #38 0x000062a49f667045 n/a (org_kde_powerdevil + 0x7045)

Stack trace of thread 21112: #0 0x0000778d6dd2c73d syscall (libc.so.6 + 0x10e73d) #1 0x0000778d6d1672f7 g_cond_wait (libglib-2.0.so.0 + 0xb32f7) #2 0x0000778d6d0d91b4 n/a (libglib-2.0.so.0 + 0x251b4) #3 0x0000778d6d141a8e n/a (libglib-2.0.so.0 + 0x8da8e) #4 0x0000778d6d13fa05 n/a (libglib-2.0.so.0 + 0x8ba05) #5 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #6 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc)

Stack trace of thread 21110: #0 0x0000778d6dca74ae n/a (libc.so.6 + 0x894ae) #1 0x0000778d6dca9d40 pthread_cond_wait (libc.so.6 + 0x8bd40) #2 0x0000778d6e2fb524 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xfb524) #3 0x0000778d68523004 n/a (libQt5WaylandClient.so.5 + 0x73004) #4 0x0000778d6e2f379a n/a (libQt5Core.so.5 + 0xf379a) #5 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #6 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc)

Stack trace of thread 21111: #0 0x0000778d6dd20f6f __poll (libc.so.6 + 0x102f6f) #1 0x0000778d6852305d n/a (libQt5WaylandClient.so.5 + 0x7305d) #2 0x0000778d6e2f379a n/a (libQt5Core.so.5 + 0xf379a) #3 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #4 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc)

Stack trace of thread 21113: #0 0x0000778d6dd20f6f __poll (libc.so.6 + 0x102f6f) #1 0x0000778d6d16c2b6 n/a (libglib-2.0.so.0 + 0xb82b6) #2 0x0000778d6d10c162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162) #3 0x0000778d6d10c1b2 n/a (libglib-2.0.so.0 + 0x581b2) #4 0x0000778d6d13fa05 n/a (libglib-2.0.so.0 + 0x8ba05) #5 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #6 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc)

Stack trace of thread 21114: #0 0x0000778d6dd20f6f __poll (libc.so.6 + 0x102f6f) #1 0x0000778d6d16c2b6 n/a (libglib-2.0.so.0 + 0xb82b6) #2 0x0000778d6d10eb97 g_main_loop_run (libglib-2.0.so.0 + 0x5ab97) #3 0x0000778d68d4d19c n/a (libgio-2.0.so.0 + 0x11219c) #4 0x0000778d6d13fa05 n/a (libglib-2.0.so.0 + 0x8ba05) #5 0x0000778d6dcaa9eb n/a (libc.so.6 + 0x8c9eb) #6 0x0000778d6dd2e7cc n/a (libc.so.6 + 0x1107cc) ELF object binary architecture: AMD x86-64

[solarisfire]

This issue is pretty widespread :(

[nicolasfella]

Backtrace from https://bugs.kde.org/show_bug.cgi?id=480030

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {206158430256}}
        ret = <optimized out>
#1  0x000077fb998ac8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x000077fb9985c668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x000077fb998444b8 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140728311536560, 96582981365184, 96582981365184, 96582980837392, 0, 12884901656, 0, 140728311536744, 0, 5, 140728311536592, 131922497604720, 131922497642944, 18446744073709551384, 2, 131922402651749}}, sa_flags = -1718897837, sa_restorer = 0x77fb999f5070 <_IO_file_jumps>}
#4  0x000077fb998443dc in __assert_fail_base
    (fmt=0x77fb999bdae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x77fb93f30d95 "sys_drm_connectors", file=file@entry=0x77fb93f2ae65 "i2c_bus_core.c", line=line@entry=614, function=function@entry=0x77fb93f56ec8 <__PRETTY_FUNCTION__.13> "i2c_check_bus") at assert.c:92
        str = 0x57d77a4badc0 "J\033;\a\322W"
        total = 4096
#5  0x000077fb99854d26 in __assert_fail
    (assertion=assertion@entry=0x77fb93f30d95 "sys_drm_connectors", file=file@entry=0x77fb93f2ae65 "i2c_bus_core.c", line=line@entry=614, function=function@entry=0x77fb93f56ec8 <__PRETTY_FUNCTION__.13> "i2c_check_bus")
    at assert.c:101
#6  0x000077fb93ee92b9 in i2c_check_bus (bus_info=0x57d77a4b3750) at i2c/i2c_bus_core.c:614
        __func__ = "i2c_check_bus"
        __PRETTY_FUNCTION__ = "i2c_check_bus"
#7  0x000077fb93eebf35 in i2c_non_async_scan (i2c_buses=0x57d77a4b3f00) at i2c/i2c_bus_core.c:828
        businfo = 0x57d77a4b3750
        ndx = 0
        debug = false
        i2c_bus_bva = <optimized out>
        buses = 0x57d77a4b3f00
        __func__ = "i2c_detect_buses0"
#8  i2c_detect_buses0 () at i2c/i2c_bus_core.c:901
        i2c_bus_bva = <optimized out>
        buses = 0x57d77a4b3f00
        __func__ = "i2c_detect_buses0"
#9  0x000077fb93eec1f5 in i2c_detect_buses () at i2c/i2c_bus_core.c:970
        result = <optimized out>
        __func__ = "i2c_detect_buses"
#10 0x000077fb93f1016b in ddci_init (libopts=<optimized out>, syslog_level_arg=<optimized out>, opts=<optimized out>, infomsg_loc=<optimized out>) at libmain/api_base.c:700
        debug = <optimized out>
        s = <optimized out>
        parsed_cmd = <optimized out>
        master_error = <optimized out>
        ddcrc = 0
        __func__ = "ddci_init"
        __PRETTY_FUNCTION__ = "ddci_init"
#11 0x000077fb93f178a2 in ddca_get_display_info_list2 (include_invalid_displays=<optimized out>, dlist_loc=0x7ffddd04df78) at libmain/api_displays.c:983
        filtered_ct = <optimized out>
        ddcrc = <optimized out>
        filtered_displays = <optimized out>
        reqd_size = <optimized out>
        result_list = <optimized out>
        curinfo = <optimized out>
        __func__ = "ddca_get_display_info_list2"
#12 0x000077fb94500d37 in DDCutilBrightness::detect() (this=0x57d77a497bc0) at /usr/src/debug/powerdevil/powerdevil-5.27.10/daemon/backends/upower/ddcutilbrightness.cpp:52
        rc = <optimized out>
        dlist = 0x0
#13 0x000077fb9450262e in PowerDevilUPowerBackend::initWithBrightness(bool) (this=0x57d77a4a20e0, screenBrightnessAvailable=false)
    at /usr/src/debug/powerdevil/powerdevil-5.27.10/daemon/backends/upower/powerdevilupowerbackend.cpp:156
        controls = {{d = 0x0, e = 0x0}}

[Adiker]

I also experience this issue, it's pretty serious in my opinion. Downgraded to earlier version temporarily, but I hope this gets resolved ASAP.

[Kamilcuk]

My powerdevil is also restarting in a loop. I found sample_clients/clmain.c that reproduces the problem on my system. I have no idea how to ./configure to compile the samples. Anyway, I prepared myself the following script:

#!/bin/bash
set -xeuo pipefail
git clean -fdx
if ! (
	trap 'git checkout ./configure.ac' EXIT &&
	NOCONFIGURE=1 ./autogen.sh &&
	./configure --prefix=/home/kamil/tmp/prefix CFLAGS='-ggdb3 -O0' DBG=1 --with-gnu-ld --disable-doxygen-doc --enable-drm=no &&
	make -j &&
	gcc src/sample_clients/clmain.c -I src/ -L src/.libs/ -lddcutil -Wl,-rpath,src/.libs
); then
	# skip
	exit 125
fi
if ! ./a.out; then
     exit 1
fi

Then I started bisecting:

git bisect start master v2.0.0
git bisect run ../script.sh

And continued drinking my sour beer. After a few back-and-forth fixes and cycles with the bisecting, I found this guy to blame:

3808a0ad55cb2315ca3c53c42e58b0049939fb5f is the first bad commit

No wonder - it just introduces assert(sys_drm_connectors); into i2c_check_bus

Just blindly checking out master and removing the assertion makes the sample execute successfully for me. So is the assertion needed there? It is hard to analyze the call flow.

edit Just moving the assertion just a few lines below makes it not fire anymore:

 */
void i2c_check_bus(I2C_Bus_Info * bus_info) {
   bool debug = false;
   DBGTRC_STARTING(debug, TRACE_GROUP, "busno=%d, bus_info=%p", bus_info->busno, bus_info );
   DBGTRC_NOPREFIX(debug, DDCA_TRC_NONE, "force_read_edid=%s", sbool(force_read_edid));
   assert(bus_info && ( memcmp(bus_info->marker, I2C_BUS_INFO_MARKER, 4) == 0) );
   assert( (bus_info->flags & I2C_BUS_EXISTS) &&
           (bus_info->flags & I2C_BUS_VALID_NAME_CHECKED) &&
           (bus_info->flags & I2C_BUS_HAS_VALID_NAME)
         );

   if (!(bus_info->flags & I2C_BUS_PROBED)) {
      DBGTRC_NOPREFIX(debug, DDCA_TRC_NONE, "Probing");
      bus_info->flags |= I2C_BUS_PROBED;
      bus_info->driver = get_driver_for_busno(bus_info->busno);
      char * connector = get_drm_connector_name_by_busno(bus_info->busno);
	   assert(sys_drm_connectors);

It looks like get_drm_connector_name_by_busno initializes sys_drm_connectors. Analyzing the call graph it happens in get_drm_connector_name_by_busno -> find_sys_drm_connector_by_busno -> find_sys_drm_connector -> if (!sys_drm_connectors) sys_drm_connectors = scan_sys_drm_connectors(-1);. The variable is just getting initialized.

Bottom line, so I think, the assertion just shouldn't be there. With that in mind, I'll create a pull request.

[Randommist]

It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem

[Kamilcuk]

It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem

Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25

[rockowitz]

Commit 7f157f6 in branch 2.1.1-dev is the proper solution to the asserti(sys_drm_connectors) failure. PowerDevil uses the libddcutil API in an unexpected way, and because of a bug in libddcutil initialization, sys_drm_connectors was not being set. A more detailed explanation can be found in the commit message.

[Dankitymao]

It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem

Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25

All that does is disable assertions entirely, which you don't really want to do long-term, heh. As rockowitz mentioned, 2.1.1-dev fixes the actual issue which is an uninitialized sys_drm_connectors because of how PowerDevil uses the API.

[jpetso]

PowerDevil uses the libddcutil API in an unexpected way, and because of a bug in libddcutil initialization, sys_drm_connectors was not being set.

Thanks.

This would also mean that starting from Plasma 6.0 RC1, which explicitly calls ddca_init() before making any other API calls, it should be safe to use libddcutil 2.1.0. The issue was reported for Plasma 5.27, which is in bugfix-only mode and has not been targeting the new 2.0 API explicitly. @nicolasfella, maybe we want to backport the ddca_init() call to the 5.27 branch as well to provide a second layer of fixing?

[rockowitz]

I have pulled the code from the powerdevil master branch. Unfortunately, I don't have the KDE infrastructure to build it. What I can say is that I earlier saw the PowerDevil crash problem when booted in Fedora 39. and could recreate it in gdb. With libddcutil built from the current ddcutil 5.1.1-dev branch, the assert() failure did not occur.

[Randommist]

It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem

Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25

I really didn't go into detail about how this was solved, but it seems that now a commit named "Fix crashes in powerdevil properly" solves the problem as it should

[Dankitymao]

It seems that arch has released an update ddcutil-2.1.0-2 that solved this problem

Well, yea, -DNDEBUG is the ultimate solution. https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/blob/main/PKGBUILD?ref_type=heads#L25

I really didn't go into detail about how this was solved, but it seems that now a commit named "Fix crashes in powerdevil properly" solves the problem as it should

It's taking rockowitz' patch and applying it to the existing codebase, so yeah, this one actually fixes it correctly :)