Re: [gdm-list] double login




Ray:

Good catch.

Look at the surround debug spew:

Oct 20 09:54:30 ubu-desktop gdm[4624]: DEBUG: Attempting to parse key
string: daemon/FirstVT=7
Oct 20 09:54:30 ubu-desktop gdm[4624]: GLib-CRITICAL:
unquote_string_inplace: assertion `err == NULL || *err == NULL' failed
Oct 20 09:54:30 ubu-desktop gdm[4624]: DEBUG: Attempting to parse key

It's blowing an assertion when attempting to parse the daemon/FirstVT
key (the message makes it sound like a GError isn't getting properly
initialized to NULL), then it crashes trying to parse
security/DisallowTCP.

I don't think it is crashing when parsing the keys.  Note that the
function unquote_string_inplace is in the glib file gshell.c.  This
is called by g_shell_unquote, which is only called by
g_shell_parse_argv().  I do not think that g_shell_parse_argv is called
at all in the process of parsing configuration options.

The parsing of FirstVT is done in daemon/getvt.c in the get_free_vt*
functions, which are called by gdm_get_empty_vt_argument().  This
is called in daemon/server.c by gdm_server_start().  Immediately
after calling gdm_get_empty_vt_argument, it calls gdm_server_spawn().

This code looks as follows (in GDM 2.20.10).  Note that the call to
ve_first_word does call g_shell_parse_argv, but does pass in NULL as the
error argument, so that cannot be the problem.

	bin = ve_first_word (disp->command);

	if (bin == NULL) {
[...]
	} else if (bin[0] != '/') {

		GdmXserver *svr = gdm_daemon_config_find_xserver (bin);
		if (svr == NULL) {
[...]
		} else {
                        GError* error_p;
[...]
			g_shell_parse_argv (str, &svr_argc,
				&svr_command, &error_p);

			g_shell_parse_argv (disp->command, &argc,
				&argv, &error_p);

I note that error_p is never set to NULL.  So, I'm guessing that the
problem is that this variable isn't getting initialized to NULL, and
on your system this is triggering the assertion.

If you want to patch the code to set error_p to NULL, I think this
would resolve the problem.

I note that it only falls into this problematic code segment if the
Xserver binary is not specified by full path (note the test
"if (bin[0] != '/'" above).  So, if my analysis is right, then you
could avoid this problem by providing the full path to the Xserver
in your configuration.

If that isn't right, I have pointed you towards the code where the
problem is happening so others can do further analysis.

Brian


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]