From: John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org>
To: 52651@debbugs.gnu.org
Subject: bug#52651: syncthing-gtk fails to run (librsvg error)
Date: Sun, 19 Dec 2021 03:06:08 +0000 [thread overview]
Message-ID: <SEtE5kowh2_VE5o_26Uaf-OJnrcVaLqlHljFCOPP0HCmBiNvq6qF1y08sLg1qf0E5b66Ei2fGxyRB8UTE0R5g6Kvv2yt3X06GllFg_MmlGs=@protonmail.com> (raw)
Hi Guixers,
Looks like syncthing-gtk broke sometime just before/during/after the big core-updates-frozen merge. It was working for me at least before the merge, but I was slightly out of date. I don't think it is the syncthing-gtk package itself (no changes other than input style change), but it fails due to librsvg or how it uses it. Not sure what has changed here to cause this.
Running with RUST_BACKTRACE=full syncthing-gtk (as suggested by syncthing-gtk after shorter error messages), the output is:
I StatusIcon Using backend StatusIconGTK3 (primary)
I App
I App Syncthing-GTK started and running in notification area
(.syncthing-gtk-real:3861): Gdk-CRITICAL **: 17:05:06.225: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
thread '<unnamed>' panicked at 'Type RsvgHandle has already been registered', /tmp/guix-build-librsvg-2.50.7.drv-0/librsvg-2.50.7/guix-vendor/rust-glib-0.9.3.tar.gz/src/subclass/types.rs:485:13
stack backtrace:
0: 0x7fb2b7bab67d - <unknown>
1: 0x7fb2b7c6969c - <unknown>
2: 0x7fb2b7b9ff75 - <unknown>
3: 0x7fb2b7ba591b - <unknown>
4: 0x7fb2b7ba54fb - <unknown>
5: 0x7fb2b7ba605e - <unknown>
6: 0x7fb2b7bac317 - <unknown>
7: 0x7fb2b7bab7bc - <unknown>
8: 0x7fb2b7ba5b72 - <unknown>
9: 0x7fb2b772e70b - <unknown>
10: 0x7fb2b7741cbb - <unknown>
11: 0x7fb2b772e538 - <unknown>
12: 0x7fb2b7733351 - rsvg_rust_handle_get_type
13: 0x7fb2d23e4463 - g_registered_type_info_get_g_type
14: 0x7fb2d25610ed - _wrap_g_registered_type_info_get_g_type
15: 0x7fb2d2d94317 - <unknown>
16: 0x7fb2d2d007c8 - _PyEval_EvalFrameDefault
17: 0x7fb2d2e3c03c - <unknown>
18: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
19: 0x7fb2d2d4ae48 - <unknown>
20: 0x7fb2d2db9642 - <unknown>
21: 0x7fb2d2cfdf0e - _PyEval_EvalFrameDefault
22: 0x7fb2d2cf968b - <unknown>
23: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
24: 0x7fb2d2e3c03c - <unknown>
25: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
26: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
27: 0x7fb2d2cf968b - <unknown>
28: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
29: 0x7fb2d2cf968b - <unknown>
30: 0x7fb2d2d4adc4 - <unknown>
31: 0x7fb2d256a7b1 - pyg_closure_marshal
32: 0x7fb2d23904af - g_closure_invoke
33: 0x7fb2d23a1fcb - signal_emit_unlocked_R.isra.0
34: 0x7fb2d2556f21 - pygobject_emit
35: 0x7fb2d2d52020 - <unknown>
36: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
37: 0x7fb2d2cf968b - <unknown>
38: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
39: 0x7fb2d2cf968b - <unknown>
40: 0x7fb2d2d4adc4 - <unknown>
41: 0x7fb2d2cff09a - _PyEval_EvalFrameDefault
42: 0x7fb2d2cf968b - <unknown>
43: 0x7fb2d2d4adc4 - <unknown>
44: 0x7fb2d256cb78 - _pygi_closure_handle
45: 0x7fb2d2375446 - <unknown>
46: 0x7fb2d23758d0 - <unknown>
47: 0x7fb2d21bf919 - g_task_return_now
48: 0x7fb2d21c040b - g_task_return.part.0
49: 0x7fb2d218a2e5 - read_bytes_callback
50: 0x7fb2d218b807 - async_ready_callback_wrapper
51: 0x7fb2d21bf919 - g_task_return_now
52: 0x7fb2d21bf959 - complete_in_idle_cb
53: 0x7fb2d246136f - g_main_context_dispatch
54: 0x7fb2d24616e8 - g_main_context_iterate.constprop.0
55: 0x7fb2d246178f - g_main_context_iteration
56: 0x7fb2d21ed4c5 - g_application_run
57: 0x7fb2d237573d - <unknown>
58: 0x7fb2d23744ec - <unknown>
59: 0x7fb2d256f376 - pygi_invoke_c_callable
60: 0x7fb2d25710ea - pygi_function_cache_invoke
61: 0x7fb2d2d47b69 - PyObject_Call
62: 0x7fb2d2cff09a - _PyEval_EvalFrameDefault
63: 0x7fb2d2e3c03c - <unknown>
64: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
65: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
66: 0x7fb2d2e3c03c - <unknown>
67: 0x7fb2d2e3c37d - PyEval_EvalCode
68: 0x7fb2d2e816f5 - <unknown>
69: 0x7fb2d2e82f4d - PyRun_SimpleFileExFlags
70: 0x7fb2d2ea1ae7 - <unknown>
71: 0x7fb2d2ea20f8 - Py_BytesMain
72: 0x7fb2d28fd7dd - __libc_start_main
73: 0x40107a - _start
74: 0x0 - <unknown>
fatal runtime error: failed to initiate panic, error 5
next reply other threads:[~2021-12-19 3:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-19 3:06 John Kehayias via Bug reports for GNU Guix [this message]
2021-12-19 3:38 ` bug#52651: syncthing-gtk fails to run (librsvg error) John Kehayias via Bug reports for GNU Guix
2021-12-19 19:57 ` bdju via Bug reports for GNU Guix
2021-12-19 20:09 ` John Kehayias via Bug reports for GNU Guix
2021-12-19 20:10 ` bdju via Bug reports for GNU Guix
2021-12-19 20:17 ` bdju via Bug reports for GNU Guix
2021-12-19 21:06 ` John Kehayias via Bug reports for GNU Guix
2021-12-20 1:11 ` Leo Famulari
2021-12-20 1:39 ` John Kehayias via Bug reports for GNU Guix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='SEtE5kowh2_VE5o_26Uaf-OJnrcVaLqlHljFCOPP0HCmBiNvq6qF1y08sLg1qf0E5b66Ei2fGxyRB8UTE0R5g6Kvv2yt3X06GllFg_MmlGs=@protonmail.com' \
--to=bug-guix@gnu.org \
--cc=52651@debbugs.gnu.org \
--cc=john.kehayias@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.