Irqbalance dumped core

Just going over the messages in my system’s log trying to spot issues, came across something like this:

Feb 21 15:15:16 DadsGram systemd-coredump[615]: Process 533 (irqbalance) of user 0 dumped core.
                                                
                                                Module [dso] without build-id.
                                                Module [dso]
                                                Stack trace of thread 533:
                                                #0  0x0000565244f42280 n/a (n/a + 0x0)
                                                ELF object binary architecture: AMD x86-64
Feb 21 15:15:16 DadsGram systemd[1]: Finished NetworkManager-wait-online.service.
Feb 21 15:15:16 DadsGram systemd[1]: Reached target network-online.target.
Feb 21 15:15:16 DadsGram systemd[1]: irqbalance.service: Main process exited, code=dumped, status=11/SEGV
Feb 21 15:15:16 DadsGram systemd[1]: irqbalance.service: Failed with result 'core-dump'.
Feb 21 15:15:16 DadsGram systemd[1]: Failed to start irqbalance.service.
Feb 21 15:15:16 DadsGram systemd[1]: systemd-coredump@0-609-0.service: Deactivated successfully.

Is this something that shuld concern me?

That’s not critical but is a problem obviously. Do you see a coredump running it with sudo irqbalance --oneshot and if so can you share a backtrace?

Here’s what journalctl shows:

Feb 21 19:18:05 DadsGram sudo[16631]:      dad : TTY=pts/1 ; PWD=/home/dad ; USER=root ; COMMAND=/usr/bin/irqbalance --oneshot
Feb 21 19:18:05 DadsGram sudo[16631]: pam_unix(sudo:session): session opened for user root(uid=0) by dad(uid=1000)
Feb 21 19:18:05 DadsGram sudo[16631]: pam_unix(sudo:session): session closed for user root
Feb 21 19:18:05 DadsGram irqbalance[16635]: Daemon couldn't be bound to the file-based socket.
Feb 21 19:18:05 DadsGram irqbalance[16635]: thermal: received group id (3).
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 164 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 164 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 162 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 162 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 160 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 160 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 159 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 159 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 167 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 167 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 157 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 157 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 165 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 165 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 155 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 155 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 163 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 163 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 153 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 153 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 161 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 161 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 168 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 168 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 158 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 158 affinity is now unmanaged
Feb 21 19:18:16 DadsGram irqbalance[16635]: Cannot change IRQ 166 affinity: Success
Feb 21 19:18:16 DadsGram irqbalance[16635]: IRQ 166 affinity is now unmanaged
$ sudo coredumpctl debug
Password: 
           PID: 641 (irqbalance)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Sat 2025-02-22 20:48:42 CET (4h 56min ago)
  Command Line: /usr/sbin/irqbalance --oneshot
    Executable: /usr/bin/irqbalance
 Control Group: /system.slice/irqbalance.service
          Unit: irqbalance.service
         Slice: system.slice
       Boot ID: 50b450e8ac284e96b79d0e031b75dbfc
    Machine ID: 07bcbf5dd22e4d0591fe1b4b3f2362c1
      Hostname: clear2
       Storage: /var/lib/systemd/coredump/core.irqbalance.0.50b450e8ac284e96b79d0e031b75dbfc.641.1740253722000000.zst (present)
  Size on Disk: 54.1K
       Message: Process 641 (irqbalance) of user 0 dumped core.
                
                Module [dso] without build-id.
                Module [dso]
                Stack trace of thread 641:
                #0  0x000055d79995e280 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64

GNU gdb (GDB) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-generic-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/irqbalance...
[New LWP 641]
[New LWP 652]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/irqbalance --oneshot'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055d79995e280 in nla_len () from /usr/lib64/libnl-3.so.200
[Current thread is 1 (Thread 0x55d799baa400 (LWP 641))]
(gdb) bt
#0  0x000055d79995e280 in nla_len () from /usr/lib64/libnl-3.so.200
#1  0x000055d799be1888 in handle_thermal_event () at thermal.c:384
#2  0x000055d799968851 in nl_recvmsgs_report () from /usr/lib64/libnl-3.so.200
#3  0x000055d799968fc9 in nl_recvmsgs () from /usr/lib64/libnl-3.so.200
#4  0x000055d799be1077 in receive_thermal_event () at thermal.c:464
#5  0x000055d799a48c49 in g_main_dispatch () at ../glib/gmain.c:3357
#6  0x000055d799af83fd in g_main_context_dispatch_unlocked () at ../glib/gmain.c:4208
#7  g_main_context_iterate_unlocked.isra.0 () at ../glib/gmain.c:4273
#8  0x000055d799a49d5f in g_main_loop_run () at ../glib/gmain.c:4475
#9  0x000055d799bd8ea6 in main () at irqbalance.c:727
(gdb)

This is where it’s breaking:

So the question is what is actually in attrs[THERMAL_GENL_ATTR_CAPACITY]?

Upon further investigation, there’s a newer version of libnl that adds a check on the value passed to nla_len before de-referencing it, so I’ll try to update that package.

** updated libnl to 3.11.0-27 – as usual, wait a few days for a new release that includes it.

2 Likes