bug#17386: 24.3.90; emacs_abort in cmcheckmagic

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Context : I was in an "emacsclient -t" over ssh session. I noticed emacs
didn't respond (but I don't know if it was emacs or the ssh connection),
so I started another ssh session, ran "emacsclient -t" again but only
part of the emacs frame was drawn (maybe just the mode line, I'm not too
sure I didn't pay much attention) -- I guess that's when it crashed
because when I tried starting emacsclient again, nothing happened.

Here's the backtrace:


[-- Attachment #2: gdb.2014-04-25_17-15.txt --]
[-- Type: text/plain, Size: 12145 bytes --]

Reading symbols from /home/youngfrog/sources/running-emacs/src/emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x817f3cc: file emacs.c, line 351.
Temporary breakpoint 2 at 0x81a47f6: file sysdep.c, line 854.
Starting program: /home/youngfrog/sources/running-emacs/src/emacs -nw
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb6389b40 (LWP 856)]
[New Thread 0xb5801b40 (LWP 859)]
[New Thread 0xb4e11b40 (LWP 860)]
[New Thread 0xb286db40 (LWP 1858)]
[New Thread 0xb206cb40 (LWP 1859)]

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:351
351	  signal (sig, SIG_DFL);
#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:351
#1  0x081a5eaf in emacs_abort () at sysdep.c:2131
#2  0x0812f8fb in cmcheckmagic (tty=0x897ee80) at cm.c:120
#3  0x0813284c in tty_write_glyphs (f=0x85c46d0, string=0xb59fdef4, len=80) at term.c:778
#4  0x0813b78e in write_glyphs (f=0x85c46d0, string=0xb59fd3b4, len=80) at terminal.c:162
#5  0x08060881 in update_frame_line (f=0x85c46d0, vpos=63) at dispnew.c:4791
#6  0x0805fbd3 in update_frame_1 (f=0x85c46d0, force_p=true, inhibit_id_p=false) at dispnew.c:4461
#7  0x0805ca64 in update_frame (f=0x85c46d0, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3073
#8  0x0809bbe6 in redisplay_internal () at xdisp.c:13810
#9  0x0809c49b in redisplay_preserve_echo_area (from_where=2) at xdisp.c:14024
#10 0x08063e66 in Fredisplay (force=140216258) at dispnew.c:5834
#11 0x0821420d in Ffuncall (nargs=1, args=0xbfff8c40) at eval.c:2815
#12 0x082552e6 in exec_byte_code (bytestr=137815633, vector=137815653, maxdepth=28, args_template=3076, nargs=1, args=0xbfff8f5c) at bytecode.c:916
#13 0x082149e5 in funcall_lambda (fun=137815613, nargs=1, arg_vector=0xbfff8f58) at eval.c:2983
#14 0x08214441 in Ffuncall (nargs=2, args=0xbfff8f54) at eval.c:2864
#15 0x082552e6 in exec_byte_code (bytestr=149598521, vector=153892389, maxdepth=32, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#16 0x08214daf in funcall_lambda (fun=153892781, nargs=5, arg_vector=0x92c3625) at eval.c:3049
#17 0x08214441 in Ffuncall (nargs=6, args=0xbfff9284) at eval.c:2864
#18 0x082552e6 in exec_byte_code (bytestr=150002009, vector=153942869, maxdepth=32, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#19 0x08214daf in funcall_lambda (fun=153942909, nargs=1, arg_vector=0x92cfb55) at eval.c:3049
#20 0x08214441 in Ffuncall (nargs=2, args=0xbfff95b8) at eval.c:2864
#21 0x08213cfb in call1 (fn=153942909, arg1=270524753) at eval.c:2614
#22 0x0821eaab in mapcar1 (leni=1, vals=0x0, fn=153942909, seq=150898822) at fns.c:2329
#23 0x0821ee2d in Fmapc (function=153942909, sequence=150898822) at fns.c:2418
#24 0x08214233 in Ffuncall (nargs=3, args=0xbfff9704) at eval.c:2818
#25 0x082552e6 in exec_byte_code (bytestr=150002441, vector=153942933, maxdepth=20, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#26 0x08214daf in funcall_lambda (fun=153942965, nargs=4, arg_vector=0x92cfb95) at eval.c:3049
#27 0x08214441 in Ffuncall (nargs=5, args=0xbfff9a24) at eval.c:2864
#28 0x082552e6 in exec_byte_code (bytestr=150207137, vector=153878309, maxdepth=28, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#29 0x08214daf in funcall_lambda (fun=153878445, nargs=2, arg_vector=0x92bff25) at eval.c:3049
#30 0x082146ff in apply_lambda (fun=153878445, args=150701286) at eval.c:2924
#31 0x082130ff in eval_sub (form=150701278) at eval.c:2230
#32 0x08211055 in internal_lisp_condition_case (var=141940154, bodyform=150701278, handlers=150701382) at eval.c:1323
#33 0x082561b4 in exec_byte_code (bytestr=150208865, vector=153878277, maxdepth=12, args_template=140216258, nargs=0, args=0x0) at bytecode.c:1162
#34 0x08214daf in funcall_lambda (fun=153820901, nargs=2, arg_vector=0x92bff05) at eval.c:3049
#35 0x08214441 in Ffuncall (nargs=3, args=0xbfffa1c4) at eval.c:2864
#36 0x082552e6 in exec_byte_code (bytestr=150219425, vector=153820621, maxdepth=12, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#37 0x08214daf in funcall_lambda (fun=153820637, nargs=1, arg_vector=0x92b1dcd) at eval.c:3049
#38 0x08214441 in Ffuncall (nargs=2, args=0xbfffa4d8) at eval.c:2864
#39 0x08213cfb in call1 (fn=153820637, arg1=270583761) at eval.c:2614
#40 0x0821eaab in mapcar1 (leni=2, vals=0x0, fn=153820637, seq=150625006) at fns.c:2329
#41 0x0821ee2d in Fmapc (function=153820637, sequence=150625006) at fns.c:2418
#42 0x08214233 in Ffuncall (nargs=3, args=0xbfffa624) at eval.c:2818
#43 0x082552e6 in exec_byte_code (bytestr=150236201, vector=153820661, maxdepth=28, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#44 0x08214daf in funcall_lambda (fun=153820725, nargs=2, arg_vector=0x92b1df5) at eval.c:3049
#45 0x08214441 in Ffuncall (nargs=3, args=0xbfffa940) at eval.c:2864
#46 0x08213770 in Fapply (nargs=2, args=0xbfffa9c4) at eval.c:2354
#47 0x08213ca6 in apply1 (fn=152674370, arg=148493038) at eval.c:2588
#48 0x08260e85 in read_process_output_call (fun_and_args=148477358) at process.c:4964
#49 0x08211291 in internal_condition_case_1 (bfun=0x8260df8 <read_process_output_call>, arg=148477358, handlers=140216258, hfun=0x8260e87 <read_process_output_error_handler>) at eval.c:1378
#50 0x0826144c in read_and_dispose_of_process_output (p=0x92c2f00, 
    chars=0xbfffaab0 ":EminenceHC!~eminenceh@173-167-242-193-ip-static.hfc.comcastbusiness.net QUIT :Remote host closed the connection\r\n:rudybot!~luser@54.215.10.197 PRIVMSG #emacs :aidalgol: derp\r\nI\243\247\b\002", nbytes=176, 
    coding=0x9014400) at process.c:5177
