GNU bug report logs - #9754
emacs -nv fails on glib 2.31

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ryan Lortie <desrt <at> desrt.ca>
To: submit <at> debbugs.gnu.org
Subject: emacs -nv fails on glib 2.31
Date: Fri, 14 Oct 2011 12:18:18 -0400

Packages: emacs
Version: 23.3

When running "emacs -nw" with the latest glib version, emacs gets stuck
in this infinite loop:

in xg_select at /usr/src/debug/emacs-23.3/src/xgselect.c:59

58	        while (n_gfds > gfds_size) 
59	          gfds_size *= 2;

This code is buggy in the case that gfds_size is zero (since clearly, no
matter how many times you multiply by 2, you're not going to increase
it).

Further down in the same file, you see:

155	void
156	xgselect_initialize ()
157	{
158	#if defined (USE_GTK) || defined (HAVE_GCONF)
159	  gfds_size = 128;
160	  gfds = xmalloc (sizeof (*gfds)*gfds_size);


So it's clear that xgselect_initialize() is not being called in the
"-nw" case.  That makes sense -- why initialise GTK when not using it?

The problem is that xg_select() is used even in the "-nw" case, without
_initialize() having been called.  This worked before because an unused
GMainContext used to have 0 fds in it, so n_gfds would be zero and
gfds_size would not need to be increased, causing the bug to be skipped
over.

Recent changes in glib have introduced one fd to every GMainContext to
deal with the inherent race introduced by signal delivery (closing a
longstanding glib bug).  This means that the untouched GMainContext no
longer has 0 fds -- but 1.  This is what is triggering the problem in
the buggy code above.


The solution to this problem is one of:

 - ensure xgselect_initialize() is always called
 - don't use xg_select in -nw case
 - fix the code to deal with the array being zero-sized and nuke
   xgselect_initialize()

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.