syncthing-gtk fails to run (librsvg error)

  • Done
  • quality assurance status badge
Details
3 participants
  • bdju
  • John Kehayias
  • Leo Famulari
Owner
unassigned
Submitted by
John Kehayias
Severity
normal
J
J
John Kehayias wrote on 19 Dec 2021 04:06
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
SEtE5kowh2_VE5o_26Uaf-OJnrcVaLqlHljFCOPP0HCmBiNvq6qF1y08sLg1qf0E5b66Ei2fGxyRB8UTE0R5g6Kvv2yt3X06GllFg_MmlGs=@protonmail.com
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
J
J
John Kehayias wrote on 19 Dec 2021 04:38
(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
BM19wIdb4fBVLHdHy-c9-1GLvxml3xNGNWQvBQHNh515Zy0fbwTvKRopyJhq_N6WN9ae31LXcU9WLR1bHyEVndkJNed31cTu6ophPBI1cyY=@protonmail.com
I should have specified it worked on core-updates-frozen before the last big changes (input style, etc.) and merge into master.
B
B
bdju wrote on 19 Dec 2021 20:57
CGJJKIMCYJ2Y.GL9S4TOD0RN8@masaki
On Sat Dec 18, 2021 at 9:38 PM CST, John Kehayias via Bug reports for GNU Guix wrote:
Toggle quote (3 lines)
> I should have specified it worked on core-updates-frozen before the last
> big changes (input style, etc.) and merge into master.

I've just ran some updates and I'm on
guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff

syncthing-gtk appears to launch fine for me
J
J
John Kehayias wrote on 19 Dec 2021 21:09
(name . bdju)(address . bdju@tilde.team)(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
vXsXxYKf9Y9eQNMR6WEJlDy-UoX0D6DM0EDu7mc_RfNJlGzKV1OoZdPML_72CLlvoEJw8KWbkII7RT5IIu5Svp6asK4GoNn5xTfO1dqiKeY=@protonmail.com
Hi,

??????? Original Message ???????

On Sunday, December 19th, 2021 at 2:57 PM, bdju wrote:

Toggle quote (9 lines)
> On Sat Dec 18, 2021 at 9:38 PM CST, John Kehayias via Bug reports for GNU Guix wrote:
>
> > I should have specified it worked on core-updates-frozen before the last
> > big changes (input style, etc.) and merge into master.
>
> I've just ran some updates and I'm on
> guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff
> syncthing-gtk appears to launch fine for me

Thanks for checking. I'm on the same Guix commit. Are you sure syncthing-gtk is up to date? I'm running on just a WM (XMonad) on Xorg, perhaps that is a difference? My path for syncthing-gtk is:

/gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8
B
B
bdju wrote on 19 Dec 2021 21:10
(name . John Kehayias)(address . john.kehayias@protonmail.com)(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
CGJJUZ0AXZ50.9WHP0PL27LYQ@masaki
On Sun Dec 19, 2021 at 2:09 PM CST, John Kehayias wrote:
Toggle quote (6 lines)
> Thanks for checking. I'm on the same Guix commit. Are you sure
> syncthing-gtk is up to date? I'm running on just a WM (XMonad) on Xorg,
> perhaps that is a difference? My path for syncthing-gtk is:
>
> /gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8

I'm using Sway, which is as close to just running a WM as you can get on
Sway.

My path according to the `whereis syncthing-gtk` output is:

/gnu/store/3li6xh09g5w0ychn2b7jknglqg3pmyl8-profile/bin/syncthing-gtk

When launched, I can go to About and see the version says "unknown
(Daemon v1.16.1)

Oh, I get a path more like yours if I run an ls on the whereis output:

/gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8/bin/syncthing-gtk

It looks like we're both on 0.9.4.4-1.c46fbd8 in that case.
B
B
bdju wrote on 19 Dec 2021 21:17
(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
CGJJZWTQ288B.EA211TUEBNKI@masaki
On Sun Dec 19, 2021 at 2:10 PM CST, bdju via Bug reports for GNU Guix wrote:
Toggle quote (3 lines)
> I'm using Sway, which is as close to just running a WM as you can get on
> Sway.

Meant to say "on Wayland"!
J
J
John Kehayias wrote on 19 Dec 2021 22:06
(name . bdju)(address . bdju@tilde.team)(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
ijI4uCpsCc2veTvdWXeYFSN17s8X5ck1EXqbfs5n0QsVvf7FKhu82ZBikyZWyVeMQockNL3dBWQb12f_TzeWjKoH-00utqGARdoApXjUaZA=@protonmail.com
Thanks for the details, and I figured out the problem, though not sure of the fix. A similar issue was reported upstream some time ago: https://github.com/kozec/syncthing-gtk/issues/428and https://gitlab.gnome.org/GNOME/librsvg/-/issues/210

The answer was that multiple librsvg were being used. I checked our syncthing-gtk (the wrapper around .syncthing-gtk-real) and there are two different librsvg store paths in GI_TYPELIB_PATH. Removing the first one fixes the problem for me, but not removing the second one.

Looking at guix gc --references for both of them shows an identical list of references (other than themselves). Any idea what is going on here?

This is the variable from the wrapper script:

export GI_TYPELIB_PATH="/gnu/store/8g4rvram1vmir3kbmizbdkbzyvfx6rqh-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/qsdlm238an63wb765ldd04kn1ac3z8wc-libappindicator-12.10.0/lib/girepository-1.0:/gnu/store/q4ys65dcqg8bvndh2260h1zhydv46n1f-libnotify-0.7.9/lib/girepository-1.0:/gnu/store/wh2j9mz03vx3x6kajv0mdqgf6igd6r0j-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/3pim1cxlfw07r08wsbkx35w6i2xj46i6-pango-1.48.10/lib/girepository-1.0:/gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/agd34525iczpyzn27zdhghy10yfiby6n-atk-2.36.0/lib/girepository-1.0:/gnu/store/pjp4d4sl00nzfdbh27qkvb47c1fb525s-libdbusmenu-16.04.0/lib/girepository-1.0:/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/dswp2mfwb56xg57903cvhwcjj1fpdhqi-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/6p5vr2dbvrcg5yd7frjhkbm1q5mapcs0-at-spi2-core-2.40.0/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"
L
L
Leo Famulari wrote on 20 Dec 2021 02:11
(name . John Kehayias via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
Yb/YL5y4UFChaQrk@jasmine.lan
On Sun, Dec 19, 2021 at 09:06:55PM +0000, John Kehayias via Bug reports for GNU Guix wrote:
Toggle quote (10 lines)
> Thanks for the details, and I figured out the problem, though not sure of the fix. A similar issue was reported upstream some time ago: https://github.com/kozec/syncthing-gtk/issues/428and https://gitlab.gnome.org/GNOME/librsvg/-/issues/210
>
> The answer was that multiple librsvg were being used. I checked our syncthing-gtk (the wrapper around .syncthing-gtk-real) and there are two different librsvg store paths in GI_TYPELIB_PATH. Removing the first one fixes the problem for me, but not removing the second one.
>
> Looking at guix gc --references for both of them shows an identical list of references (other than themselves). Any idea what is going on here?
>
> This is the variable from the wrapper script:
>
> export GI_TYPELIB_PATH="/gnu/store/8g4rvram1vmir3kbmizbdkbzyvfx6rqh-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/qsdlm238an63wb765ldd04kn1ac3z8wc-libappindicator-12.10.0/lib/girepository-1.0:/gnu/store/q4ys65dcqg8bvndh2260h1zhydv46n1f-libnotify-0.7.9/lib/girepository-1.0:/gnu/store/wh2j9mz03vx3x6kajv0mdqgf6igd6r0j-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/3pim1cxlfw07r08wsbkx35w6i2xj46i6-pango-1.48.10/lib/girepository-1.0:/gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/agd34525iczpyzn27zdhghy10yfiby6n-atk-2.36.0/lib/girepository-1.0:/gnu/store/pjp4d4sl00nzfdbh27qkvb47c1fb525s-libdbusmenu-16.04.0/lib/girepository-1.0:/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/dswp2mfwb56xg57903cvhwcjj1fpdhqi-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/6p5vr2dbvrcg5yd7frjhkbm1q5mapcs0-at-spi2-core-2.40.0/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"

Thanks for the report. I believe this is fixed with commit
99f290bf5ba59e3218b95d7505ac27f989250aad

Please let us know if this bug is closed in error.
J
J
John Kehayias wrote on 20 Dec 2021 02:39
(name . 52651@debbugs.gnu.org)(address . 52651@debbugs.gnu.org)
xbreAQmj0729ksuFV7-YRs6HI5PrNjId7sXLLaUro0hc-GMRxAsF_YccRAVGfZVRkXoEvUYT0rGZ9zkahhe9QfrymLDqv2iyPADeNDAlzb4=@protonmail.com
Thanks for pushing and closing Leo!
?
Your comment

This issue is archived.

To comment on this conversation send an email to 52651@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52651
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch