Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionDavid Zambonini
2018-12-17 11:24:39 UTC
Description of problem:
Running our own PHP builds within a restricted environment where access to the full passdb is not available, it appears that enchant triggers a glib 2.0 critical assert if it cannot determine the users home directory:
GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
Version-Release number of selected component (if applicable):
enchant-1.6.0-8.el7.x86_64
How reproducible:
A simple case can be forced by running enchant with a UID not in the passdb, without HOME set in the environment.
Steps to Reproduce:
1. run enchant with a UID not in the passdb and without HOME in the environment:
sudo -u \#123456 -- sh -c 'unset HOME; enchant -a < /dev/null'
(or another non-existing uid)
Actual results:
@(#) International Ispell Version 3.1.20 (but really Enchant 1.6.0)
GLib-CRITICAL **: (datestring): g_once_init_leave: assertion 'result != 0' failed
Expected results:
@(#) International Ispell Version 3.1.20 (but really Enchant 1.6.0)
Additional info:
Caused by the assumption the home directory will always be found, leading to g_slist_free(NULL) in multiple locations:
src/enchant.c:198 g_slist_free (home_dirs);
src/enchant.c:233 g_slist_free (user_dirs);
src/enchant.c:270 g_slist_free (user_conf_dirs);
src/enchant.c:637 g_slist_free (user_config_dirs);
src/enchant.c:1513 g_slist_free (module_dirs);
src/enchant.c:1567 g_slist_free (conf_dirs);
It's obviously outside normal expected operating conditions, but a defensive if (home_dirs) g_slist_free (home_dirs) etc. would appear prudent in any case?
> a defensive if (home_dirs) g_slist_free (home_dirs) etc. would appear prudent in any case?
Thanks for a bug report. The above won't help, g_slist_free() accepts NULL, the same as the runtime warning you refer to doesn't look related to this g_slist_free() call.
I tried it on Fedora with enchant-1.6.0-20.fc28.x86_64 and I see this:
$ sudo -u \#123456 -- sh -c 'unset HOME; LD_PRELOAD=/build/local/lib/libcamel-1.2.so enchant -a < /dev/null'
@(#) International Ispell Version 3.1.20 (but really Enchant 1.6.0)
(process:9318): GLib-WARNING **: 15:59:18.709: getpwuid_r(): failed due to unknown user id (123456)
at g_logv() at gmessages.c:1319
by g_log() at gmessages.c:1471
by g_get_user_database_entry() at gutils.c:678
by g_get_home_dir() at gutils.c:878
by g_init_user_config_dir() at gutils.c:1231
by g_get_user_config_dir() at gutils.c:1272
by enchant_get_user_dirs()
by enchant_broker_init()
by main()
by __libc_start_main()
by _start()
(process:9318): GLib-CRITICAL **: 15:59:18.727: g_once_init_leave: assertion 'result != 0' failed
at g_logv() at gmessages.c:1319
by g_log() at gmessages.c:1471
by g_return_if_fail_warning() at gmessages.c:2888
by g_once_init_leave() at gthread.c:693
by g_get_home_dir() at gutils.c:889
by g_init_user_config_dir() at gutils.c:1231
by g_get_user_config_dir() at gutils.c:1272
by enchant_get_user_dirs()
by enchant_broker_init()
by main()
by __libc_start_main()
by _start()
From which I understand that the later is due to the first warning. I see the same warnings in RHEL 7 as well.
I'm moving this to glib2, because it's the place which causes the runtime warnings.
Comment 5RHEL Program Management
2021-03-15 07:32:37 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.