Bug 1659997

Summary:	GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
Product:	Red Hat Enterprise Linux 7	Reporter:	David Zambonini <redhat-e27>
Component:	glib2	Assignee:	Colin Walters <walters>
Status:	CLOSED WONTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	mcrha
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-03-15 07:32:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David 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?

Comment 2 Milan Crha 2019-01-02 15:09:45 UTC

> 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 5 RHEL 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.