bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Chong Yidong]

Hi Adrian, can you reproduce this problem?

> To reproduce do:
>  - start emacs from terminal with
>
>    emacs -nw
>
>  - evaluate the emacs lisp function
>
>    (set-frame-name "somestring")
>
> This will make Emacs v23 crash on my MacOSX 10.5.8 every time with the error:
>
>    Fatal Error (10)
>
> In my Emacs init file I now have something like
>
>   (if window-system (set-frame-name "something"))
>
> which eludes the crash.
>
> I downloaded Emacs 23 for MacOSX from URL
>
>   http://emacsformacosx.com/

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Adrian Robert]

On Oct 23, 2009, at 11:46 AM, Chong Yidong wrote:

> Hi Adrian, can you reproduce this problem?

I can on Snow Leopard and Tiger but this is in -nw mode and the stack  
trace (below) shows nothing involved from NS side.  Does it appear  
under other OS's?  The stack trace below shows it resulting from  
ns_set_name() called from x_implicitly_set_name.  ns_set_name does not  
check if it is an ns frame, but the X equivalent doesn't either.  It  
seems like something is going wrong earlier if x_implicitly_set_name  
is being called for a non-GUI frame.


-Adrian


#0  0x000000010023528a in ns_set_name (f=0x10140dc28, name=4297771651,  
explicit=0) at nsfns.m:524
#1  0x00000001002354e2 in x_implicitly_set_name (f=0x10140dc28,  
arg=4297771651, oldval=4320133129) at nsfns.m:587
#2  0x000000010003603b in x_consider_frame_title (frame=4315995180) at  
xdisp.c:9512
#3  0x0000000100036109 in prepare_menu_bars () at xdisp.c:9566
#4  0x000000010003a015 in redisplay_internal (preserve_echo_area=0) at  
xdisp.c:11472
#5  0x0000000100038c57 in redisplay () at xdisp.c:11048
#6  0x00000001000df199 in read_char (commandflag=1, nmaps=2,  
maps=0x7fff5fbfe440, prev_event=4320133129,  
used_mouse_menu=0x7fff5fbfe888, end_time=0x0) at keyboard.c:2708
#7  0x00000001000ec4c3 in read_key_sequence (keybuf=0x7fff5fbfea30,  
bufsize=30, prompt=4320133129, dont_downcase_last=0,  
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9462
#8  0x00000001000dba23 in command_loop_1 () at keyboard.c:1641
#9  0x00000001001897af in internal_condition_case (bfun=0x1000db5ae  
<command_loop_1>, handlers=4320212825, hfun=0x1000dad76 <cmd_error>)  
at eval.c:1490
#10 0x00000001000db24b in command_loop_2 () at keyboard.c:1358
#11 0x00000001001890d4 in internal_catch (tag=4320197385,  
func=0x1000db22a <command_loop_2>, arg=4320133129) at eval.c:1226
#12 0x00000001000db1f2 in command_loop () at keyboard.c:1337

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Chong Yidong]

Adrian Robert <adrian.b.robert@gmail.com> writes:

> On Oct 23, 2009, at 11:46 AM, Chong Yidong wrote:
>
>> Hi Adrian, can you reproduce this problem?
>
> I can on Snow Leopard and Tiger but this is in -nw mode and the stack
> trace (below) shows nothing involved from NS side.  Does it appear
> under other OS's?  The stack trace below shows it resulting from
> ns_set_name() called from x_implicitly_set_name.  ns_set_name does not
> check if it is an ns frame, but the X equivalent doesn't either.  It
> seems like something is going wrong earlier if x_implicitly_set_name
> is being called for a non-GUI frame.

No crash for me on GNU/Linux.  The x_implicity_set_name function *is*
called, but because `f->explicit_name' is non-zero (it's 1), that
function returns.

I think the problem is that ns_set_name should defer calling
FRAME_NS_VIEW until after line 542.  Maybe that fixes the bug; could you
check?

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Adrian Robert]

On Oct 23, 2009, at 12:59 PM, Chong Yidong wrote:

> Adrian Robert <adrian.b.robert@gmail.com> writes:
>
>> On Oct 23, 2009, at 11:46 AM, Chong Yidong wrote:
>>
>>> Hi Adrian, can you reproduce this problem?
>>
>> I can on Snow Leopard and Tiger but this is in -nw mode and the stack
>> trace (below) shows nothing involved from NS side.  Does it appear
>> under other OS's?  The stack trace below shows it resulting from
>> ns_set_name() called from x_implicitly_set_name.  ns_set_name does  
>> not
>> check if it is an ns frame, but the X equivalent doesn't either.  It
>> seems like something is going wrong earlier if x_implicitly_set_name
>> is being called for a non-GUI frame.
>
> No crash for me on GNU/Linux.  The x_implicity_set_name function *is*
> called, but because `f->explicit_name' is non-zero (it's 1), that
> function returns.
>
> I think the problem is that ns_set_name should defer calling
> FRAME_NS_VIEW until after line 542.  Maybe that fixes the bug; could  
> you
> check?

It fixes the crash, but nothing gets changed in the display either.   
On emacs-22 it sets something just to the right of the left set of  
dashes.  Could this be an additional bug in the NS code?

-Adrian

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Chong Yidong]

Adrian Robert <adrian.b.robert@gmail.com> writes:

> It fixes the crash, but nothing gets changed in the display either.
> On emacs-22 it sets something just to the right of the left set of
> dashes.  Could this be an additional bug in the NS code?

Maybe.  Is the `name' frame-parameter changed?

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[Glenn Morris]

Version: 23.2

Adrian Robert wrote:

>> I think the problem is that ns_set_name should defer calling
>> FRAME_NS_VIEW until after line 542. Maybe that fixes the bug; could
>> you check?
>
> It fixes the crash

I see it was installed 2009-10-24, for 23.2.

> , but nothing gets changed in the display either. On emacs-22 it sets
> something just to the right of the left set of dashes. Could this be
> an additional bug in the NS code?

I imagine that was a trivial issue due to ns-win.el messing with
mode-line-frame-identification, since fixed (bug#10051).

bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac

[robert]

To reproduce do:
 - start emacs from terminal with

   emacs -nw

 - evaluate the emacs lisp function

   (set-frame-name "somestring")

This will make Emacs v23 crash on my MacOSX 10.5.8 every time with the error:

   Fatal Error (10)

In my Emacs init file I now have something like

  (if window-system (set-frame-name "something"))

which eludes the crash.

I downloaded Emacs 23 for MacOSX from URL

  http://emacsformacosx.com/

yours,
/robert

In GNU Emacs 23.1.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-08-16 on black.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: en_US.UTF-8
  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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ ? 1 ; 2 c ESC x r e p TAB o r TAB RET

Recent messages:
("/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs" "-Q")
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...