bug#17386: 24.3.90; emacs_abort in cmcheckmagic

[Nicolas Richard]

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:

[Eli Zaretskii]

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.
[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?

[Nicolas Richard]

Post by Eli Zaretskii
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)

[Eli Zaretskii]

Date: Fri, 02 May 2014 10:14:18 +0200

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

(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?)

[Nicolas Richard]

Post by Eli Zaretskii

Date: Fri, 02 May 2014 10:14:18 +0200

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

(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.

Post by Eli Zaretskii
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).

[Eli Zaretskii]

Date: Fri, 02 May 2014 11:45:23 +0200

Post by Eli Zaretskii
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.

[Nicolas Richard]

Post by Eli Zaretskii

Post by Nicolas Richard

Post by Eli Zaretskii
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)

[Eli Zaretskii]

Date: Fri, 02 May 2014 17:17:49 +0200

Post by Eli Zaretskii
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.

[Nicolas Richard]

Post by Eli Zaretskii

Date: Fri, 02 May 2014 17:17:49 +0200

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Fri, 02 May 2014 18:00:23 +0200

Post by Eli Zaretskii

Date: Fri, 02 May 2014 17:17:49 +0200

Post by Eli Zaretskii
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.

[Nicolas Richard]

Post by Eli Zaretskii

Post by Nicolas Richard
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)

[Eli Zaretskii]

Date: Sat, 03 May 2014 08:56:57 +0200

Post by Eli Zaretskii

Post by Nicolas Richard
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.
$ gdb emacs
(gdb) r -nw -Q
hit: C-z
(gdb) p FrameRows(current_tty)
$1 = 43
$ 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?

[Andreas Schwab]

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Sat, 03 May 2014 10:21:22 +0200

Post by Eli Zaretskii
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?

[Andreas Schwab]

Post by Eli Zaretskii
Can we be sure that tmux reserves its line via that ioctl?

What do you mean with "reserves its line"?

Andreas.

[Eli Zaretskii]

Date: Sat, 03 May 2014 10:56:00 +0200

Post by Eli Zaretskii
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

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

and

(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.

[Nicolas Richard]

Post by Eli Zaretskii
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 :
Loading Image...

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.

[Eli Zaretskii]

Date: Mon, 05 May 2014 12:27:39 +0200
$ 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)
$ 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.

[Nicolas Richard]

Post by 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.

[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.

[Eli Zaretskii]

Date: Wed, 28 May 2014 10:35:39 +0200
It happened again (at least it looks very very similar to me) but I'm
afraid I'm not bringing much new information.
(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?

[Nicolas Richard]

Post by Eli Zaretskii
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.

[Andreas Schwab]

Post by Nicolas Richard
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.

[Eli Zaretskii]

Date: Wed, 28 May 2014 17:24:18 +0200

Post by Nicolas Richard
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?

[Andreas Schwab]

Post by Eli Zaretskii
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.

[Nicolas Richard]

Post by Eli Zaretskii

Post by Andreas Schwab
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.

Post by Eli Zaretskii
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.)

[Eli Zaretskii]

Date: Wed, 28 May 2014 22:47:36 +0200

Post by Eli Zaretskii

Post by Andreas Schwab
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.

Post by Eli Zaretskii
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.)
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.