GNU bug report logs -
#78793
sc-controller crashes after commit: 9bc97424d347901e6b70b5477a1066359f3d6f2c
Previous Next
To reply to this bug, email your comments to 78793 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#78793
; Package
guix
.
(Sun, 15 Jun 2025 01:55:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Fredrik Salomonsson <plattfot <at> posteo.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 15 Jun 2025 01:55:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
I've been using the sc-controller package for over a year — I had the
patches from https://issues.guix.gnu.org/58403 applied to my own channel
while I waited for it to be reviewed and merged in the main channel.
Which look like it was around three weeks ago. But it looks like
something broke between May 24 — commit
9bc97424d347901e6b70b5477a1066359f3d6f2c — and May 31 — commit
fd1d786e4574854093f31f52a7898560a609304a. As when I did a pull on May
31 I'm getting this when launching it:
```
guix shell sc-controller -- sc-controller
substitute: looking for substitutes on 'https://substitutes.nonguix.org'... 100.0%
substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0%
2,1 MB will be downloaded
sc-controller-0.4.8.9 2.0MiB 1.4MiB/s 00:01 ▕██████████████████▏ 100.0%
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
thread '<unnamed>' panicked at /tmp/guix-build-librsvg-2.58.5.drv-0/librsvg-2.58.5/guix-vendor/rust-glib-0.19.9.tar.gz/src/subclass/types.rs:999:9:
assertion `left == right` failed: Type RsvgHandle has already been registered
left: 911974304
right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
0: 0x7f6a2b4179bd - <unknown>
1: 0x7f6a2b4424f3 - <unknown>
2: 0x7f6a2b4258b9 - <unknown>
3: 0x7f6a2b42915f - <unknown>
4: 0x7f6a2b428d88 - <unknown>
5: 0x7f6a2b429705 - <unknown>
6: 0x7f6a2b417d75 - <unknown>
7: 0x7f6a2b417bc9 - <unknown>
8: 0x7f6a2b4292e4 - <unknown>
9: 0x7f6a2b0c45d5 - <unknown>
10: 0x7f6a2b0c4662 - <unknown>
11: 0x7f6a2b0c47a6 - <unknown>
12: 0x7f6a2b0c71c9 - rsvg_handle_get_type
13: 0x7f6a4ebb7d0e - g_registered_type_info_get_g_type
14: 0x7f6a4ed4aebd - <unknown>
15: 0x7f6a4f5b95b2 - <unknown>
16: 0x7f6a4f563f32 - PyObject_Vectorcall
17: 0x7f6a4f5040dd - _PyEval_EvalFrameDefault
18: 0x7f6a4f669d71 - <unknown>
19: 0x7f6a4f5672e8 - <unknown>
20: 0x7f6a4f56469c - PyObject_CallOneArg
21: 0x7f6a4f5dc0c2 - <unknown>
22: 0x7f6a4f5bd7d7 - PyObject_GetAttr
23: 0x7f6a4f502b39 - _PyEval_EvalFrameDefault
24: 0x7f6a4f669d71 - <unknown>
25: 0x7f6a4f564b2e - _PyObject_Call_Prepend
26: 0x7f6a4f5dd947 - <unknown>
27: 0x7f6a4f5d4657 - <unknown>
28: 0x7f6a4f5631f5 - _PyObject_MakeTpCall
29: 0x7f6a4f5040dd - _PyEval_EvalFrameDefault
30: 0x7f6a4f669d71 - <unknown>
31: 0x7f6a4ed57c48 - <unknown>
32: 0x7f6a4eb3c931 - <unknown>
33: 0x7f6a4eb3d1e8 - <unknown>
34: 0x7f6a4eb5b929 - <unknown>
35: 0x7f6a4eb7063b - <unknown>
36: 0x7f6a4eb75b55 - g_signal_emit_valist
37: 0x7f6a4eb75c02 - g_signal_emit
38: 0x7f6a4d7d88f2 - g_application_register
39: 0x7f6a4d7d8d20 - <unknown>
40: 0x7f6a4d7d908e - g_application_run
41: 0x7f6a4eb3d052 - <unknown>
42: 0x7f6a4eb3bc85 - <unknown>
43: 0x7f6a4eb3c68e - ffi_call
44: 0x7f6a4ed5a537 - <unknown>
45: 0x7f6a4ed5c5ba - <unknown>
46: 0x7f6a4f5642f9 - PyObject_Call
47: 0x7f6a4f506b53 - _PyEval_EvalFrameDefault
48: 0x7f6a4f669c0f - PyEval_EvalCode
49: 0x7f6a4f6b7d7d - <unknown>
50: 0x7f6a4f6b9487 - _PyRun_SimpleFileObject
51: 0x7f6a4f6b9a9b - _PyRun_AnyFileObject
52: 0x7f6a4f6dae38 - <unknown>
53: 0x7f6a4f6db4cc - Py_BytesMain
54: 0x7f6a4f16bbf7 - __libc_start_call_main
55: 0x7f6a4f16bcac - __libc_start_main <at> GLIBC_2.2.5
56: 0x401071 - _start
57: 0x0 - <unknown>
thread caused non-unwinding panic. aborting.
```
It works fine before that, for example here is the generation I'm
currently running that works:
```
Generation 50 maj 24 2025 14:40:52 (current)
file name: /var/guix/profiles/system-50-link
canonical file name: /gnu/store/4y0vk93rgzwcvf4fjvz6c8djdxjwpg2r-system
label: GNU with Linux 6.14.7
bootloader: grub-efi
root device: label: "guix-root"
kernel: /gnu/store/hc2ksndxbar6n5vfi85hnm5b7kvpyfnd-linux-6.14.7/bzImage
channels:
plt:
repository URL: https://git.sr.ht/~plattfot/plt
branch: master
commit: 5ff3981e9e95160c86239f09617f6bdcb75a68c4
nonguix:
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 7152e92a13edf3e9a356e7b9b759b163aed3044c
guix:
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 9bc97424d347901e6b70b5477a1066359f3d6f2c
```
And one that triggers that error:
```
Generation 51 maj 31 2025 20:05:25
file name: /var/guix/profiles/system-51-link
canonical file name: /gnu/store/sqh0ryd7fds737z50sadgl1k5l2zpy52-system
label: GNU with Linux 6.14.8
bootloader: grub-efi
root device: label: "guix-root"
kernel: /gnu/store/540pf10pz1q557h6sr6p2k4czfpckjdy-linux-6.14.8/bzImage
channels:
plt:
repository URL: https://git.sr.ht/~plattfot/plt
branch: master
commit: a4f0fd42fcef34a7e4228ac82ffdf8e160fc7f51
nonguix:
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 0b9e1041aec581d5426adf5fa593e12cc4b75409
guix:
repository URL: https://git.guix.gnu.org/guix.git
branch: master
commit: fd1d786e4574854093f31f52a7898560a609304a
```
I tested to update to the latest version 0.4.8.13 and also the fork of
it at https://github.com/C0rn3j/sc-controller using version 0.5.2. As
https://github.com/Ryochan7/sc-controller has been archived.
Both of these are triggering the same panic. I haven't found any
reports upstream on a similar issue. So I'm not sure if it's a bug
upstream or in guix.
Anyone has any idea what could be the issue?
--
s/Fred[re]+i[ck]+/Fredrik/g
Reply sent
to
Andreas Enge <andreas <at> enge.fr>
:
You have taken responsibility.
(Sat, 12 Jul 2025 10:06:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Fredrik Salomonsson <plattfot <at> posteo.net>
:
bug acknowledged by developer.
(Sat, 12 Jul 2025 10:06:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 78793-done <at> debbugs.gnu.org (full text, mbox):
Hello Morgan,
thanks for the updates and fixes, and for researching related issues.
I am going to push your commits.
Fredrik, I am also closing your issue; if it is not fixed, please feel
free to reopen it or to file a new one on codeberg.
Andreas
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.