Segfault in Emacs 23 with multi-tty

Segfault in Emacs 23 with multi-tty

[Daniel Hackney]

While testing the new multi-tty feature, I came across a segfault. I started up
an instance of emacs-snapshot in a terminal with the following command:

 $ emacs-snapshot -q -nw --eval "(setq server-name \"editor\")" -f server-start

I then opened a second terminal and ran:

 $ emacsclient -s editor -e '(ignore)'

The -e '(ignore)' is a no-op to give me a fresh frame. The second command opens
up a GTK frame connected to the first frame and both work just fine. The problem
comes when I try to kill the GTK frame. First, if I use
"save-buffers-kill-terminal", it kills the server in the terminal, which is not
what I want. "delete-frame" seemed to be the best choice. Unfortunately, when I
run "delete-frame" from the GTK frame, not only does the GTK frame close, but
the terminal frame (which is also the server) dies with a segfault:

  Fatal error (11)Segmentation fault (core dumped)

Here is the result of running it in GDB. Not terribly useful, but it might shed
some light on the situation.

#0  0x080d3bca in ?? ()
#1  0x08a13d80 in ?? ()
#2  0x088c4e60 in ?? ()
#3  0xbff3d998 in ?? ()
#4  0x08370868 in ?? ()
#5  0x088c4e60 in ?? ()
#6  0x088c4e64 in ?? ()
#7  0xbff3d9e8 in ?? ()
#8  0x08063062 in ?? ()
#9  0x084bfb28 in ?? ()
#10 0x0834de5d in ?? ()
#11 0x083508c9 in ?? ()
#12 0x083508f9 in ?? ()
#13 0x08062870 in ?? ()
#14 0xb7653170 in ?? () from /lib/tls/i686/cmov/libc.so.6
#15 0x08da9b00 in ?? ()
#16 0x08da9ae8 in ?? ()
#17 0x08903adc in ?? ()
#18 0x08a42c4c in ?? ()
#19 0xb787c8ac in __pthread_mutex_unlock_usercnt ()
   from /lib/tls/i686/cmov/libpthread.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

If I instead run the client in a tty (by adding the "-t" option), exiting via
both kill-terminal and delete-frame work as expected, killing the current
terminal without killing the server.

The packages I am using were acquired from here:

  http://ppa.launchpad.net/avassalotti/ubuntu

Obviously, the trace will not be of much use without the debugging symbols, but
the installation I used did not include them.

Here is additional information about my version of emacs.

In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.0)
 of 2007-10-31 on samarium
 (emacs-snapshot package, version 1:20071030-1~gutsy)
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--build' 'i486-linux-gnu' '--host'
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.0.60/leim'
'--with-x=yes' '--with-x-toolkit=gtk' '--enable-font-backend'
'--with-xft' '--with-freetype' 'build_alias=i486-linux-gnu'
'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN
-DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t


-- 
Daniel M. Hackney

Re: Segfault in Emacs 23 with multi-tty

[Dan Nicolaescu]

"Daniel Hackney" <dan@haxney.org> writes:

  > While testing the new multi-tty feature, I came across a segfault. I started up
  > an instance of emacs-snapshot in a terminal with the following command:
  > 
  >  $ emacs-snapshot -q -nw --eval "(setq server-name \"editor\")" -f server-start
  > 
  > I then opened a second terminal and ran:
  > 
  >  $ emacsclient -s editor -e '(ignore)'
  > 
  > The -e '(ignore)' is a no-op to give me a fresh frame. The second command opens
  > up a GTK frame connected to the first frame and both work just fine. The problem
  > comes when I try to kill the GTK frame. First, if I use
  > "save-buffers-kill-terminal", it kills the server in the terminal, which is not
  > what I want. "delete-frame" seemed to be the best choice. Unfortunately, when I
  > run "delete-frame" from the GTK frame, not only does the GTK frame close, but
  > the terminal frame (which is also the server) dies with a segfault:
  > 
  >   Fatal error (11)Segmentation fault (core dumped)

Thank you for your bug report.

This works fine for me for emacs checked today from the CVS branch
emacs-unicode-2 (i.e. what you call Emacs 23).

Please try a more up to date version and report again here if you have
any problems.

Re: Segfault in Emacs 23 with multi-tty

[Daniel Hackney]

On 12/9/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Daniel Hackney" <dan@haxney.org> writes:
>
>   > While testing the new multi-tty feature, I came across a segfault. I started up
>   > an instance of emacs-snapshot in a terminal with the following command:
>   >
>   >  $ emacs-snapshot -q -nw --eval "(setq server-name \"editor\")" -f server-start
>   >
>   > I then opened a second terminal and ran:
>   >
>   >  $ emacsclient -s editor -e '(ignore)'
>   >
>
> Thank you for your bug report.
>
> This works fine for me for emacs checked today from the CVS branch
> emacs-unicode-2 (i.e. what you call Emacs 23).
>
> Please try a more up to date version and report again here if you have
> any problems.

I tried the current emacs-unicode-2 branch which I got using git from
git://git.sv.gnu.org/emacs.git, using the commit
65a977059896b030055ff2b39513c32962519b6b. I compiled with

 $ ./configure --prefix=/home/frochild/Projects/emacs-bin --with-gtk
