error on start with ----------------------- oschtan@oschtan ~ $ yandex-disk start --dir=Work/ (process:2691): GLib-GObject-CRITICAL **: 23:26:19.844: cannot register existing type 'PxManager' (process:2691): GLib-CRITICAL **: 23:26:19.844: g_once_init_leave: assertion 'result != 0' failed (process:2691): GLib-GObject-CRITICAL **: 23:26:19.844: g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed Got signal 11, faulty address is 44, from 0x7f901400ffef 0.1.6.1080 x64 [bt] Execution path: [bt] /usr/lib64/libproxy/libpxbackend-1.0.so(px_manager_get_proxies_sync+0x2f) [0x7f901400ffef] [bt] /usr/lib64/libproxy/libpxbackend-1.0.so(px_manager_get_proxies_sync+0x2f) [0x7f901400ffef] [bt] /usr/lib64/libproxy.so(px_proxy_factory_get_proxies+0x28) [0x7f901518a2f8] [bt] yandex-disk() [0x468ec1] [bt] yandex-disk() [0x47613c] [bt] yandex-disk() [0x4764ef] [bt] yandex-disk() [0x4acee9] [bt] yandex-disk() [0x47c64b] [bt] yandex-disk() [0x47cd48] [bt] yandex-disk() [0x47ce1c] [bt] yandex-disk() [0x4b3d20] [bt] yandex-disk() [0x41e307] [bt] yandex-disk() [0x415d63] [bt] yandex-disk() [0x41790b] [bt] /lib64/libc.so.6(+0x238ca) [0x7f9014c838ca] [bt] /lib64/libc.so.6(__libc_start_main+0x85) [0x7f9014c83985] [bt] yandex-disk() [0x4140e9] ----------------------- Downgrade to =net-libs/libproxy-0.4.18 resolved error
I couldn't find any fix on the other distributions supplying this, even if they now ship newer libproxy and this same yandex-disk version Are you still hitting this with libproxy-0.5.2? Previous 0.5.x versions were having some important bugs Thanks
With current versions of dev-libs/glib and net-libs/libproxy yandex-disk does not start =dev-libs/glib-2.76.4 =net-libs/libproxy-0.5.3 --------------------log----------------- oschtan@oschtan ~ $ yandex-disk start --dir=Yandex-disk/ (process:13625): GLib-GObject-CRITICAL **: 01:02:37.122: cannot register existing type 'PxManager' (process:13625): GLib-CRITICAL **: 01:02:37.122: g_once_init_leave: assertion 'result != 0' failed (process:13625): GLib-GObject-CRITICAL **: 01:02:37.122: g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed Got signal 11, faulty address is 60, from 0x7f9005ac8497 0.1.6.1080 x64 [bt] Execution path: [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7f9005ac8497] [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7f9005ac8497] [bt] /usr/lib64/libproxy/libpxbackend-1.0.so(px_manager_get_proxies_sync+0x28) [0x7f9005bbd008] [bt] /usr/lib64/libproxy.so(px_proxy_factory_get_proxies+0x28) [0x7f9006d9a2f8] [bt] yandex-disk() [0x468ec1] [bt] yandex-disk() [0x47613c] [bt] yandex-disk() [0x4764ef] [bt] yandex-disk() [0x4acee9] [bt] yandex-disk() [0x47c64b] [bt] yandex-disk() [0x47cd48] [bt] yandex-disk() [0x47ce1c] [bt] yandex-disk() [0x4b3d20] [bt] yandex-disk() [0x41e307] [bt] yandex-disk() [0x415d63] [bt] yandex-disk() [0x41790b] [bt] /lib64/libc.so.6(+0x23e0a) [0x7f9006831e0a] [bt] /lib64/libc.so.6(__libc_start_main+0x85) [0x7f9006831ec5] [bt] yandex-disk() [0x4140e9] -------------------------------------- An attempt to communicate with Yandex support directly led to stock phrases and a complete reluctance to help or somehow convey information to their employees. I propose to set this client for deletion, since it does not work properly at the moment at all
@Oschtan I fixed it by running 'yandex-disk setup' again.
(In reply to baxzzzz from comment #3) > @Oschtan I fixed it by running 'yandex-disk setup' again. oschtan@oschtan ~ $ yandex-disk start --dir=Work/ (process:29885): GLib-GObject-CRITICAL **: 20:45:28.628: cannot register existing type 'PxManager' (process:29885): GLib-CRITICAL **: 20:45:28.628: g_once_init_leave: assertion 'result != 0' failed (process:29885): GLib-GObject-CRITICAL **: 20:45:28.628: g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed Got signal 11, faulty address is 60, from 0x7f0bb8e60507 0.1.6.1080 x64 [bt] Execution path: [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7f0bb8e60507] [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7f0bb8e60507] [bt] /usr/lib64/libproxy/libpxbackend-1.0.so(px_manager_get_proxies_sync+0x39) [0x7f0bb8f54fc9] [bt] yandex-disk() [0x468ec1] [bt] yandex-disk() [0x47613c] [bt] yandex-disk() [0x4764ef] [bt] yandex-disk() [0x4acee9] [bt] yandex-disk() [0x47c64b] [bt] yandex-disk() [0x47cd48] [bt] yandex-disk() [0x47ce1c] [bt] yandex-disk() [0x4b3d20] [bt] yandex-disk() [0x41e307] [bt] yandex-disk() [0x415d63] [bt] yandex-disk() [0x41790b] [bt] /lib64/libc.so.6(+0x23f0a) [0x7f0bb9bcaf0a] [bt] /lib64/libc.so.6(__libc_start_main+0x85) [0x7f0bb9bcafc5] [bt] yandex-disk() [0x4140e9] oschtan@oschtan ~ $ yandex-disk start --dir=Work/ (process:29907): GLib-GObject-CRITICAL **: 20:45:29.861: cannot register existing type 'PxManager' (process:29907): GLib-CRITICAL **: 20:45:29.861: g_once_init_leave: assertion 'result != 0' failed (process:29907): GLib-GObject-CRITICAL **: 20:45:29.861: g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed Got signal 11, faulty address is 60, from 0x7fe74bace507 0.1.6.1080 x64 [bt] Execution path: [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7fe74bace507] [bt] /usr/lib64/libglib-2.0.so.0(g_mutex_lock+0x7) [0x7fe74bace507] [bt] /usr/lib64/libproxy/libpxbackend-1.0.so(px_manager_get_proxies_sync+0x39) [0x7fe74bbc2fc9] [bt] yandex-disk() [0x468ec1] [bt] yandex-disk() [0x47613c] [bt] yandex-disk() [0x4764ef] [bt] yandex-disk() [0x4acee9] [bt] yandex-disk() [0x47c64b] [bt] yandex-disk() [0x47cd48] [bt] yandex-disk() [0x47ce1c] [bt] yandex-disk() [0x4b3d20] [bt] yandex-disk() [0x41e307] [bt] yandex-disk() [0x415d63] [bt] yandex-disk() [0x41790b] [bt] /lib64/libc.so.6(+0x23f0a) [0x7fe74c838f0a] [bt] /lib64/libc.so.6(__libc_start_main+0x85) [0x7fe74c838fc5] [bt] yandex-disk() [0x4140e9] oschtan@oschtan ~ $ ======================== I don't see the difference. This worked with the previous version of yandex-disk. Then they removed libproxy and everything broke
I've digged this problem a bit as I can no longer hold libproxy masked to pre-0.5, here's what I've found: yandex-disk uses libproxy via dlopen, but for whatever reason it dlcloses it after first (every?) request and opens it again. And on second open libproxy fails to create new proxy managers as it have lost its global state, thinks it's first call, attempts to register type in glib, fails but doesn't report an error to calling side, and then crashes on lookup. I've created issue in libproxy repo https://github.com/libproxy/libproxy/issues/285 but haven't thought how it could be fixed yet. I've also reported it to yandex support but client haven't been updated in years and I'm not sure it'll even reach developers. It could be stubbed with simple LD_PRELOAD script so libproxy wouldn't get unloaded, it should be possible to pack in into ebuild. But of course libproxy and/or yandex-disk fix would be much more preferable.
As a temporary workaround, binary could be patched via patchelf --add-needed libproxy.so.1 /opt/bin/yandex-disk I don't think it is a good solution. Libproxy fix would be better, but it'll take some time.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fea07b72d07d7fd5ac3e29ed2c337325467af3d6 commit fea07b72d07d7fd5ac3e29ed2c337325467af3d6 Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2024-04-07 15:45:25 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2024-04-07 15:45:25 +0000 net-libs/libproxy: add 0.5.5 Bug: https://bugs.gentoo.org/907899 Signed-off-by: Pacho Ramos <pacho@gentoo.org> net-libs/libproxy/Manifest | 1 + net-libs/libproxy/libproxy-0.5.5.ebuild | 68 +++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+)
works fine for me with libproxy-0.5.5