#51 0x0826116e in read_process_output (proc=153890565, channel=176) at process.c:5086
#52 0x08260826 in wait_reading_process_output (time_limit=0, nsecs=10000000, read_kbd=0, do_display=false, wait_for_cell=140216258, wait_proc=0xceba8e0, just_wait_proc=0) at process.c:4808
#53 0x0825eea8 in Faccept_process_output (process=216770789, seconds=176315135, millisec=40, just_this_one=140216258) at process.c:4000
#54 0x0821429a in Ffuncall (nargs=4, args=0xbfffbf64) at eval.c:2826
#55 0x082552e6 in exec_byte_code (bytestr=169508313, vector=177807349, maxdepth=28, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#56 0x08214daf in funcall_lambda (fun=177807373, nargs=1, arg_vector=0xa991ff5) at eval.c:3049
#57 0x08214441 in Ffuncall (nargs=2, args=0xbfffc284) at eval.c:2864
#58 0x082552e6 in exec_byte_code (bytestr=170275961, vector=155679221, maxdepth=20, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#59 0x08214daf in funcall_lambda (fun=155679301, nargs=1, arg_vector=0x94779f5) at eval.c:3049
#60 0x08214441 in Ffuncall (nargs=2, args=0xbfffc5a4) at eval.c:2864
#61 0x082552e6 in exec_byte_code (bytestr=170275137, vector=155679325, maxdepth=20, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#62 0x08214daf in funcall_lambda (fun=155679389, nargs=0, arg_vector=0x9477a5d) at eval.c:3049
#63 0x08214441 in Ffuncall (nargs=1, args=0xbfffc8c4) at eval.c:2864
#64 0x082552e6 in exec_byte_code (bytestr=170465169, vector=175695285, maxdepth=24, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#65 0x08214daf in funcall_lambda (fun=175695421, nargs=0, arg_vector=0xa78e5b5) at eval.c:3049
#66 0x08214441 in Ffuncall (nargs=1, args=0xbfffcbf0) at eval.c:2864
#67 0x08212d9a in eval_sub (form=172590406) at eval.c:2157
#68 0x08211055 in internal_lisp_condition_case (var=140216258, bodyform=172590406, handlers=172590526) at eval.c:1323
#69 0x082561b4 in exec_byte_code (bytestr=170486521, vector=153458157, maxdepth=16, args_template=140216258, nargs=0, args=0x0) at bytecode.c:1162
#70 0x08254740 in Fbyte_code (bytestr=170486521, vector=153458157, maxdepth=16) at bytecode.c:482
#71 0x08212ef8 in eval_sub (form=172590878) at eval.c:2191
#72 0x082106ea in internal_catch (tag=156315122, func=0x82128d5 <eval_sub>, arg=172590878) at eval.c:1118
#73 0x08255ec6 in exec_byte_code (bytestr=170486777, vector=153458213, maxdepth=12, args_template=140216258, nargs=0, args=0x0) at bytecode.c:1097
#74 0x08214daf in funcall_lambda (fun=153458245, nargs=4, arg_vector=0x9259625) at eval.c:3049
#75 0x08214441 in Ffuncall (nargs=5, args=0xbfffd3f4) at eval.c:2864
#76 0x082552e6 in exec_byte_code (bytestr=170465385, vector=175695445, maxdepth=20, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#77 0x08214daf in funcall_lambda (fun=175695469, nargs=3, arg_vector=0xa78e655) at eval.c:3049
#78 0x08214441 in Ffuncall (nargs=4, args=0xbfffd714) at eval.c:2864
#79 0x082552e6 in exec_byte_code (bytestr=164681025, vector=170601165, maxdepth=24, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#80 0x08214daf in funcall_lambda (fun=158907597, nargs=3, arg_vector=0xa2b2acd) at eval.c:3049
#81 0x08214441 in Ffuncall (nargs=4, args=0xbfffda34) at eval.c:2864
#82 0x082552e6 in exec_byte_code (bytestr=165635177, vector=157953309, maxdepth=28, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#83 0x08214daf in funcall_lambda (fun=157100309, nargs=3, arg_vector=0x96a2d1d) at eval.c:3049
#84 0x08214441 in Ffuncall (nargs=4, args=0xbfffdd54) at eval.c:2864
#85 0x082552e6 in exec_byte_code (bytestr=165597273, vector=153689061, maxdepth=36, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#86 0x08214daf in funcall_lambda (fun=157100117, nargs=3, arg_vector=0x9291be5) at eval.c:3049
#87 0x08214441 in Ffuncall (nargs=4, args=0xbfffe084) at eval.c:2864
#88 0x082552e6 in exec_byte_code (bytestr=167134361, vector=178002557, maxdepth=16, args_template=140216258, nargs=0, args=0x0) at bytecode.c:916
#89 0x08214daf in funcall_lambda (fun=178002653, nargs=1, arg_vector=0xa9c1a7d) at eval.c:3049
#90 0x08214441 in Ffuncall (nargs=2, args=0xbfffe3f0) at eval.c:2864
#91 0x0820d957 in Fcall_interactively (function=153554762, record_flag=140216258, keys=140225101) at callint.c:836
#92 0x08214262 in Ffuncall (nargs=4, args=0xbfffe62c) at eval.c:2822
#93 0x082552e6 in exec_byte_code (bytestr=138217873, vector=138217893, maxdepth=52, args_template=4100, nargs=1, args=0xbfffe960) at bytecode.c:916
#94 0x082149e5 in funcall_lambda (fun=138217853, nargs=1, arg_vector=0xbfffe95c) at eval.c:2983
#95 0x08214441 in Ffuncall (nargs=2, args=0xbfffe958) at eval.c:2864
#96 0x08213cfb in call1 (fn=140242714, arg1=153554762) at eval.c:2614
#97 0x08183a97 in command_loop_1 () at keyboard.c:1556
#98 0x0821116f in internal_condition_case (bfun=0x818342b <command_loop_1>, handlers=140249338, hfun=0x8182c5a <cmd_error>) at eval.c:1354
#99 0x081830d5 in command_loop_2 (ignore=140216258) at keyboard.c:1174
#100 0x082106ea in internal_catch (tag=140247386, func=0x81830b1 <command_loop_2>, arg=140216258) at eval.c:1118
#101 0x0818308f in command_loop () at keyboard.c:1153
#102 0x081827ee in recursive_edit_1 () at keyboard.c:777
#103 0x081829ae in Frecursive_edit () at keyboard.c:845
#104 0x08180cef in main (argc=2, argv=0xbfffecc4) at emacs.c:1646

