SIGSEGV in rpt_lsof_collect0 during suspend resume

[kerneltoast]

FYI, I generated this report using AI. I got this crash while on 2.2.7-DEV (specific commit mentioned below).

---

Summary

powerdevil (KDE Power Management) crashes with SIGSEGV when resuming from suspend (opening laptop lid). The crash is in ddcutil 2.2.7-DEV's new open-failure diagnostic code path, specifically a null pointer dereference in rpt_lsof_collect0.

Environment

• OS: Arch Linux (x86_64)
• Kernel: 6.18.6
• Wayland compositor: KWin 6.6.3
• GPU: AMD (amdgpu, DCN 3.5.1)
• ddcutil: 2.2.7-DEV (built from master branch, commit d7c0379)
• powerdevil: 6.6.3

Trigger

Opening the laptop lid to resume from suspend. The laptop's eDP display generates I2C bus change events during resume. ddcutil's watch thread detects the screen change and attempts to re-enumerate I2C buses, but one bus is transiently unavailable. The open fails, and the new diagnostic code crashes while trying to log the failure.

Crash details

• Signal: 11 (SIGSEGV)
• Faulting instruction: mov 0x8(%rax),%edx at offset 0x7f0f9 in libddcutil.so.5 (rpt_lsof_collect0), where %rax is null/invalid

Stack trace (crashing thread)

Symbols resolved via addr2line against the unstripped build of libddcutil.so.5.5.0:

#0  __pthread_kill_implementation (pthread_kill.c:44)
#1  __pthread_kill_internal (pthread_kill.c:89)
#2  __GI_raise (raise.c:26)
#3  KCrash::defaultCrashHandler (kcrash.cpp:623)
#4  <signal handler called>
#5  rpt_lsof_collect0                      <-- SIGSEGV here (null pointer dereference)
#6  diagnose_open_failure_collect
#7  diagnose_open_failure_to_syslog
#8  i2c_open_bus_basic                     <-- I2C bus open failed, entered diagnostic path
#9  i2c_open_bus
#10 i2c_edid_exists
#11 i2c_filter_buses_w_edid_as_bitset
#12 process_screen_change_event            <-- ddcutil watch detected screen change (dw_poll.c)
#13 dw_watch_display_connections           <-- ddcutil display watch thread
#14 dw_recheck_displays_func              <-- ddcutil recheck thread entry
#15 g_thread_proxy (gthread.c:893)         <-- glib thread pool

Other threads at time of crash

• Main thread (237773): idle in QCoreApplication::exec() event loop
• Thread 237815: ddcutil recheck thread waiting in g_async_queue_timeout_pop (normal idle state)
• Thread 237780: glib worker thread (g_main_context_iteration)
• Threads 237777, 237778: Qt Wayland client threads (poll)
• Thread 237774: Qt DBus thread
• Thread 237781: GIO D-Bus shared thread
• Thread 237779: glib thread pool (g_async_queue_pop, idle)

Analysis

The crash is in the new open-failure diagnostic functions added in the recent commits:

• d14ab57 i2c_open_bus_basic(): use diagnose open_failure_to_syslog() if error
• 4815b1a add and modify functions for diagnosing unexpected open() failure

When i2c_open_bus_basic() fails to open an I2C bus (which is expected during suspend/resume when buses are transiently unavailable), it calls diagnose_open_failure_to_syslog(), which calls diagnose_open_failure_collect(), which calls rpt_lsof_collect0(). The rpt_lsof_collect0 function dereferences a pointer at offset +8 that is null, causing the SEGV.

The I2C bus open failure itself is benign (transient unavailability during resume). The crash is in the diagnostic/logging code that handles the failure, not in the core detection logic.

Attachments

• Crash trace: powerdevil_20260331.txt
• GDB backtrace (debuginfod-resolved symbols for libc/glib/KCrash): gdb-debuginfod-output.txt
• Unstripped libddcutil build from commit d7c0379, for symbol resolution: libddcutil.so.5.5.0.gz
• Coredump: core.org_kde_powerde.1000.4e8ab4a77bff4ddcb823fc3f3ef6527e.237773.1774968497000000.gz

