emacs-bug-tracker
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52651: closed (syncthing-gtk fails to run (librsvg error))

From: GNU bug Tracking System
Subject: bug#52651: closed (syncthing-gtk fails to run (librsvg error))
Date: Mon, 20 Dec 2021 01:12:02 +0000 
Your message dated Sun, 19 Dec 2021 20:11:11 -0500
with message-id <Yb/YL5y4UFChaQrk@jasmine.lan>
and subject line Re: bug#52651: syncthing-gtk fails to run (librsvg error)
has caused the debbugs.gnu.org bug report #52651,
regarding syncthing-gtk fails to run (librsvg error)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
52651: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=52651
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: syncthing-gtk fails to run (librsvg error) Date: Sun, 19 Dec 2021 03:06:08 +0000 
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

--- End Message ---
--- Begin Message --- Subject: Re: bug#52651: syncthing-gtk fails to run (librsvg error) Date: Sun, 19 Dec 2021 20:11:11 -0500 
On Sun, Dec 19, 2021 at 09:06:55PM +0000, John Kehayias via Bug reports for GNU 
Guix wrote:
> 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/428 and 
> 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.

--- End Message ---
reply via email to
[Prev in Thread] Current Thread [Next in Thread]