Lisp Backtrace:
"redisplay_internal (C function)" (0x85a5d90)
"redisplay" (0xbfff8c44)
"sit-for" (0xbfff8f58)
"rcirc-print" (0xbfff9288)
0x92cfb78 PVEC_COMPILED
"mapc" (0xbfff9708)
"rcirc-handler-QUIT" (0xbfff9a28)
"rcirc-process-server-response-1" (0xbfff9cb0)
"rcirc-process-server-response" (0xbfffa1c8)
0x92b1dd8 PVEC_COMPILED
"mapc" (0xbfffa628)
"rcirc-filter" (0xbfffa944)
"accept-process-output" (0xbfffbf68)
"nnheader-accept-process-output" (0xbfffc288)
"nntp-accept-process-output" (0xbfffc5a8)
"nntp-accept-response" (0xbfffc8c8)
0xa78e638 PVEC_COMPILED
"funcall" (0xbfffcbf0)
"byte-code" (0xbfffd000)
"nntp-with-open-group-function" (0xbfffd3f8)
"nntp-finish-retrieve-group-infos" (0xbfffd718)
"gnus-finish-retrieve-group-infos" (0xbfffda38)
"gnus-read-active-for-groups" (0xbfffdd58)
"gnus-get-unread-articles" (0xbfffe088)
"gnus-group-get-new-news" (0xbfffe3f4)
"call-interactively" (0xbfffe630)
"command-execute" (0xbfffe95c)