To resolve ddcutil symbols against the provided unstripped library, use addr2line with offsets relative to the libddcutil.so.5 base address (0x7f14faed0000 in this core):

addr2line -e libddcutil.so.5.5.0 -f -C -p 0x7f0f9 0x7f2bf 0x7f30e 0x30381 0x3081d 0x34fe7 0x36d97 0x91003 0x92278

---

This report was generated with AI assistance (Claude Opus 4.6, Anthropic).

[rockowitz]

Thanks for the detailed bug report. The one additional thing I would like to see is the journalctl -t org_kde_powerdevll output at the time of the crash, preferably beginning with the line "Starting libddcutil"" prior to the crash.

What I expect is that there will be a line starting with "Unable to execute command" and that command lsof is not present on your system.

Can you describe how you used Claude Opus to generate the report? I'm very curious. I've just started playing with Claude Code, but I'm still in the "Hello, World!" phase.

[kerneltoast]

Thanks for the detailed bug report. The one additional thing I would like to see is the journalctl -t org_kde_powerdevll output at the time of the crash, preferably beginning with the line "Starting libddcutil"" prior to the crash.

What I expect is that there will be a line starting with "Unable to execute command" and that command lsof is not present on your system.

Oh huh, it's an i2c permission issue: Open failed for /dev/i2c-9, errno=EACCES(-13): Permission denied in file i2c_bus_core.c near line 355

Here's the full log of what you asked for: powerdevil-log.txt

Can you describe how you used Claude Opus to generate the report? I'm very curious. I've just started playing with Claude Code, but I'm still in the "Hello, World!" phase.

I had started by asking Claude to debug my powerdevil crash, and I gave it the trace and coredump. I also asked to check upstream to see if the bug has already been either reported or fixed.


To generate the report, this is what I told Claude:

Generate a report for me to give to ddcutil upstream, output it to an .md file and tell me what to attach to the report. Disclose that the report was generated with AI.

And then there was a little bit of back and forth with Claude to tweak some things in the report, like adding the specific commit hash of ddcutil I was using and that I also need to provide the unstripped library in addition to what it already determined I should attach.

Results with Claude and AI in general vary... a lot. I've gone to lengths to configure Claude for "maximum quality" because anything less and Claude is pretty useless to me. There is also quality fluctuation that happens a lot without being communicated to you transparently, so you need to be vigilant and call it quits when it's clear that Claude is going to be worthless at some given time. One such fluctuation occurs due to lots of people using Claude at once, which results in slower responses and/or lower quality responses (i.e., Claude suddenly becomes dumb). Other big AIs have this shortcoming as well.

My advice with Claude is to use Opus 4.6 with a 1 million token context window, and make the following tweaks in addition:

1. Add this into ~/.claude/settings.json to increase the output token limit, so that Claude can actually reason about complex prompts without getting cut off due the limit and suddenly giving a dumb response instead:

  "env": {
    "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "128000"
  }

2. Enable sandboxing so that Claude won't prompt you for permission for every little thing at least within the directory you run claude from. It'll give Claude free reign specifically within the working directory.
3. There is an effort level knob for Opus 4.6 with the following values: low, medium, and high. Or so it seems, because there is actually another effort level that only ever persists for your current session: max. You can't configure 'max' to be the effort level by default when you run claude; there's simply no way to do it. So I have a bash alias to specify 'max' as the effort level whenever I run claude: alias claude='claude --effort max'

And then just speak in plain English to Claude as if you were speaking to a fellow engineer.

[rockowitz]

@kerneltoast Re:

Oh huh, it's an i2c permission issue: Open failed for /dev/i2c-9, errno=EACCES(-13): Permission denied in file i2c_bus_core.c near line 355

I wanted to see the log for two reasons. First, to better understand the segfault in the new diagnostic functions. The low level functions that execute a CLI command were written years ago, when there was only ddcutil, not libddcutil, and they wrote error messages to stderr. Since Plasma redirects stdout and stderr to the system log, I would have expected to see messages there.

