Code Monkey home page Code Monkey logo

Comments (12)

Randommist avatar Randommist commented on June 24, 2024 2

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

from ddcutil.

rockowitz avatar rockowitz commented on June 24, 2024 2

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.

from ddcutil.

solarisfire avatar solarisfire commented on June 24, 2024 1

This issue is pretty widespread :(

from ddcutil.

nicolasfella avatar nicolasfella commented on June 24, 2024 1

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}}

from ddcutil.

Adiker avatar Adiker commented on June 24, 2024

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

from ddcutil.

Kamilcuk avatar Kamilcuk commented on June 24, 2024

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

obraz

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.

from ddcutil.

Kamilcuk avatar Kamilcuk commented on June 24, 2024

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

from ddcutil.

Dankitymao avatar Dankitymao commented on June 24, 2024

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.

from ddcutil.

jpetso avatar jpetso commented on June 24, 2024

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?

from ddcutil.

rockowitz avatar rockowitz commented on June 24, 2024

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.

from ddcutil.

Randommist avatar Randommist commented on June 24, 2024

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

from ddcutil.

Dankitymao avatar Dankitymao commented on June 24, 2024

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 :)

from ddcutil.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.