[-- Attachment #3: Type: text/plain, Size: 420 bytes --]



In GNU Emacs 24.3.90.8 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-04-25 on geodiff-mac3
Windowing system distributor `The X.Org Foundation', version 11.0.11304000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --with-x-toolkit=lucid --enable-checking 'CFLAGS= -O0 -g3''

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Fri, 02 May 2014 07:08:18 +0200
> 
> Context : I was in an "emacsclient -t" over ssh session. I noticed emacs
> didn't respond (but I don't know if it was emacs or the ssh connection),
> so I started another ssh session, ran "emacsclient -t" again but only
> part of the emacs frame was drawn (maybe just the mode line, I'm not too
> sure I didn't pay much attention) -- I guess that's when it crashed
> because when I tried starting emacsclient again, nothing happened.
> 
> Here's the backtrace:
> 
> 
> [2:text/plain Hide]
> 
> Reading symbols from /home/youngfrog/sources/running-emacs/src/emacs...done.
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> DISPLAY = :0.0
> TERM = screen
> Breakpoint 1 at 0x817f3cc: file emacs.c, line 351.
> Temporary breakpoint 2 at 0x81a47f6: file sysdep.c, line 854.
> Starting program: /home/youngfrog/sources/running-emacs/src/emacs -nw
> warning: Could not load shared library symbols for linux-gate.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0xb6389b40 (LWP 856)]
> [New Thread 0xb5801b40 (LWP 859)]
> [New Thread 0xb4e11b40 (LWP 860)]
> [New Thread 0xb286db40 (LWP 1858)]
> [New Thread 0xb206cb40 (LWP 1859)]
> 
> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:351
> 351	  signal (sig, SIG_DFL);
> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:351
> #1  0x081a5eaf in emacs_abort () at sysdep.c:2131
> #2  0x0812f8fb in cmcheckmagic (tty=0x897ee80) at cm.c:120
> #3  0x0813284c in tty_write_glyphs (f=0x85c46d0, string=0xb59fdef4, len=80) at term.c:778

Which part of the condition on line 119 of cm.c caused the call to
emacs_abort?

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Le 02/05/2014 09:28, Eli Zaretskii a écrit :
> Which part of the condition on line 119 of cm.c caused the call to
> emacs_abort?

The inequality :

(gdb) f 2
#2  0x0812f8fb in cmcheckmagic (tty=0x897ee80) at cm.c:120
120             emacs_abort ();
(gdb) l
115     cmcheckmagic (struct tty_display_info *tty)
116     {
117       if (curX (tty) == FrameCols (tty))
118         {
119           if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
120             emacs_abort ();
121           if (tty->termscript)
122             putc ('\r', tty->termscript);
123           putc ('\r', tty->output);
124           if (tty->termscript)
(gdb) p MagicWrap(tty)
$1 = true
(gdb) p curY(tty)
$2 = 63
(gdb) p FrameRows (tty)
$3 = 23
(gdb) 

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> Date: Fri, 02 May 2014 10:14:18 +0200
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> CC: 17386@debbugs.gnu.org
> 
> Le 02/05/2014 09:28, Eli Zaretskii a écrit :
> > Which part of the condition on line 119 of cm.c caused the call to
> > emacs_abort?
> 
> The inequality :
> 
> (gdb) f 2
> #2  0x0812f8fb in cmcheckmagic (tty=0x897ee80) at cm.c:120
> 120             emacs_abort ();
> (gdb) l
> 115     cmcheckmagic (struct tty_display_info *tty)
> 116     {
> 117       if (curX (tty) == FrameCols (tty))
> 118         {
> 119           if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
> 120             emacs_abort ();
> 121           if (tty->termscript)
> 122             putc ('\r', tty->termscript);
> 123           putc ('\r', tty->output);
> 124           if (tty->termscript)
> (gdb) p MagicWrap(tty)
> $1 = true
> (gdb) p curY(tty)
> $2 = 63
> (gdb) p FrameRows (tty)
> $3 = 23

Then I don't think this crash is interesting.  It seems like you
connected with a second emacsclient in the middle of a potentially
already confused session, which caused Emacs to be confused about the
number of rows on your terminal.  (Which one is true: 64 or 23?)

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 02 May 2014 10:14:18 +0200
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> CC: 17386@debbugs.gnu.org
>> 
>> Le 02/05/2014 09:28, Eli Zaretskii a écrit :
>> > Which part of the condition on line 119 of cm.c caused the call to
>> > emacs_abort?
>> 
>> The inequality :
>> 
>> (gdb) f 2
>> #2  0x0812f8fb in cmcheckmagic (tty=0x897ee80) at cm.c:120
>> 120             emacs_abort ();
>> (gdb) l
>> 115     cmcheckmagic (struct tty_display_info *tty)
>> 116     {
>> 117       if (curX (tty) == FrameCols (tty))
>> 118         {
>> 119           if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
>> 120             emacs_abort ();
>> 121           if (tty->termscript)
>> 122             putc ('\r', tty->termscript);
>> 123           putc ('\r', tty->output);
>> 124           if (tty->termscript)
>> (gdb) p MagicWrap(tty)
>> $1 = true
>> (gdb) p curY(tty)
>> $2 = 63
>> (gdb) p FrameRows (tty)
>> $3 = 23
>
> Then I don't think this crash is interesting.

Sorry about that.

> It seems like you connected with a second emacsclient in the middle of
> a potentially already confused session, which caused Emacs to be
> confused about the number of rows on your terminal. (Which one is
> true: 64 or 23?)

63 is the exact number of lines I can put in a buffer when
gnome-terminal is maximized on the computer where emacs is running.

If I run gnome-terminal on my laptop (from which I was ssh'ing when the
crash happened), I count 22 lines at the default window size, and 41
when the window is maximized (window, in the "X window" sense).

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
> Date: Fri, 02 May 2014 11:45:23 +0200
> 
> > It seems like you connected with a second emacsclient in the middle of
> > a potentially already confused session, which caused Emacs to be
> > confused about the number of rows on your terminal. (Which one is
> > true: 64 or 23?)
> 
> 63 is the exact number of lines I can put in a buffer when
> gnome-terminal is maximized on the computer where emacs is running.
> 
> If I run gnome-terminal on my laptop (from which I was ssh'ing when the
> crash happened), I count 22 lines at the default window size, and 41
> when the window is maximized (window, in the "X window" sense).

The code that crashed redraws the entire frame, not a single window
(TTY redrawing always works like that).  So the size that matters is
the size of the entire frame, including the menu bar (if present), the
mode line, and the minibuffer window/echo area, not the maximum size
you can give to your buffer windows.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> > It seems like you connected with a second emacsclient in the middle of
>> > a potentially already confused session, which caused Emacs to be
>> > confused about the number of rows on your terminal. (Which one is
>> > true: 64 or 23?)
>> 
>> 63 is the exact number of lines I can put in a buffer when
>> gnome-terminal is maximized on the computer where emacs is running.
>> 
>> If I run gnome-terminal on my laptop (from which I was ssh'ing when the
>> crash happened), I count 22 lines at the default window size, and 41
>> when the window is maximized (window, in the "X window" sense).
>
> The code that crashed redraws the entire frame, not a single window
> (TTY redrawing always works like that).  So the size that matters is
> the size of the entire frame, including the menu bar (if present), the
> mode line, and the minibuffer window/echo area, not the maximum size
> you can give to your buffer windows.

Then you should add 2 to the numbers I gave (one for the modeline, one
for the echo area -- I don't display menus)

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
> Date: Fri, 02 May 2014 17:17:49 +0200
> 
> > The code that crashed redraws the entire frame, not a single window
> > (TTY redrawing always works like that).  So the size that matters is
> > the size of the entire frame, including the menu bar (if present), the
> > mode line, and the minibuffer window/echo area, not the maximum size
> > you can give to your buffer windows.
> 
> Then you should add 2 to the numbers I gave (one for the modeline, one
> for the echo area -- I don't display menus)

That'd be strange, since FrameRows returned 23, not 24.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Le 02/05/2014 17:42, Eli Zaretskii a écrit :
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
>> Date: Fri, 02 May 2014 17:17:49 +0200
>> 
>> > The code that crashed redraws the entire frame, not a single window
>> > (TTY redrawing always works like that).  So the size that matters is
>> > the size of the entire frame, including the menu bar (if present), the
>> > mode line, and the minibuffer window/echo area, not the maximum size
>> > you can give to your buffer windows.
>> 
>> Then you should add 2 to the numbers I gave (one for the modeline, one
>> for the echo area -- I don't display menus)
> 
> That'd be strange, since FrameRows returned 23, not 24.

Perhaps it was counting lines in the frame that lived in tmux-over-gdb
(tmux uses one line). Would that make sense ?

N.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> Date: Fri, 02 May 2014 18:00:23 +0200
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> CC: 17386@debbugs.gnu.org
> 
> Le 02/05/2014 17:42, Eli Zaretskii a écrit :
> >> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> >> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
> >> Date: Fri, 02 May 2014 17:17:49 +0200
> >> 
> >> > The code that crashed redraws the entire frame, not a single window
> >> > (TTY redrawing always works like that).  So the size that matters is
> >> > the size of the entire frame, including the menu bar (if present), the
> >> > mode line, and the minibuffer window/echo area, not the maximum size
> >> > you can give to your buffer windows.
> >> 
> >> Then you should add 2 to the numbers I gave (one for the modeline, one
> >> for the echo area -- I don't display menus)
> > 
> > That'd be strange, since FrameRows returned 23, not 24.
> 
> Perhaps it was counting lines in the frame that lived in tmux-over-gdb
> (tmux uses one line). Would that make sense ?

Sorry, I have no idea what tmux-over-gdb can do to that.  I'd be
surprised if it changed Emacs's idea of screen dimensions, though.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
>> Perhaps it was counting lines in the frame that lived in tmux-over-gdb
>> (tmux uses one line). Would that make sense ?
>
> Sorry, I have no idea what tmux-over-gdb can do to that.  I'd be
> surprised if it changed Emacs's idea of screen dimensions, though.

tmux shows some sort of status line, which means that the client
(emacs-in-gdb in my case) sees one line less.

I tried this experiment in a maximized gnome-terminal on my laptop:
$ gdb emacs
(gdb) r -nw -Q
hit: C-z
(gdb) p FrameRows(current_tty)
$1 = 43

now with tmux, still in a maximized gnome-terminal :
$ tmux # this will show a "status line" from tmux in gnome-terminal
$ gdb emacs
(gdb) r -nw -Q
hit: C-z
(gdb) p FrameRows(current_tty)
$1 = 42

So it does change the screen dimensions.

I tried splitting tmux (because of the related bug bug#16674) :
(gdb) p FrameRows(current_tty)
$4 = 20

(that's in the lower pane ; in the one above the answer is 21)

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
> Date: Sat, 03 May 2014 08:56:57 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> Perhaps it was counting lines in the frame that lived in tmux-over-gdb
> >> (tmux uses one line). Would that make sense ?
> >
> > Sorry, I have no idea what tmux-over-gdb can do to that.  I'd be
> > surprised if it changed Emacs's idea of screen dimensions, though.
> 
> tmux shows some sort of status line, which means that the client
> (emacs-in-gdb in my case) sees one line less.
> 
> I tried this experiment in a maximized gnome-terminal on my laptop:
> $ gdb emacs
> (gdb) r -nw -Q
> hit: C-z
> (gdb) p FrameRows(current_tty)
> $1 = 43
> 
> now with tmux, still in a maximized gnome-terminal :
> $ tmux # this will show a "status line" from tmux in gnome-terminal
> $ gdb emacs
> (gdb) r -nw -Q
> hit: C-z
> (gdb) p FrameRows(current_tty)
> $1 = 42
> 
> So it does change the screen dimensions.

OK, so evidently tmux reduces the screen dimensions _before_ Emacs
starts, in which case yes, the 1-off difference is probably due to
that factor, and shouldn't be causing any trouble.

So perhaps the problem is that Emacs takes the screen dimensions only
at startup and when it gets the SIGWINCH signal, and tmux somehow
makes these changes without sending SIGWINCH?

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> So perhaps the problem is that Emacs takes the screen dimensions only
> at startup and when it gets the SIGWINCH signal, and tmux somehow
> makes these changes without sending SIGWINCH?

The signal is generated by the kernel, upon the submit of the TIOCSWINSZ
ioctl, so it is impossible to change the size without generating the
signal.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17386@debbugs.gnu.org
> Date: Sat, 03 May 2014 10:21:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So perhaps the problem is that Emacs takes the screen dimensions only
> > at startup and when it gets the SIGWINCH signal, and tmux somehow
> > makes these changes without sending SIGWINCH?
> 
> The signal is generated by the kernel, upon the submit of the TIOCSWINSZ
> ioctl, so it is impossible to change the size without generating the
> signal.

Can we be sure that tmux reserves its line via that ioctl?

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Can we be sure that tmux reserves its line via that ioctl?

What do you mean with "reserves its line"?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: theonewiththeevillook@yahoo.fr,  17386@debbugs.gnu.org
> Date: Sat, 03 May 2014 10:56:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can we be sure that tmux reserves its line via that ioctl?
> 
> What do you mean with "reserves its line"?

What Nicolas reported (I know nothing about tmux, so cannot say this
better, sorry):

> tmux shows some sort of status line, which means that the client
> (emacs-in-gdb in my case) sees one line less.

and

> I tried splitting tmux (because of the related bug bug#16674) :
> (gdb) p FrameRows(current_tty)
> $4 = 20
> 
> (that's in the lower pane ; in the one above the answer is 21)

My understanding from this was that tmux reserves one screen line for
its status, and also that it can split a TTY into several portions,
each one emulating a separate terminal.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Le 03/05/2014 11:16, Eli Zaretskii a écrit :
> My understanding from this was that tmux reserves one screen line for
> its status, and also that it can split a TTY into several portions,
> each one emulating a separate terminal.

Yes.

Here's a picture of what tmux does :
http://tmux.sourceforge.net/tmux3.png

What I called "status line" is the last one. The different windows are
called 'panes' in tmux parlance.

Btw, I tried another experiment, using "cat", to see if SIGWINCH is sent~:

$ gdb cat
(gdb) handle SIGWINCH print
Signal        Stop	Print	Pass to program	Description
SIGWINCH      No	Yes	Yes		Window size changed
(gdb) r -
Starting program: /bin/cat -
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?

#### At this point I maximized then unmaximized the window.

Program received signal SIGWINCH, Window size changed.

Program received signal SIGWINCH, Window size changed.
[Inferior 1 (process 21202) exited normally]
(gdb) 

I tried the same with emacs but saw nothing:

$ gdb emacs 
(gdb) handle SIGWINCH print
Signal        Stop	Print	Pass to program	Description
SIGWINCH      No	Yes	Yes		Window size changed
(gdb) r -Q -nw
Starting program: /usr/local/bin/emacs -Q -nw
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb6386b40 (LWP 21216)]
[Thread 0xb673c880 (LWP 21212) exited]
[Inferior 1 (process 21212) exited normally]
(gdb) 

There's nothing to see on this transcript, but I did change the window
size after running "r -Q -nw", just like with "cat" above, before
exiting emacs. I don't know what this means.

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> Date: Mon, 05 May 2014 12:27:39 +0200
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> CC: 17386@debbugs.gnu.org
> 
> Btw, I tried another experiment, using "cat", to see if SIGWINCH is sent~:
> 
> $ gdb cat
> (gdb) handle SIGWINCH print
> Signal        Stop	Print	Pass to program	Description
> SIGWINCH      No	Yes	Yes		Window size changed
> (gdb) r -
> Starting program: /bin/cat -
> warning: Could not load shared library symbols for linux-gate.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> 
> #### At this point I maximized then unmaximized the window.
> 
> Program received signal SIGWINCH, Window size changed.
> 
> Program received signal SIGWINCH, Window size changed.
> [Inferior 1 (process 21202) exited normally]
> (gdb) 
> 
> I tried the same with emacs but saw nothing:
> 
> $ gdb emacs 
> (gdb) handle SIGWINCH print
> Signal        Stop	Print	Pass to program	Description
> SIGWINCH      No	Yes	Yes		Window size changed
> (gdb) r -Q -nw
> Starting program: /usr/local/bin/emacs -Q -nw
> warning: Could not load shared library symbols for linux-gate.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0xb6386b40 (LWP 21216)]
> [Thread 0xb673c880 (LWP 21212) exited]
> [Inferior 1 (process 21212) exited normally]
> (gdb) 
> 
> There's nothing to see on this transcript, but I did change the window
> size after running "r -Q -nw", just like with "cat" above, before
> exiting emacs. I don't know what this means.

I cannot reproduce this: I see GDB announcing SIGWINCH when Emacs runs
under tmux and the screen dimensions are changed.  I don't know what
you meant by "maximized then unmaximized the screen", but what I did
was to press 'C-b "' to split the screen in half, and then 'C-b !' to
join the halves into a single screen; both times GDB announced
SIGWINCH.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

>> $ gdb emacs 
>> (gdb) handle SIGWINCH print
>> Signal        Stop	Print	Pass to program	Description
>> SIGWINCH      No	Yes	Yes		Window size changed
>> (gdb) r -Q -nw
>> Starting program: /usr/local/bin/emacs -Q -nw
>> warning: Could not load shared library symbols for linux-gate.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/libthread_db.so.1".
>> [New Thread 0xb6386b40 (LWP 21216)]
>> [Thread 0xb673c880 (LWP 21212) exited]
>> [Inferior 1 (process 21212) exited normally]
>> (gdb) 
>> 
>> There's nothing to see on this transcript, but I did change the window
>> size after running "r -Q -nw", just like with "cat" above, before
>> exiting emacs. I don't know what this means.

> I don't know what you meant by "maximized then unmaximized the
> screen",

It was with gnome-terminal, maximizing and minimizing its frame. No
tmux involved.

> but what I did was to press 'C-b "' to split the screen in half, and
> then 'C-b !' to join the halves into a single screen; both times GDB
> announced SIGWINCH.

I just tried with "handle SIGWINCH stop print", and with that setup gdb
indeed takes control whenever I change the dimensions (either with tmux
or with gnome-terminal).

I don't know why I see nothing printed on the console in my previous
experiment, but it's probably just me not being able to use gdb.

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

It happened again (at least it looks very very similar to me) but I'm
afraid I'm not bringing much new information.

Anyway, just to show that it is the same problem :

(gdb) f 2
#2  0x0812f9b7 in cmcheckmagic (tty=0x897de50) at cm.c:120
120             emacs_abort ();
(gdb) l
115     cmcheckmagic (struct tty_display_info *tty)
116     {
117       if (curX (tty) == FrameCols (tty))
118         {
119           if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
120             emacs_abort ();
121           if (tty->termscript)
122             putc ('\r', tty->termscript);
123           putc ('\r', tty->output);
124           if (tty->termscript)
(gdb) p curY(tty)
$1 = 41
(gdb) p FrameRows(tty)
$2 = 23

The situation was as follows: I had a detached tmux session with an
"emacs -nw" in it (in gdb), and I had a graphical frame open also (via
emacsclient). I then tried to reattach to the tmux session, and that's
when emacs crashed.

I guess it would help to know what happens when tmux is detached.
Perhaps emacs should receive some kind of notification, and that doesn't
happen in some cases ? Next time I have to close emacs I'll try using
screen instead of tmux.

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Wed, 28 May 2014 10:35:39 +0200
> Cc: 17386@debbugs.gnu.org
> 
> It happened again (at least it looks very very similar to me) but I'm
> afraid I'm not bringing much new information.
> 
> Anyway, just to show that it is the same problem :
> 
> (gdb) f 2
> #2  0x0812f9b7 in cmcheckmagic (tty=0x897de50) at cm.c:120
> 120             emacs_abort ();
> (gdb) l
> 115     cmcheckmagic (struct tty_display_info *tty)
> 116     {
> 117       if (curX (tty) == FrameCols (tty))
> 118         {
> 119           if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
> 120             emacs_abort ();
> 121           if (tty->termscript)
> 122             putc ('\r', tty->termscript);
> 123           putc ('\r', tty->output);
> 124           if (tty->termscript)
> (gdb) p curY(tty)
> $1 = 41
> (gdb) p FrameRows(tty)
> $2 = 23
> 
> The situation was as follows: I had a detached tmux session with an
> "emacs -nw" in it (in gdb), and I had a graphical frame open also (via
> emacsclient). I then tried to reattach to the tmux session, and that's
> when emacs crashed.
> 
> I guess it would help to know what happens when tmux is detached.
> Perhaps emacs should receive some kind of notification, and that doesn't
> happen in some cases ? Next time I have to close emacs I'll try using
> screen instead of tmux.

What does it mean "detached tmux"?  How do you "attach" to a tmux
session, and what does that tell Emacs about the TTY that is being
attached?

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

Le 28/05/2014 16:17, Eli Zaretskii a écrit :
> What does it mean "detached tmux"?  How do you "attach" to a tmux
> session, and what does that tell Emacs about the TTY that is being
> attached?

Sorry about my fuzzy wording.

By detaching tmux, I mean hitting "C-b d" (with the default binding).
(In 'screen' that would be "C-a d".) The effect is that tmux is now
detached : you can hang up the connection to the terminal (e.g. close
terminal emulator, or stop ssh connection), it'll still run in the
background (with emacs in it).

Later you can reattach, by running "tmux attach" (in 'screen', this is
"screen -r"). This has the effect of bringing back tmux (with emacs
running inside it).

I don't know what information emacs (or whatever is running inside tmux)
receives when detaching or reattaching.

-- 
Nicolas.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Andreas Schwab]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> I don't know what information emacs (or whatever is running inside tmux)
> receives when detaching or reattaching.

Most likely nothing, since it is supposed to be transparent to the tmux
or screen instance.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  17386@debbugs.gnu.org
> Date: Wed, 28 May 2014 17:24:18 +0200
> 
> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> 
> > I don't know what information emacs (or whatever is running inside tmux)
> > receives when detaching or reattaching.
> 
> Most likely nothing, since it is supposed to be transparent to the tmux
> or screen instance.

How is Emacs supposed to get the screen dimension when tmux is
attached?  It looks like Emacs saw (or maybe fell back on) a 23-line
text terminal when it expected to see more than that (at least 42)
from the beginning of the session.

Nicolas, is the screen size supposed to be the same when you detach
and re-attach, and if so, what size do you expect it to be?

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> How is Emacs supposed to get the screen dimension when tmux is
> attached?

If the screen dimensions are changing, then tmux supposedly issues the
appropriate ioctl to the tty device, which causes a SIGWINCH signal to
be sent to the foreground process group.  But when detaching no such
action is needed.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

>> From: Andreas Schwab <schwab@suse.de>
>> Most likely nothing, since it is supposed to be transparent to the tmux
>> or screen instance.

fwiw, this was confirmed to me on IRC in #tmux.


Eli Zaretskii <eliz@gnu.org> writes:
> How is Emacs supposed to get the screen dimension when tmux is
> attached?  It looks like Emacs saw (or maybe fell back on) a 23-line
> text terminal when it expected to see more than that (at least 42)
> from the beginning of the session.
>
> Nicolas, is the screen size supposed to be the same when you detach
> and re-attach, and if so, what size do you expect it to be?

The size of my screen (read : the size of my gnome-terminal frame) can
be different when I detach and when I reattach (because I sometimes
maximize the frame, some other times not -- also because I use screen of
different sizes.)

On my laptop, over ssh:
- when I don't maximize my gnome-terminal frame, then gdb reports:
  FrameRows(current_tty) = 23.
- If the gnome-terminal frame is maximized, gdb reports 42.

(In case you wonder, I tried detaching when not-maximized, then
maximizing gnome-terminal and then reattaching : it worked fine.)

-- 
Nico.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Andreas Schwab <schwab@suse.de>,  theonewiththeevillook@yahoo.fr,  17386@debbugs.gnu.org
> Date: Wed, 28 May 2014 22:47:36 +0200
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Most likely nothing, since it is supposed to be transparent to the tmux
> >> or screen instance.
> 
> fwiw, this was confirmed to me on IRC in #tmux.
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > How is Emacs supposed to get the screen dimension when tmux is
> > attached?  It looks like Emacs saw (or maybe fell back on) a 23-line
> > text terminal when it expected to see more than that (at least 42)
> > from the beginning of the session.
> >
> > Nicolas, is the screen size supposed to be the same when you detach
> > and re-attach, and if so, what size do you expect it to be?
> 
> The size of my screen (read : the size of my gnome-terminal frame) can
> be different when I detach and when I reattach (because I sometimes
> maximize the frame, some other times not -- also because I use screen of
> different sizes.)
> 
> On my laptop, over ssh:
> - when I don't maximize my gnome-terminal frame, then gdb reports:
>   FrameRows(current_tty) = 23.
> - If the gnome-terminal frame is maximized, gdb reports 42.
> 
> (In case you wonder, I tried detaching when not-maximized, then
> maximizing gnome-terminal and then reattaching : it worked fine.)

So I guess tmux is not issuing the ioctl that Andreas mentioned, and
Emacs doesn't get SIGWINCH, and so doesn't know the screen dimensions
changed.

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Lars Ingebrigtsen]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Context : I was in an "emacsclient -t" over ssh session. I noticed emacs
> didn't respond (but I don't know if it was emacs or the ssh connection),
> so I started another ssh session, ran "emacsclient -t" again but only
> part of the emacs frame was drawn (maybe just the mode line, I'm not too
> sure I didn't pay much attention) -- I guess that's when it crashed
> because when I tried starting emacsclient again, nothing happened.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Do you still see this issue in recent Emacs versions?

(Skimming this bug report, it seems like the discussion seemed to change
to discuss SIGWINCH under tmux, which doesn't seem quite related to the
crash...)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/html, Size: 1460 bytes --]

bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Lars Ingebrigtsen]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Not at all. Seems it was fixed, thanks !

Thanks for checking.

> (I'm trying to close the bug, I hope I did it right.)

Yup; looks good.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no