* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
@ 2009-10-20 14:38 robert
0 siblings, 0 replies; 7+ messages in thread
From: robert @ 2009-10-20 14:38 UTC (permalink / raw
To: bug-gnu-emacs
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...
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
@ 2009-10-23 15:46 Chong Yidong
2009-10-23 16:24 ` Adrian Robert
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2009-10-23 15:46 UTC (permalink / raw
To: Adrian Robert; +Cc: robert, 4765
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
2009-10-23 15:46 bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac Chong Yidong
@ 2009-10-23 16:24 ` Adrian Robert
2009-10-23 16:59 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: Adrian Robert @ 2009-10-23 16:24 UTC (permalink / raw
To: Chong Yidong; +Cc: robert, 4765
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
2009-10-23 16:24 ` Adrian Robert
@ 2009-10-23 16:59 ` Chong Yidong
2009-10-23 20:10 ` Adrian Robert
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2009-10-23 16:59 UTC (permalink / raw
To: Adrian Robert; +Cc: robert, 4765
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
2009-10-23 16:59 ` Chong Yidong
@ 2009-10-23 20:10 ` Adrian Robert
2009-10-23 20:53 ` Chong Yidong
2011-11-17 0:47 ` Glenn Morris
0 siblings, 2 replies; 7+ messages in thread
From: Adrian Robert @ 2009-10-23 20:10 UTC (permalink / raw
To: Chong Yidong; +Cc: robert, 4765
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
2009-10-23 20:10 ` Adrian Robert
@ 2009-10-23 20:53 ` Chong Yidong
2011-11-17 0:47 ` Glenn Morris
1 sibling, 0 replies; 7+ messages in thread
From: Chong Yidong @ 2009-10-23 20:53 UTC (permalink / raw
To: Adrian Robert; +Cc: robert, 4765
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac
2009-10-23 20:10 ` Adrian Robert
2009-10-23 20:53 ` Chong Yidong
@ 2011-11-17 0:47 ` Glenn Morris
1 sibling, 0 replies; 7+ messages in thread
From: Glenn Morris @ 2011-11-17 0:47 UTC (permalink / raw
To: 4765-done
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-11-17 0:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-23 15:46 bug#4765: 23.1; set-frame-name makes emacs -nw crash on mac Chong Yidong
2009-10-23 16:24 ` Adrian Robert
2009-10-23 16:59 ` Chong Yidong
2009-10-23 20:10 ` Adrian Robert
2009-10-23 20:53 ` Chong Yidong
2011-11-17 0:47 ` Glenn Morris
-- strict thread matches above, loose matches on Subject: below --
2009-10-20 14:38 robert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.