--with-xft CFLAGS="-O0 -g"

as recommended.

It did not segfault, but when closing the GTK window, the following was written
to stderr of the server instance:

(emacs:26151): Gdk-CRITICAL **: gdk_screen_get_display: assertion
`GDK_IS_SCREEN (screen)' failed

(emacs:26151): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(emacs:26151): GLib-GObject-CRITICAL **:
g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE
(instance)' failed

(emacs:26151): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(emacs:26151): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.14.1/gobject/gsignal.c:2180: invalid unclassed
object pointer for value type `GdkScreen'

(emacs:26151): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.14.1/gobject/gsignal.c:2180: invalid unclassed
object pointer for value type `GdkScreen'

(emacs:26151): GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed

The server did not terminate, however, so it is not that big of a problem. The
only issue is that unless it is redirected, this debug output is written to the
terminal on top of the existing emacs process, creating some garbage until C-l
is pressed. I do not know if this is beyond the scope of this bug report, but it
would be nice if GTK errors did not get written over an existing emacs terminal.

Recompiling without "-g" did not change this output.

-- 
Daniel M. Hackney

Re: Segfault in Emacs 23 with multi-tty

[Daniel Hackney]

On 12/12/07, Daniel Hackney <dan@haxney.org> wrote:
> I tried the current emacs-unicode-2 branch which I got using git from
> git://git.sv.gnu.org/emacs.git, using the commit
> 65a977059896b030055ff2b39513c32962519b6b. I compiled with
>
>  $ ./configure --prefix=/home/frochild/Projects/emacs-bin --with-gtk
> --with-xft CFLAGS="-O0 -g"
>
> as recommended.
>
> It did not segfault, but when closing the GTK window, the following was written
> to stderr of the server instance:
>
> -- SNIP --

I tried again with the font server, and did get it to segfault. This time I
configured with

 $ ./configure --prefix=/home/frochild/Projects/emacs-bin --with-gtk
--with-xft CFLAGS="-O0 -g" --enable-font-backend

And ran the server with

 $ emacs -q -nw --eval "(setq server-name \"editor\")" -f server-start
 --enable-font-backend

And the client with:

 $ emacsclient -s editor -c

It opened a window successfully, but when I ran "save-buffers-kill-terminal",
the server died with the following backtrace:

(gdb) where
#0  0x081183e3 in x_delete_terminal (terminal=0x8526838) at xterm.c:11721
#1  0x08063e60 in Fdelete_frame (frame=147149636, force=138254537) at
frame.c:1538
#2  0x081d954b in Ffuncall (nargs=2, args=0xbfe7cb50) at eval.c:3027
#3  0x0821322e in Fbyte_code (bytestr=143782139, vector=146664764,
maxdepth=48) at bytecode.c:679
#4  0x081d9d24 in funcall_lambda (fun=141123292, nargs=1,
arg_vector=0xbfe7ce84) at eval.c:3211
#5  0x081d97b3 in Ffuncall (nargs=2, args=0xbfe7ce80) at eval.c:3070
#6  0x0821322e in Fbyte_code (bytestr=144008315, vector=144391396,
maxdepth=24) at bytecode.c:679
#7  0x081d9d24 in funcall_lambda (fun=145145876, nargs=2,
arg_vector=0xbfe7d1a4) at eval.c:3211
#8  0x081d97b3 in Ffuncall (nargs=3, args=0xbfe7d1a0) at eval.c:3070
#9  0x0821322e in Fbyte_code (bytestr=136936147, vector=136936164,
maxdepth=32) at bytecode.c:679
#10 0x081d9d24 in funcall_lambda (fun=136936100, nargs=1,
arg_vector=0xbfe7d514) at eval.c:3211
#11 0x081d97b3 in Ffuncall (nargs=2, args=0xbfe7d510) at eval.c:3070
#12 0x081d4e87 in Fcall_interactively (function=143574953,
record_flag=138254537, keys=138292956)
    at callint.c:841
#13 0x0815ac87 in Fcommand_execute (cmd=143574953,
record_flag=138254537, keys=138254537,
    special=138254537) at keyboard.c:10479
#14 0x0814c0b0 in command_loop_1 () at keyboard.c:1941
#15 0x081d6ff2 in internal_condition_case (bfun=0x814a915
<command_loop_1>, handlers=138298769,
    hfun=0x814a2b9 <cmd_error>) at eval.c:1493
#16 0x0814a66e in command_loop_2 () at keyboard.c:1398
#17 0x081d6ad8 in internal_catch (tag=138293617, func=0x814a64b
<command_loop_2>, arg=138254537)
    at eval.c:1229
#18 0x0814a624 in command_loop () at keyboard.c:1377
#19 0x08149ec6 in recursive_edit_1 () at keyboard.c:986
#20 0x0814a034 in Frecursive_edit () at keyboard.c:1048
#21 0x081488a7 in main (argc=8, argv=0xbfe7e034) at emacs.c:1808

Hopefully this is a more useful backtrace. The same thing happened if Emacs was
launched without "--enable-font-backend", so it seems to be a problem with
the configure flag.

-- 
Daniel M. Hackney

Re: Segfault in Emacs 23 with multi-tty

[Richard Stallman]

I suggest you recompile with -O0 -g
in order to get a better backtrace.