GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2020-07-07T09:27:49Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/2155Support RTLD_DEEPBIND in g_module_open2020-07-07T09:27:49ZArseniy LartsevSupport RTLD_DEEPBIND in g_module_openExample: an executable is linked dynamically against libsomething.so exporting sybol `func` (a function), and then g_module_opens a plugin which was itself linked, statically or dynamically, to libanother.so or libanother.a which, in tur...Example: an executable is linked dynamically against libsomething.so exporting sybol `func` (a function), and then g_module_opens a plugin which was itself linked, statically or dynamically, to libanother.so or libanother.a which, in turn, exports a symbol (a function) by the same name. When the plugin calls `func`, expecting `func` from libanother to be called, actually `func` from libsomething will be called.
This can happen if executable and plugin link to different versions of the same library, or executable links to libsqlite and plugin links to libsqlcipher. The solution, short of rebuilding/modifying the executable, is to pass RTLD_DEEPBIND flag to dlopen. Therefore, it would be useful to support that flag in g_module_open (on platforms that have it, anyway – it was added to glibc a couple of releases later than RTLD_LOCAL I believe).https://gitlab.gnome.org/GNOME/glib/-/issues/1443Deadlock between g_module_open() and dlopen() when called from a constructor2019-12-12T17:40:41ZДилян Палаузовgit-dpa@aegee.orgDeadlock between g_module_open() and dlopen() when called from a constructorStarting Evolution under valgrind --tool=helgrind --num-callers=40 prints the text below. My interpretation is, that it calls g_proxy_resolver_get_default (where the incorrect order was observed) and g_module_open() and just because the...Starting Evolution under valgrind --tool=helgrind --num-callers=40 prints the text below. My interpretation is, that it calls g_proxy_resolver_get_default (where the incorrect order was observed) and g_module_open() and just because these functions are called, there is a deadlock.
I use glib-2.56.1 and libproxy-0.4.15.
Is the problem to be resolved in glib, Evolution or libproxy?
If necessary I will provide trace with more function by increasing --num-callers.
```
Thread #1: lock order "0x24AB2A90 before 0x4225968" violated
Observed (incorrect) order is: acquisition of lock at 0x4225968
at 0x4C313F0: mutex_lock_WRK (hg_intercepts.c:909)
by 0x4C3527C: pthread_mutex_lock (hg_intercepts.c:925)
by 0x40127B1: _dl_open (dl-open.c:542)
by 0x178E1EF5: dlopen_doit (dlopen.c:66)
by 0x146B5D0B: _dl_catch_exception (dl-error-skeleton.c:196)
by 0x146B5D7E: _dl_catch_error (dl-error-skeleton.c:215)
by 0x178E2534: _dlerror_run (dlerror.c:162)
by 0x178E1F90: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
by 0x3354879C: libmodman::module_manager::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (module_manager.cpp:251)
by 0x335493DB: libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (module_manager.cpp:328)
by 0x33537718: libproxy::proxy_factory::proxy_factory() (proxy.cpp:165)
by 0x33537BBA: px_proxy_factory_new (proxy.cpp:449)
by 0x333294A1: g_libproxy_resolver_init (glibproxyresolver.c:79)
by 0xA82CFA4: g_type_create_instance (gtype.c:1866)
by 0xA80E777: g_object_new_internal (gobject.c:1799)
by 0xA80FE14: g_object_new_with_properties (gobject.c:1967)
by 0xA810820: g_object_new (gobject.c:1639)
by 0xA4C68C0: try_implementation (giomodule.c:815)
by 0xA4C69EF: _g_io_module_get_default (giomodule.c:914)
by 0x5136C5E: camel_service_init (camel-service.c:1077)
by 0xA82CF67: g_type_create_instance (gtype.c:1860)
by 0xA80E777: g_object_new_internal (gobject.c:1799)
by 0xA8104AF: g_object_new_valist (gobject.c:2122)
by 0xA4C3275: g_initable_new_valist (ginitable.c:244)
by 0xA4C332B: g_initable_new (ginitable.c:162)
by 0x513B83C: session_add_service (camel-session.c:448)
by 0x29B3810F: mail_session_add_service (e-mail-session.c:1186)
by 0x2A62BFD5: mail_ui_session_add_service (e-mail-ui-session.c:516)
by 0x513B457: camel_session_add_service (camel-session.c:922)
by 0x29B3861D: mail_session_add_from_source (e-mail-session.c:464)
by 0x29B391F0: mail_session_constructed (e-mail-session.c:1052)
by 0xA80E91F: g_object_new_internal (gobject.c:1839)
by 0xA8104AF: g_object_new_valist (gobject.c:2122)
by 0xA81080B: g_object_new (gobject.c:1642)
by 0x2A62CBCA: e_mail_ui_session_new (e-mail-ui-session.c:1015)
by 0x2A5DA8FA: mail_backend_constructed (e-mail-backend.c:1229)
by 0x2F5925B1: mail_shell_backend_constructed (e-mail-shell-backend.c:827)
by 0xA80ED74: g_object_new_internal (gobject.c:1771)
by 0xA8104AF: g_object_new_valist (gobject.c:2122)
by 0xA81080B: g_object_new (gobject.c:1642)
followed by a later acquisition of lock at 0x24AB2A90
at 0x4C313F0: mutex_lock_WRK (hg_intercepts.c:909)
by 0x4C3527C: pthread_mutex_lock (hg_intercepts.c:925)
by 0x99B5532: g_module_open (gmodule.c:500)
by 0x3398DA62: _nm_utils_init (nm-utils.c:248)
by 0x400EE49: call_init.part.0 (dl-init.c:72)
by 0x400EF55: _dl_init (dl-init.c:118)
by 0x4012F62: dl_open_worker (dl-open.c:511)
by 0x146B5D0B: _dl_catch_exception (dl-error-skeleton.c:196)
by 0x4012829: _dl_open (dl-open.c:594)
by 0x178E1EF5: dlopen_doit (dlopen.c:66)
by 0x146B5D0B: _dl_catch_exception (dl-error-skeleton.c:196)
by 0x146B5D7E: _dl_catch_error (dl-error-skeleton.c:215)
by 0x178E2534: _dlerror_run (dlerror.c:162)
by 0x178E1F90: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
by 0x3354879C: libmodman::module_manager::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (module_manager.cpp:251)
by 0x335493DB: libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (module_manager.cpp:328)
by 0x33537718: libproxy::proxy_factory::proxy_factory() (proxy.cpp:165)
by 0x33537BBA: px_proxy_factory_new (proxy.cpp:449)
by 0x333294A1: g_libproxy_resolver_init (glibproxyresolver.c:79)
by 0xA82CFA4: g_type_create_instance (gtype.c:1866)
by 0xA80E777: g_object_new_internal (gobject.c:1799)
by 0xA80FE14: g_object_new_with_properties (gobject.c:1967)
by 0xA810820: g_object_new (gobject.c:1639)
by 0xA4C68C0: try_implementation (giomodule.c:815)
by 0xA4C69EF: _g_io_module_get_default (giomodule.c:914)
by 0x5136C5E: camel_service_init (camel-service.c:1077)
by 0xA82CF67: g_type_create_instance (gtype.c:1860)
by 0xA80E777: g_object_new_internal (gobject.c:1799)
by 0xA8104AF: g_object_new_valist (gobject.c:2122)
by 0xA4C3275: g_initable_new_valist (ginitable.c:244)
by 0xA4C332B: g_initable_new (ginitable.c:162)
by 0x513B83C: session_add_service (camel-session.c:448)
by 0x29B3810F: mail_session_add_service (e-mail-session.c:1186)
by 0x2A62BFD5: mail_ui_session_add_service (e-mail-ui-session.c:516)
by 0x513B457: camel_session_add_service (camel-session.c:922)
by 0x29B3861D: mail_session_add_from_source (e-mail-session.c:464)
by 0x29B391F0: mail_session_constructed (e-mail-session.c:1052)
by 0xA80E91F: g_object_new_internal (gobject.c:1839)
by 0xA8104AF: g_object_new_valist (gobject.c:2122)
by 0xA81080B: g_object_new (gobject.c:1642)
Required order was established by acquisition of lock at 0x24AB2A90
at 0x4C313F0: mutex_lock_WRK (hg_intercepts.c:909)
by 0x4C3527C: pthread_mutex_lock (hg_intercepts.c:925)
by 0x99B5532: g_module_open (gmodule.c:500)
by 0x74D7D58: _gtk_module_has_mixed_deps (gtkmodules.c:590)
by 0x74B1321: pre_parse_hook (gtkmain.c:654)
by 0xAAA26D4: g_option_context_parse (goption.c:1937)
by 0xF4554B0: gtk_clutter_init_with_args (gtk-clutter-util.c:294)
by 0x40443E: main (main.c:471)
followed by a later acquisition of lock at 0x4225968
at 0x4C313F0: mutex_lock_WRK (hg_intercepts.c:909)
by 0x4C3527C: pthread_mutex_lock (hg_intercepts.c:925)
by 0x40127B1: _dl_open (dl-open.c:542)
by 0x178E1F10: dlopen_doit (dlopen.c:66)
by 0x146B5D0B: _dl_catch_exception (dl-error-skeleton.c:196)
by 0x146B5D7E: _dl_catch_error (dl-error-skeleton.c:215)
by 0x178E2534: _dlerror_run (dlerror.c:162)
by 0x178E1F90: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
by 0x99B59CB: g_module_open (gmodule-dl.c:125)
by 0x74D7D58: _gtk_module_has_mixed_deps (gtkmodules.c:590)
by 0x74B1321: pre_parse_hook (gtkmain.c:654)
by 0xAAA26D4: g_option_context_parse (goption.c:1937)
by 0xF4554B0: gtk_clutter_init_with_args (gtk-clutter-util.c:294)
by 0x40443E: main (main.c:471)
Lock at 0x24AB2A90 was first observed
at 0x4C35259: pthread_mutex_init (hg_intercepts.c:787)
by 0xAADA1AC: g_rec_mutex_impl_new (gthread-posix.c:282)
by 0xAADA267: g_rec_mutex_lock (gthread-posix.c:302)
by 0x99B5532: g_module_open (gmodule.c:500)
by 0x74D7D58: _gtk_module_has_mixed_deps (gtkmodules.c:590)
by 0x74B1321: pre_parse_hook (gtkmain.c:654)
by 0xAAA26D4: g_option_context_parse (goption.c:1937)
by 0xF4554B0: gtk_clutter_init_with_args (gtk-clutter-util.c:294)
by 0x40443E: main (main.c:471)
Address 0x24ab2a90 is 0 bytes inside a block of size 40 alloc'd
at 0x4C2E18B: malloc (vg_replace_malloc.c:299)
by 0xAADA17F: g_rec_mutex_impl_new (gthread-posix.c:276)
by 0xAADA267: g_rec_mutex_lock (gthread-posix.c:302)
by 0x99B5532: g_module_open (gmodule.c:500)
by 0x74D7D58: _gtk_module_has_mixed_deps (gtkmodules.c:590)
by 0x74B1321: pre_parse_hook (gtkmain.c:654)
by 0xAAA26D4: g_option_context_parse (goption.c:1937)
by 0xF4554B0: gtk_clutter_init_with_args (gtk-clutter-util.c:294)
by 0x40443E: main (main.c:471)
Block was alloc'd by thread #1
Lock at 0x4225968 was first observed
at 0x4C313F0: mutex_lock_WRK (hg_intercepts.c:909)
by 0x4C3527C: pthread_mutex_lock (hg_intercepts.c:925)
by 0x40127B1: _dl_open (dl-open.c:542)
by 0x178E1F10: dlopen_doit (dlopen.c:66)
by 0x146B5D0B: _dl_catch_exception (dl-error-skeleton.c:196)
by 0x146B5D7E: _dl_catch_error (dl-error-skeleton.c:215)
by 0x178E2534: _dlerror_run (dlerror.c:162)
by 0x178E1F90: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
by 0xF1BCB37: bmalloc::Environment::computeIsDebugHeapEnabled() (Environment.cpp:99)
by 0xF1BCB98: bmalloc::Environment::Environment(std::lock_guard<bmalloc::StaticMutex>&) (Environment.cpp:111)
by 0xF1B58B4: bmalloc::PerProcess<bmalloc::Environment>::getSlowCase() (PerProcess.h:81)
by 0xF1B5E42: bmalloc::Heap::Heap(bmalloc::HeapKind, std::lock_guard<bmalloc::StaticMutex>&) (PerProcess.h:65)
by 0xF1B3E32: bmalloc::PerProcess<bmalloc::PerHeapKind<bmalloc::Heap> >::getSlowCase() (PerHeapKind.h:43)
by 0xF1B3B03: bmalloc::Cache::Cache(bmalloc::HeapKind) (PerProcess.h:65)
by 0xF1B3EF5: bmalloc::PerThread<bmalloc::PerHeapKind<bmalloc::Cache> >::getSlowCase() (PerHeapKind.h:43)
by 0xF1B3BAE: bmalloc::Cache::allocateSlowCaseNullCache(bmalloc::HeapKind, unsigned long) (Cache.cpp:58)
by 0xF19A5D5: WTF::StringImpl::createFromLiteral(char const*, unsigned int) (StringImpl.h:161)
by 0xF19A650: WTF::StringImpl::createFromLiteral(char const*) (StringImpl.cpp:158)
by 0xF1A6321: WTF::String::String(WTF::ASCIILiteral) (WTFString.cpp:83)
by 0xC0A2806: _GLOBAL__sub_I_PasteboardHelper.cpp (PasteboardHelper.cpp:43)
by 0x400EE49: call_init.part.0 (dl-init.c:72)
by 0x400EF55: _dl_init (dl-init.c:118)
by 0x4001069: ??? (in /lib64/ld-2.27.so)
Address 0x4225968 is 2312 bytes inside data symbol "_rtld_local"
```https://gitlab.gnome.org/GNOME/glib/-/issues/1185g_module_open returns the wrong error when loading libtool convenience libraries2018-05-24T19:00:43ZBugzillag_module_open returns the wrong error when loading libtool convenience libraries## Submitted by Jérémie Galarneau
**[Link to original bug (#769391)](https://bugzilla.gnome.org/show_bug.cgi?id=769391)**
## Description
Created attachment 332488
libtool convenience library wrapper exhibiting the problem
g_module_...## Submitted by Jérémie Galarneau
**[Link to original bug (#769391)](https://bugzilla.gnome.org/show_bug.cgi?id=769391)**
## Description
Created attachment 332488
libtool convenience library wrapper exhibiting the problem
g_module_open() mishandles libtool wrappers "*.la" files when they wrap internal project libraries. Libtool's documentation refers to such libraries as "Convenience Libraries" [1].
When pointed to such wrappers, g_module_open() will fail, as expected. However, the error returned by g_module_error() is misleading.
For instance, when pointed to "../plugins/ctf/fs/libbabeltrace-plugin-ctf-fs.la", a convenience library, g_module_error() will return:
"../plugins/ctf/fs/.libs/: cannot read file data: Is a directory"
The problem was originaly encountered with glib 2.48.1 on Arch Linux, but was also
reproduced using glib 2.32.4 on Ubuntu 12.04.
Looking at the code, g_module_open() calls into parse_libtool_archive() to determine the path of the actual shared object to load. However, as you can see in the attached file, dlname is empty, a condition which is not checked for.
This will cause parse_libtool_archive() to return a path to a directory which is ultimately passed to dlopen() and fails with the "Is a directory" error.
My idea for a fix would be to check for this situation, set the current g_module error to "Could not load /path/to/thefile.la as it is a convenience library" using g_module_set_error and return NULL in parse_libtool_archive()
Should I submit a patch?
[1] https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html
**Attachment 332488**, "libtool convenience library wrapper exhibiting the problem":
[libbabeltrace-plugin-ctf-fs.la](/uploads/93030c77952b2dd39fdc637559090af8/libbabeltrace-plugin-ctf-fs.la)
Version: 2.48.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/1012dlclose with atfork handlers core dumps2018-05-24T17:38:05ZBugzilladlclose with atfork handlers core dumps## Submitted by mai..@..xx.net
**[Link to original bug (#746536)](https://bugzilla.gnome.org/show_bug.cgi?id=746536)**
## Description
This report is meant to bring attention to the issue mentioned in:
https://trac.macports.org/ticke...## Submitted by mai..@..xx.net
**[Link to original bug (#746536)](https://bugzilla.gnome.org/show_bug.cgi?id=746536)**
## Description
This report is meant to bring attention to the issue mentioned in:
https://trac.macports.org/ticket/45309 and
http://comments.gmane.org/gmane.os.openbsd.bugs/21076
Brief summary of the issue:
When a library used by a module adding a new dependency which has
an initializer which adds a child atfork handler:
The result is that after closing the module, the system has a
dangling pointer for the atfork handler which would at best
crash on the child side of fork() and at worst lead to arbitray
code execution of whatever happened to be at that location in
memory at a later time in the process.
This issue can be reproduced on OSX and OpenBSD. On the latter,
for example using a webkit (p11-kit as dependency) based
browsers which dumps core on any call to fork().
A more detailed analysis for OSX can be found
in the ticket above, starting in the later comments:
https://trac.macports.org/ticket/45309#comment:47
A more detailed analysis for OpenBSD is in this thread:
http://comments.gmane.org/gmane.os.openbsd.bugs/21076
A possible workaround is to not call dlclose() as done in the
following patch:
https://trac.macports.org/browser/trunk/dports/devel/glib2-devel/files/patch-gmodule-gmodule-dl.c.diff?rev=127768
This patch is confirmed to work on OpenBSD as well.
Version: 2.42.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/270_g_module_self should use RTLD_DEFAULT when available2019-08-20T08:56:48ZBugzilla_g_module_self should use RTLD_DEFAULT when available## Submitted by Roy Marples
**[Link to original bug (#610490)](https://bugzilla.gnome.org/show_bug.cgi?id=610490)**
## Description
_g_module_self should use RTLD_DEFAULT when available.
Although not needed for NetBSD, it apparently ...## Submitted by Roy Marples
**[Link to original bug (#610490)](https://bugzilla.gnome.org/show_bug.cgi?id=610490)**
## Description
_g_module_self should use RTLD_DEFAULT when available.
Although not needed for NetBSD, it apparently is for FreeBSD and supplies a minor optimization.
Version: 2.23.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/31Binary relocatability API for glib2022-11-30T16:51:13ZBugzillaBinary relocatability API for glib## Submitted by Mike Hearn
**[Link to original bug (#172268)](https://bugzilla.gnome.org/show_bug.cgi?id=172268)**
## Description
It'd be nice to have a GetModuleFileName style API in glib that abstracts the
different ways a program...## Submitted by Mike Hearn
**[Link to original bug (#172268)](https://bugzilla.gnome.org/show_bug.cgi?id=172268)**
## Description
It'd be nice to have a GetModuleFileName style API in glib that abstracts the
different ways a program can locate its own absolute path at runtime.
On Windows you can use GetModuleFileName to locate the absolute path of the
current process. On Linux reading /proc/self/exe does the same thing. I do not
know what the equivalent is on other UNIX systems.
One thing I'm not sure about is whether to support libraries or not. Windows and
Linux let you determine the absolute path of a library by passing in a pointer
to somewhere inside the image, for instance the address of an empty string.
Again I am not sure how portable that is outside these two platforms.
I hope to write a patch for this in the next few months.
### Depends on
* [Bug 615903](https://bugzilla.gnome.org/show_bug.cgi?id=615903)