I've pushed changes to 2.2.7-dev that address the segfault resulting from an unexpected failure of command lsof and that better captures errors from CLI commands.

The second was to better understand the events that led to the open() failure. Your explanation that the open failure is a transient one because /dev/i2c devices are immediately available upon resume would explain a lot of the transient permission errors that have baffled me for the past couple months. I'm not sure it explains them all, and it's unfortunate that errno EACCES is used in this case. I'm working on more diagnostic code for detecting this situation.

Finally, thank you so much for your detailed description of how you're using Claude. That's very helpful to me. A project that's been on the TODO list forever has been to put a Python wrapper on the C API. With Claude Code it looks like the scale of the project will be an order of magnitude less.

[rockowitz]

Function diagnose_open_failure_to_syslog(), which is called when open() on a /dev/i2c device fails, now includes a check of DBUS property IdleSinceHintMonotonic to determine if the system recently resumed from sleep. Purely informational at this point, but if it indeed tracks with transient open failures then it can be used to trigger retry. If you encounter more EACCES failures on /dev/i2c devices, please submit the relevant Journalctl output. Thank you.

[kerneltoast]

If you encounter more EACCES failures on /dev/i2c devices, please submit the relevant Journalctl output.

Yes, I can replicate the EACCES failure on demand by triggering a quick suspend/resume cycle with amd-s2idle test --count 1 --duration 1 --wait 1 --format stdout. I dug quite deeply into the kernel to find out why, and found out that it's some race with ACL.

I asked Claude to analyze it the rest of the way and got this (see below). I'll look more into Claude's analysis here tomorrow to verify Claude's claims in the kernel.

My prompt:

I am trying to find out why a component of ddcutil hits -EACCES upon trying to open() a /dev/i2c-* file shortly after resuming from suspend on my laptop. The failure is transient; it seems like some sort of narrow race condition. I have found the root of the issue but do not understand why: when the issue occurs, in acl_permission_check() mask=38 and mode=8624. When the issue doesn't occur, mask=129 and mode=16877. See ./ddcutil-kernel-log.txt for a full kernel log. Can you help me understand what the differing mask/mode values mean and why there is a difference sometimes?

Claude's response:

Here's the full analysis.

Decoding the values

mask=129 / mode=16877 (the "success" check):

• mask = 129 = 0x81 = MAY_NOT_BLOCK | MAY_EXEC -- this is a directory traversal check (execute permission to search a directory), done in RCU mode
• mode = 16877 = 0o40755 = S_IFDIR | rwxr-xr-x -- this is the /dev directory itself

mask=38 / mode=8624 (the check that sometimes fails):

• mask = 38 = 0x26 = MAY_OPEN | MAY_READ | MAY_WRITE -- this is the actual file open check for read+write access
• mode = 8624 = 0o20660 = S_IFCHR | rw-rw---- -- this is the /dev/i2c-N character device node (owner rw, group rw, no others)

These are not two different outcomes; they are two steps in the same open()

Every open("/dev/i2c-N", O_RDWR) always triggers both checks in sequence:

1. Directory check on /dev: mask=129, mode=16877 -- always passes (everyone has execute on /dev)
2. File check on /dev/i2c-N: mask=38, mode=8624 -- this is where the race manifests

The mask/mode values are identical in both the success and failure cases. The only difference is what check_acl() returns at fs/namei.c:433: error=0 (success) vs error=-13 (EACCES).

Why the fast path doesn't help

The fast path at line 403 checks !((mask & 7) * 0111 & ~mode). For the device file:

• mask & 7 = 6 (read + write)
• 6 * 0111(octal) = 0666(octal) -- spreads rw to user, group, and other
• & ~mode -- the "other" bits in mode are --- (zero), so this is nonzero
• Fast path fails because the "other" permission bits don't grant rw

