UNBLOCK_INPUT in change_frame_size_1

UNBLOCK_INPUT in change_frame_size_1

[Dan Nicolaescu]

Shouldn't UNBLOCK_INPUT in dispnew.c:change_frame_size_1 be placed
after the call to record_unwind_protect?

record_unwind_protect calls grow_specdpl that in turn calls xrealloc
which might allocate memory.... 

change_frame_size_1 can be called like this:

window_change_signal -> change_frame_size -> change_frame_size_1 

I am not quite sure I understand the rules for BLOCK/UNBLOCK_INPUT but
the above looks suspicious.


This was inspired by the following bug reported for the multi-tty branch:

Han Boetes <han@mijncomputer.nl> writes:

  > I really don't know what I was doing, but here it is:
  > 
  > ~/nfs/Emacs/multi-tty/src% gdb =emacs ~/emacs.core
  > GNU gdb 6.3
  > Copyright 2004 Free Software Foundation, Inc.
  > GDB is free software, covered by the GNU General Public License, and you are
  > welcome to change it and/or distribute copies of it under certain conditions.
  > Type "show copying" to see the conditions.
  > There is absolutely no warranty for GDB.  Type "show warranty" for details.
  > This GDB was configured as "i386-unknown-openbsd3.9"...
  > Core was generated by `emacs'.
  > Program terminated with signal 11, Segmentation fault.
  > Reading symbols from /usr/lib/libossaudio.so.3.0...done.
  > Loaded symbols for /usr/lib/libossaudio.so.3.0
  > Reading symbols from /usr/lib/libncurses.so.10.0...done.
  > Loaded symbols for /usr/lib/libncurses.so.10.0
  > Reading symbols from /usr/lib/libm.so.2.1...done.
  > Loaded symbols for /usr/lib/libm.so.2.1
  > Reading symbols from /usr/lib/libc.so.39.0...done.
  > Loaded symbols for /usr/lib/libc.so.39.0
  > Reading symbols from /usr/libexec/ld.so...done.
  > Loaded symbols for /usr/libexec/ld.so
  > #0  0x08051798 in window_change_signal (signalnum=28) at /home/public/han/Emacs/multi-tty/src/dispnew.c:6069
  > 6069        get_tty_size (fileno (tty->input), &width, &height);
  > Environment variable "DISPLAY" not defined.
  > TERM = screen
  > Breakpoint 1 at 0x809bb5e: file /home/public/han/Emacs/multi-tty/src/emacs.c, line 465.
  > Breakpoint 2 at 0x80b1877: file /home/public/han/Emacs/multi-tty/src/sysdep.c, line 1441.
  > (gdb) bt
  > #0  0x08051798 in window_change_signal (signalnum=28) at /home/public/han/Emacs/multi-tty/src/dispnew.c:6069
  > #1  0x48e8502d in ?? ()
  > #2  0x0000001c in ?? ()
  > #3  0x00000000 in ?? ()
  > 
  > Lisp Backtrace:
  > "yes-or-no-p"
  > "kill-buffer"
  > "server-delete-client"
  > "server-sentinel"
  > (gdb) 
  > 
  > 
  > This is on OpenBSD, without X installed.
  > 
  > 
  > # Han
  > _______________________________________________
  > multi-tty mailing list
  > multi-tty@lists.fnord.hu
  > http://lists.fnord.hu/mailman/listinfo/multi-tty

Re: UNBLOCK_INPUT in change_frame_size_1

[Richard M. Stallman]

    Shouldn't UNBLOCK_INPUT in dispnew.c:change_frame_size_1 be placed
    after the call to record_unwind_protect?

    record_unwind_protect calls grow_specdpl that in turn calls xrealloc
    which might allocate memory.... 

No problem here.  xrealloc does BLOCK/UNBLOCK_INPUT.