* bug#1052: segfault when resuming emacsclient -t in an xterm
@ 2008-09-29 17:46 ` Dan Nicolaescu
2008-10-01 0:45 ` bug#1052: marked as done (segfault when resuming emacsclient -t in an xterm) Emacs bug Tracking System
0 siblings, 1 reply; 5+ messages in thread
From: Dan Nicolaescu @ 2008-09-29 17:46 UTC (permalink / raw)
To: bug-gnu-emacs
This change:
2008-03-29 Stefan Monnier <monnier@iro.umontreal.ca>
* xt-mouse.el (xterm-mouse-mode): Use delete-terminal-functions.
(xterm-mouse-handle-delete-frame): Delete.
* term/xterm.el (terminal-init-xterm): Use delete-terminal-functions.
(xterm-turn-on-modify-other-keys, xterm-turn-off-modify-other-keys)
(xterm-remove-modify-other-keys): Lookup terminal rather than frame
in xterm-modify-other-keys-terminal-list.
causes the following:
emacs -Q -f server-start RET
in another xterm do:
emacsclient -t RET
C-z
emacsclient -t RET
C-z
fg
C-x C-c
at this point emacs segfaults with the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x007c3c81 in fwrite () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install Xaw3d.i386 e2fsprogs.i386 giflib.i386 glibc.i686 gpm.i386 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXmu.i386 libXpm.i386 libXrender.i386 libXt.i386 libjpeg.i386 libpng.i386 libtiff.i386 libxcb.i386 ncurses.i386 zlib.i386
(gdb) bt
#0 0x007c3c81 in fwrite () from /lib/libc.so.6
#1 0x08052f7a in Fsend_string_to_terminal (string=143248211, terminal=137808073)
at /tmp/emacs/src/dispnew.c:6473
#2 0x0816ed97 in Ffuncall (nargs=2, args=0xbf8e3b00)
at /tmp/emacs/src/eval.c:3047
#3 0x081a3680 in Fbyte_code (bytestr=143248515, vector=146901764, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#4 0x08170b73 in funcall_lambda (fun=146932996, nargs=1, arg_vector=0xbf8e3df4)
at /tmp/emacs/src/eval.c:3231
#5 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e3df0)
at /tmp/emacs/src/eval.c:3101
#6 0x0816fe01 in run_hook_with_args (nargs=2, args=0xbf8e3df0, cond=to_completion)
at /tmp/emacs/src/eval.c:2703
#7 0x0816ec36 in Ffuncall (nargs=3, args=0xbf8e3dec)
at /tmp/emacs/src/eval.c:3025
#8 0x0816dd6d in internal_condition_case_2 (bfun=0x816e8f0 <Ffuncall>, nargs=3, args=0xbf8e3dec,
handlers=137808121, hfun=0x8076a40 <safe_eval_handler>)
at /tmp/emacs/src/eval.c:1610
#9 0x0807f2aa in safe_call (nargs=3, args=0xbf8e3dec)
at /tmp/emacs/src/xdisp.c:2379
#10 0x0807f2fb in safe_call2 (fn=137949729, arg1=138024513, arg2=144406428)
at /tmp/emacs/src/xdisp.c:2420
#11 0x080cac9d in Fdelete_terminal (terminal=144406428, force=137808121)
at /tmp/emacs/src/terminal.c:331
#12 0x0805e8b3 in Fdelete_frame (frame=147003460, force=137808121)
at /tmp/emacs/src/frame.c:1525
#13 0x0816ed97 in Ffuncall (nargs=2, args=0xbf8e3f00)
at /tmp/emacs/src/eval.c:3047
#14 0x081a3680 in Fbyte_code (bytestr=143528187, vector=146950748, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#15 0x08170b73 in funcall_lambda (fun=147009116, nargs=1, arg_vector=0xbf8e4044)
at /tmp/emacs/src/eval.c:3231
#16 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e4040)
at /tmp/emacs/src/eval.c:3101
#17 0x081a3680 in Fbyte_code (bytestr=137997267, vector=144196452, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#18 0x08170b73 in funcall_lambda (fun=144184804, nargs=2, arg_vector=0xbf8e4174)
at /tmp/emacs/src/eval.c:3231
#19 0x0816ea9b in Ffuncall (nargs=3, args=0xbf8e4170)
at /tmp/emacs/src/eval.c:3101
#20 0x081a3680 in Fbyte_code (bytestr=136424043, vector=136424060, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#21 0x08170b73 in funcall_lambda (fun=136423996, nargs=1, arg_vector=0xbf8e42f4)
at /tmp/emacs/src/eval.c:3231
#22 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e42f0)
at /tmp/emacs/src/eval.c:3101
#23 0x0816c9ac in Fcall_interactively (function=143157089, record_flag=137808073, keys=137846508)
at /tmp/emacs/src/callint.c:857
#24 0x0816ed7b in Ffuncall (nargs=4, args=0xbf8e44b0)
at /tmp/emacs/src/eval.c:3050
#25 0x0816eec9 in call3 (fn=137972297, arg1=143157089, arg2=137808073, arg3=137808073)
at /tmp/emacs/src/emacs.c:1724
Lisp Backtrace:
"send-string-to-terminal" (0xbf8e3b04)
"xterm-remove-modify-other-keys" (0xbf8e3df4)
"run-hook-with-args" (0xbf8e3df0)
"delete-frame" (0xbf8e3f04)
"server-delete-client" (0xbf8e4044)
"server-save-buffers-kill-terminal" (0xbf8e4174)
"save-buffers-kill-terminal" (0xbf8e42f4)
"call-interactively" (0xbf8e44b4)
The reason is:
(gdb) frame 1
#1 0x08052f7a in Fsend_string_to_terminal (string=143248211, terminal=137808073)
at /tmp/emacs/src/dispnew.c:6473
6473 fwrite (SDATA (string), 1, SBYTES (string), tty->output);
(gdb) p tty->output
$1 = (FILE *) 0x0
The problem is that after the cited change
`xterm-remove-modify-other-keys' calls `terminal-live-p' (it was
previously using `frame-live-p') before calling
`send-string-to-terminal'.
`terminal-live-p' does not return false when tty->output is NULL ---> KABOOM.
BTW, unlike what the cited ChangeLog says,
`xterm-turn-off-modify-other-keys' still uses `frame-live-p'.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#1052: segfault when resuming emacsclient -t in an xterm
@ 2008-09-30 17:06 Chong Yidong
2008-09-30 18:18 ` Dan Nicolaescu
0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2008-09-30 17:06 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1052
> The problem is that after the cited change
> `xterm-remove-modify-other-keys' calls `terminal-live-p' (it was
> previously using `frame-live-p') before calling
> `send-string-to-terminal'.
>
> `terminal-live-p' does not return false when tty->output is NULL --->
> KABOOM.
Looks like it's just a matter of checking tty->output, then. WDYT?
*** trunk/src/dispnew.c.~1.419.~ 2008-09-28 16:09:43.000000000 -0400
--- trunk/src/dispnew.c 2008-09-30 13:02:21.000000000 -0400
***************
*** 6470,6477 ****
fwrite (SDATA (string), 1, SBYTES (string), tty->termscript);
fflush (tty->termscript);
}
! fwrite (SDATA (string), 1, SBYTES (string), tty->output);
! fflush (tty->output);
UNBLOCK_INPUT;
return Qnil;
}
--- 6470,6480 ----
fwrite (SDATA (string), 1, SBYTES (string), tty->termscript);
fflush (tty->termscript);
}
! if (tty->output)
! {
! fwrite (SDATA (string), 1, SBYTES (string), tty->output);
! fflush (tty->output);
! }
UNBLOCK_INPUT;
return Qnil;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#1052: segfault when resuming emacsclient -t in an xterm
2008-09-30 17:06 bug#1052: segfault when resuming emacsclient -t in an xterm Chong Yidong
@ 2008-09-30 18:18 ` Dan Nicolaescu
2008-09-30 22:06 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Dan Nicolaescu @ 2008-09-30 18:18 UTC (permalink / raw)
To: Chong Yidong; +Cc: 1052
Chong Yidong <cyd@stupidchicken.com> writes:
> > The problem is that after the cited change
> > `xterm-remove-modify-other-keys' calls `terminal-live-p' (it was
> > previously using `frame-live-p') before calling
> > `send-string-to-terminal'.
> >
> > `terminal-live-p' does not return false when tty->output is NULL --->
> > KABOOM.
>
> Looks like it's just a matter of checking tty->output, then. WDYT?
Not sure it's a good idea.
The test for `frame-live-p' was trying to make sure that the frame is OK
and `send-string-to-terminal' would work.
Not sure
1. why was it replaced with `terminal-live-p'
2. maybe `terminal-live-p' needs to be changed to detect this condition
> *** trunk/src/dispnew.c.~1.419.~ 2008-09-28 16:09:43.000000000 -0400
> --- trunk/src/dispnew.c 2008-09-30 13:02:21.000000000 -0400
> ***************
> *** 6470,6477 ****
> fwrite (SDATA (string), 1, SBYTES (string), tty->termscript);
> fflush (tty->termscript);
> }
> ! fwrite (SDATA (string), 1, SBYTES (string), tty->output);
> ! fflush (tty->output);
> UNBLOCK_INPUT;
> return Qnil;
> }
> --- 6470,6480 ----
> fwrite (SDATA (string), 1, SBYTES (string), tty->termscript);
> fflush (tty->termscript);
> }
> ! if (tty->output)
> ! {
> ! fwrite (SDATA (string), 1, SBYTES (string), tty->output);
> ! fflush (tty->output);
> ! }
> UNBLOCK_INPUT;
> return Qnil;
> }
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#1052: segfault when resuming emacsclient -t in an xterm
2008-09-30 18:18 ` Dan Nicolaescu
@ 2008-09-30 22:06 ` Stefan Monnier
0 siblings, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2008-09-30 22:06 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1052, Chong Yidong
>> > The problem is that after the cited change
>> > `xterm-remove-modify-other-keys' calls `terminal-live-p' (it was
>> > previously using `frame-live-p') before calling
>> > `send-string-to-terminal'.
>> >
>> > `terminal-live-p' does not return false when tty->output is NULL --->
>> > KABOOM.
>>
>> Looks like it's just a matter of checking tty->output, then. WDYT?
> Not sure it's a good idea.
> The test for `frame-live-p' was trying to make sure that the frame is OK
> and `send-string-to-terminal' would work.
> Not sure
> 1. why was it replaced with `terminal-live-p'
Because the function receives a `terminal' argument.
> 2. maybe `terminal-live-p' needs to be changed to detect this condition
I think there are 2 problems:
1- xterm-remove-modify-other-keys forgets to pass `terminal'
to `send-string-to-terminal'. Hopefully, I've just fixed it, so that
your recipe should not causes a segfault any more.
2- send-string-to-terminal causes a segfault is called for a terminal
that is suspended. I've made it signal an error.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#1052: marked as done (segfault when resuming emacsclient -t in an xterm)
2008-09-29 17:46 ` bug#1052: segfault when resuming emacsclient -t in an xterm Dan Nicolaescu
@ 2008-10-01 0:45 ` Emacs bug Tracking System
0 siblings, 0 replies; 5+ messages in thread
From: Emacs bug Tracking System @ 2008-10-01 0:45 UTC (permalink / raw)
To: Dan Nicolaescu
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
Your message dated Tue, 30 Sep 2008 17:36:22 -0700 (PDT)
with message-id <200810010036.m910aM6C018539@mothra.ics.uci.edu>
and subject line Re: bug#1052: segfault when resuming emacsclient -t in an xterm
has caused the Emacs bug report #1052,
regarding segfault when resuming emacsclient -t in an xterm
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)
--
1052: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1052
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems
[-- Attachment #2: Type: message/rfc822, Size: 7338 bytes --]
From: Dan Nicolaescu <dann@ics.uci.edu>
To: bug-gnu-emacs@gnu.org
Subject: segfault when resuming emacsclient -t in an xterm
Date: Mon, 29 Sep 2008 10:46:26 -0700 (PDT)
Message-ID: <200809291746.m8THkQE1005918@mothra.ics.uci.edu>
This change:
2008-03-29 Stefan Monnier <monnier@iro.umontreal.ca>
* xt-mouse.el (xterm-mouse-mode): Use delete-terminal-functions.
(xterm-mouse-handle-delete-frame): Delete.
* term/xterm.el (terminal-init-xterm): Use delete-terminal-functions.
(xterm-turn-on-modify-other-keys, xterm-turn-off-modify-other-keys)
(xterm-remove-modify-other-keys): Lookup terminal rather than frame
in xterm-modify-other-keys-terminal-list.
causes the following:
emacs -Q -f server-start RET
in another xterm do:
emacsclient -t RET
C-z
emacsclient -t RET
C-z
fg
C-x C-c
at this point emacs segfaults with the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x007c3c81 in fwrite () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install Xaw3d.i386 e2fsprogs.i386 giflib.i386 glibc.i686 gpm.i386 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXmu.i386 libXpm.i386 libXrender.i386 libXt.i386 libjpeg.i386 libpng.i386 libtiff.i386 libxcb.i386 ncurses.i386 zlib.i386
(gdb) bt
#0 0x007c3c81 in fwrite () from /lib/libc.so.6
#1 0x08052f7a in Fsend_string_to_terminal (string=143248211, terminal=137808073)
at /tmp/emacs/src/dispnew.c:6473
#2 0x0816ed97 in Ffuncall (nargs=2, args=0xbf8e3b00)
at /tmp/emacs/src/eval.c:3047
#3 0x081a3680 in Fbyte_code (bytestr=143248515, vector=146901764, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#4 0x08170b73 in funcall_lambda (fun=146932996, nargs=1, arg_vector=0xbf8e3df4)
at /tmp/emacs/src/eval.c:3231
#5 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e3df0)
at /tmp/emacs/src/eval.c:3101
#6 0x0816fe01 in run_hook_with_args (nargs=2, args=0xbf8e3df0, cond=to_completion)
at /tmp/emacs/src/eval.c:2703
#7 0x0816ec36 in Ffuncall (nargs=3, args=0xbf8e3dec)
at /tmp/emacs/src/eval.c:3025
#8 0x0816dd6d in internal_condition_case_2 (bfun=0x816e8f0 <Ffuncall>, nargs=3, args=0xbf8e3dec,
handlers=137808121, hfun=0x8076a40 <safe_eval_handler>)
at /tmp/emacs/src/eval.c:1610
#9 0x0807f2aa in safe_call (nargs=3, args=0xbf8e3dec)
at /tmp/emacs/src/xdisp.c:2379
#10 0x0807f2fb in safe_call2 (fn=137949729, arg1=138024513, arg2=144406428)
at /tmp/emacs/src/xdisp.c:2420
#11 0x080cac9d in Fdelete_terminal (terminal=144406428, force=137808121)
at /tmp/emacs/src/terminal.c:331
#12 0x0805e8b3 in Fdelete_frame (frame=147003460, force=137808121)
at /tmp/emacs/src/frame.c:1525
#13 0x0816ed97 in Ffuncall (nargs=2, args=0xbf8e3f00)
at /tmp/emacs/src/eval.c:3047
#14 0x081a3680 in Fbyte_code (bytestr=143528187, vector=146950748, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#15 0x08170b73 in funcall_lambda (fun=147009116, nargs=1, arg_vector=0xbf8e4044)
at /tmp/emacs/src/eval.c:3231
#16 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e4040)
at /tmp/emacs/src/eval.c:3101
#17 0x081a3680 in Fbyte_code (bytestr=137997267, vector=144196452, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#18 0x08170b73 in funcall_lambda (fun=144184804, nargs=2, arg_vector=0xbf8e4174)
at /tmp/emacs/src/eval.c:3231
#19 0x0816ea9b in Ffuncall (nargs=3, args=0xbf8e4170)
at /tmp/emacs/src/eval.c:3101
#20 0x081a3680 in Fbyte_code (bytestr=136424043, vector=136424060, maxdepth=<value optimized out>)
at /tmp/emacs/src/bytecode.c:678
#21 0x08170b73 in funcall_lambda (fun=136423996, nargs=1, arg_vector=0xbf8e42f4)
at /tmp/emacs/src/eval.c:3231
#22 0x0816ea9b in Ffuncall (nargs=2, args=0xbf8e42f0)
at /tmp/emacs/src/eval.c:3101
#23 0x0816c9ac in Fcall_interactively (function=143157089, record_flag=137808073, keys=137846508)
at /tmp/emacs/src/callint.c:857
#24 0x0816ed7b in Ffuncall (nargs=4, args=0xbf8e44b0)
at /tmp/emacs/src/eval.c:3050
#25 0x0816eec9 in call3 (fn=137972297, arg1=143157089, arg2=137808073, arg3=137808073)
at /tmp/emacs/src/emacs.c:1724
Lisp Backtrace:
"send-string-to-terminal" (0xbf8e3b04)
"xterm-remove-modify-other-keys" (0xbf8e3df4)
"run-hook-with-args" (0xbf8e3df0)
"delete-frame" (0xbf8e3f04)
"server-delete-client" (0xbf8e4044)
"server-save-buffers-kill-terminal" (0xbf8e4174)
"save-buffers-kill-terminal" (0xbf8e42f4)
"call-interactively" (0xbf8e44b4)
The reason is:
(gdb) frame 1
#1 0x08052f7a in Fsend_string_to_terminal (string=143248211, terminal=137808073)
at /tmp/emacs/src/dispnew.c:6473
6473 fwrite (SDATA (string), 1, SBYTES (string), tty->output);
(gdb) p tty->output
$1 = (FILE *) 0x0
The problem is that after the cited change
`xterm-remove-modify-other-keys' calls `terminal-live-p' (it was
previously using `frame-live-p') before calling
`send-string-to-terminal'.
`terminal-live-p' does not return false when tty->output is NULL ---> KABOOM.
BTW, unlike what the cited ChangeLog says,
`xterm-turn-off-modify-other-keys' still uses `frame-live-p'.
[-- Attachment #3: Type: message/rfc822, Size: 2356 bytes --]
From: Dan Nicolaescu <dann@ics.uci.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: 1052-done@emacsbugs.donarmstrong.com, Chong Yidong <cyd@stupidchicken.com>
Subject: Re: bug#1052: segfault when resuming emacsclient -t in an xterm
Date: Tue, 30 Sep 2008 17:36:22 -0700 (PDT)
Message-ID: <200810010036.m910aM6C018539@mothra.ics.uci.edu>
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> I think there are 2 problems:
> 1- xterm-remove-modify-other-keys forgets to pass `terminal'
> to `send-string-to-terminal'. Hopefully, I've just fixed it, so that
> your recipe should not causes a segfault any more.
>
> 2- send-string-to-terminal causes a segfault is called for a terminal
> that is suspended. I've made it signal an error.
Thank you, your changes seem to have fixed the problem.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-10-01 0:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200810010036.m910aM6C018539@mothra.ics.uci.edu>
2008-09-29 17:46 ` bug#1052: segfault when resuming emacsclient -t in an xterm Dan Nicolaescu
2008-10-01 0:45 ` bug#1052: marked as done (segfault when resuming emacsclient -t in an xterm) Emacs bug Tracking System
2008-09-30 17:06 bug#1052: segfault when resuming emacsclient -t in an xterm Chong Yidong
2008-09-30 18:18 ` Dan Nicolaescu
2008-09-30 22:06 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).