The code then checks owner (not matching, ddcutil isn't root), then falls into the POSIX ACL path at line 430-435 because IS_POSIXACL(inode) is true on devtmpfs and mode & S_IRWXG is nonzero (the group bits are rw-).

The actual race: check_acl() and udev

Looking at check_acl() (line 317-344): since mask=38 does NOT include MAY_NOT_BLOCK, it takes the blocking path, calling get_inode_acl() to fetch the POSIX ACL and then posix_acl_permission() to evaluate it.

Your log shows the race clearly:

Time	Device	Result
59.899s	/dev/i2c-9	error=-13 (EACCES)
59.921s	/dev/i2c-10	error=-13
59.927s	/dev/i2c-11	error=-13
59.933s	/dev/i2c-12	error=-13
59.938s	/dev/i2c-13	error=-13
59.944s	/dev/i2c-14	error=-13
59.951s	/dev/i2c-15	error=0 (first success!)
59.951s	/dev/i2c-16	error=-13 (back to failing)
59.958s+	later devices	error=0 (all succeed)

After resume, the i2c adapter drivers re-create their devices. udev receives the uevents and processes rules asynchronously to set POSIX ACLs (likely via TAG+="uaccess" or a similar rule that calls setfacl to add a user:sultan:rw- ACL entry). There is a race window between device node creation and udev ACL application. ddcutil hits that window for the early i2c buses.

When the ACL entry for your user doesn't exist yet, posix_acl_permission() finds no matching ACL entry and returns -EACCES. Once udev catches up and applies the ACL, the same check finds the user:sultan:rw- entry and returns 0.

[rockowitz]

That's impressive sleuthing. So much more makes sense, though I'm not sure that it explains the transient loss of permissions reported on first login.

Can you send me the relevant section of the system log showing diagnostics for the open() failure? I want to see what it's reporting as the "millisec since returned from sleep" value.

[kerneltoast]

That's impressive sleuthing. So much more makes sense, though I'm not sure that it explains the transient loss of permissions reported on first login.

What error have you seen on first login? Is it also EACCES?

Can you send me the relevant section of the system log showing diagnostics for the open() failure? I want to see what it's reporting as the "millisec since returned from sleep" value.

ddcutil-i2c-fail-log.txt

[kerneltoast]

You can see the ACL race in my log: for some of the i2c nodes, getfacl shows that my user (sultan) isn't there:

Apr 03 22:03:33.884225 org_kde_powerdevil[90755]: [ 90875]    Open failed for /dev/i2c-9, errno=EACCES(-13): Permission denied in file i2c_bus_core.c near line 360
Apr 03 22:03:33.884228 org_kde_powerdevil[90755]: [ 90875]         uid: 1000=sultan, euid: 1000=sultan, gid: 1000=sultan, egid: 1000=sultan
Apr 03 22:03:33.884230 org_kde_powerdevil[90755]: [ 90875]         file owner: 0=root, file group: 967=i2c
Apr 03 22:03:33.884232 org_kde_powerdevil[90755]: [ 90875]    Using command getfacl:
Apr 03 22:03:33.884235 org_kde_powerdevil[90755]: [ 90875]    getfacl: Removing leading '/' from absolute path names
Apr 03 22:03:33.884236 org_kde_powerdevil[90755]: [ 90875]    # file: dev/i2c-9
Apr 03 22:03:33.884239 org_kde_powerdevil[90755]: [ 90875]    # owner: root
Apr 03 22:03:33.884241 org_kde_powerdevil[90755]: [ 90875]    # group: i2c
Apr 03 22:03:33.884243 org_kde_powerdevil[90755]: [ 90875]    user::rw-
Apr 03 22:03:33.884245 org_kde_powerdevil[90755]: [ 90875]    group::rw-        #effective:rw-
Apr 03 22:03:33.884246 org_kde_powerdevil[90755]: [ 90875]    mask::rw-
Apr 03 22:03:33.884247 org_kde_powerdevil[90755]: [ 90875]    other::---
Apr 03 22:03:33.884248 org_kde_powerdevil[90755]: [ 90875]
Apr 03 22:03:33.884249 org_kde_powerdevil[90755]: [ 90875]    Using acl api:
Apr 03 22:03:33.884252 org_kde_powerdevil[90755]: [ 90875]     user::rw-
Apr 03 22:03:33.884253 org_kde_powerdevil[90755]: [ 90875]     group::rw-
Apr 03 22:03:33.884255 org_kde_powerdevil[90755]: [ 90875]     mask::rw-
Apr 03 22:03:33.884257 org_kde_powerdevil[90755]: [ 90875]     other::---
Apr 03 22:03:33.884259 org_kde_powerdevil[90755]: [ 90875]    sh: line 1: lsof: command not found
Apr 03 22:03:33.884262 org_kde_powerdevil[90755]: [ 90875]    millisec_since_returned_from_sleep(): 12673525
Apr 03 22:03:33.884264 org_kde_powerdevil[90755]: [ 90875]    interval_millis: 5000, recently returned = false

And then for another one my user is present in the ACL even though the open() failed, because the ACL was applied after the open() but before the getfacl:

Apr 03 22:03:33.902064 org_kde_powerdevil[90755]: [ 90875]    Open failed for /dev/i2c-11, errno=EACCES(-13): Permission denied in file i2c_bus_core.c near line 360
Apr 03 22:03:33.902071 org_kde_powerdevil[90755]: [ 90875]         uid: 1000=sultan, euid: 1000=sultan, gid: 1000=sultan, egid: 1000=sultan
Apr 03 22:03:33.902073 org_kde_powerdevil[90755]: [ 90875]         file owner: 0=root, file group: 967=i2c
Apr 03 22:03:33.902076 org_kde_powerdevil[90755]: [ 90875]    Using command getfacl:
Apr 03 22:03:33.902078 org_kde_powerdevil[90755]: [ 90875]    getfacl: Removing leading '/' from absolute path names
Apr 03 22:03:33.902081 org_kde_powerdevil[90755]: [ 90875]    # file: dev/i2c-11
Apr 03 22:03:33.902083 org_kde_powerdevil[90755]: [ 90875]    # owner: root
Apr 03 22:03:33.902085 org_kde_powerdevil[90755]: [ 90875]    # group: i2c
Apr 03 22:03:33.902087 org_kde_powerdevil[90755]: [ 90875]    user::rw-
Apr 03 22:03:33.902089 org_kde_powerdevil[90755]: [ 90875]    user:sultan:rw-        #effective:rw-
Apr 03 22:03:33.902092 org_kde_powerdevil[90755]: [ 90875]    group::rw-        #effective:rw-
Apr 03 22:03:33.902094 org_kde_powerdevil[90755]: [ 90875]    mask::rw-
Apr 03 22:03:33.902096 org_kde_powerdevil[90755]: [ 90875]    other::---
Apr 03 22:03:33.902098 org_kde_powerdevil[90755]: [ 90875]
Apr 03 22:03:33.902100 org_kde_powerdevil[90755]: [ 90875]    Using acl api:
Apr 03 22:03:33.902102 org_kde_powerdevil[90755]: [ 90875]     user::rw-
Apr 03 22:03:33.902104 org_kde_powerdevil[90755]: [ 90875]     user:sultan:rw-
Apr 03 22:03:33.902106 org_kde_powerdevil[90755]: [ 90875]     group::rw-
Apr 03 22:03:33.902108 org_kde_powerdevil[90755]: [ 90875]     mask::rw-
Apr 03 22:03:33.902110 org_kde_powerdevil[90755]: [ 90875]     other::---
Apr 03 22:03:33.902112 org_kde_powerdevil[90755]: [ 90875]    sh: line 1: lsof: command not found
Apr 03 22:03:33.902114 org_kde_powerdevil[90755]: [ 90875]    millisec_since_returned_from_sleep(): 12673543
Apr 03 22:03:33.902116 org_kde_powerdevil[90755]: [ 90875]    interval_millis: 5000, recently returned = false