9:38 p.m.
Hi all --
This is a bit of a weird one... when using XEmacs 21.5 inside
screen(1), and using multiple frames, XEmacs sometimes goes bonkers
when I resize the terminal window.
I've got a set of steps to reproduce the problem, using:
- RedHat Linux (tried EL3 and FC5)
- XEmacs 21.5.27
- screen 4.00.02
- Any type of terminal (PuTTY, xterm, etc.)
Here are the steps:
1. Open an 80x24 terminal window, and start screen.
2. Inside screen, start xemacs, and use C-x 5 2 to create a new
frame. Type "Hello".
3. Resize the terminal to something larger than 80x24. You should
notice that XEmacs APPEARS to handle the resize correctly -- your
"Hello" is in the top-left corner, and the modeline moves to the
bottom and spans the full width of the terminal.
4. Now try typing. Does everything work normally?
When I do this, XEmacs seems to behave as if it's inside a terminal
that's only 2 characters wide x 3 characters tall, positioned in the
top-left corner of the real terminal. If I press M-<, what I actually
see is:
H$ <-- truncated "Hello"
-- <-- the modeline
M\ <-- truncated "Mark set" from M-<
Recovering from this is very tricky. It's not enough to put the
terminal back to its previous size; I need to actually delete the
frame (C-x 5 0), and sometimes still adjust the size of the terminal
for it to really recover.
Using 21.4, everything seems to work correctly. And with no frames,
there's no problem. Anybody know what might be going on here? Any
suggestions for how I might track this down?
Thanks!
--
Ron Isaacson
Morgan Stanley
ron.isaacson(a)morganstanley.com / (212) 276-1144
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:41 p.m.
Ron Isaacson writes:
This is a bit of a weird one... when using XEmacs 21.5 inside
screen(1), and using multiple frames, XEmacs sometimes goes bonkers
when I resize the terminal window.
Replicated in a Mac OS X Terminal over ssh with 21.5.28.
I did manage to get the values of (frame-height) and (frame-width),
and they are in fact 2 and 3 respectively. Evidently something is
going wrong with communication of the terminal dimensions.
I don't know what's going on, but I did manage to replicate as
follows:
1. start "xemacs -vanilla &" as an X application
2. in the X frame, M-x gnuserv-start RET
3. in the Terminal window, "screen", then "gnuclient junk" in screen
4. C-x 5 2
5. Type "Hello"
6. Resize the Terminal window
7. Type something
and observe the anomoly. Having the X frame should help reduce the
annoyance of querying XEmacs for what it thinks is going on, at least.
If you are going to be trying to debug this, note that there has been
active work on frame dimensioning since 21.5.27. The bug is still
there, but probably you should be using CVS XEmacs to work on this.
Mike, any thoughts?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:37 a.m.
Stephen J. Turnbull wrote:
Ron Isaacson writes:
> This is a bit of a weird one... when using XEmacs 21.5 inside
> screen(1), and using multiple frames, XEmacs sometimes goes bonkers
> when I resize the terminal window.
Replicated in a Mac OS X Terminal over ssh with 21.5.28.
I did manage to get the values of (frame-height) and (frame-width),
and they are in fact 2 and 3 respectively. Evidently something is
going wrong with communication of the terminal dimensions.
Ok, I was able to reproduce this under gdb. I tracked down where the
problem happens, although I don't really understand why. See
end_hold_frame_size_changes in redisplay.c, which says:
if (f->size_change_pending)
change_frame_size (f, f->new_height, f->new_width, 0);
So when it exits a period when no frame size changes were allowed, it
checks to see if there's one queued, and executes it if so. Sounds
reasonable enough, except that I've got this stack trace:
#0 change_frame_size (f=0x968a758, newheight=0, newwidth=0, delay=0)
at frame.c:3433
#1 0x0818b577 in end_hold_frame_size_changes (unused_obj=136941128)
at redisplay.c:6725
#2 0x080ccc81 in unbind_to_hairy (count=3) at eval.c:6113
#3 0x080ccbc5 in unbind_to_1 (count=3, value=136941128) at eval.c:6065
#4 0x0818b6ce in exit_redisplay_critical_section (depth=3) at redisplay.c:6784
#5 0x0818bc55 in redisplay_frame (f=0x96c8a68, preemption_check=1)
at redisplay.c:6975
#6 0x0818bf0a in redisplay_device (d=0x967a290, automatic=1)
at redisplay.c:7028
#7 0x0818c512 in redisplay_without_hooks () at redisplay.c:7103
#8 0x0818c7bb in redisplay_no_pre_idle_hook () at redisplay.c:7174
#9 0x0818c76f in redisplay () at redisplay.c:7156
#10 0x080d9381 in Fnext_event (event=157446364, prompt=136941128)
at event-stream.c:2288
Note that newheight and newwidth in the call to change_frame_size are
both 0. Here's how I got there:
After a resize, I see TWO calls to change_frame_size with the correct
dimensions, while delay == 1. Each of these sets the f->new_*
variables, along with size_change_pending, then returns. Then there's
a THIRD call, again with correct dimensions, when delay == 0; that
sets size_change_pending to 0 and then we go through a full redisplay.
redisplay_frame does:
depth = enter_redisplay_critical_section ();
and gets back a depth of 3. It proceeds all the way through the
CRITICAL REDISPLAY SECTION, then when it's done, calls:
exit_redisplay_critical_section (depth);
Now, I confirmed that just before that call, f->size_change_pending is
still 0. However, when exit_redisplay_critical_section does its
unbind_to business, specpdl_depth_counter starts at 13; by the time it
walks down to 3, f->size_change_pending has been reset to 1, but the
two f->new_* variables are still 0. This is what leads to the stack
trace shown above. The 2x3 dimensions are imposed by check_frame_size,
which won't let you create a 0x0 frame.
That's about as far as I've been able to get. The problem seems to be
introduced somewhere in the unwind chain created by
begin_redisplay_critical_section, but there's some serious black magic
in there.
Any suggestions on where to go from here?
--
Ron Isaacson
Morgan Stanley
ron.isaacson(a)morganstanley.com / (212) 276-1144
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:10 p.m.
Hi, Ron,
I’ve been seeing this for the last few years too, together with occasional
blocks on redisplay that take far too long to time out. As I understand it,
screen(1) plays games with various socket options, which causes the latter,
and may intercept SIGWINCH and the rest of the infrastructure for signalling
to an app that its terminal has been changed.
But, as you mention, 21.4 doesn’t have a problem, so we did something in the
course of 21.5 to provoke this. A binary search through the 21.5 releases
would narrow it down considerably, and with a bit of work with CVS it should
be possible to isolate the actual commit.
Bye,
Aidan
Ar an seachtú lá is fiche de mí na Samhain, scríobh Ron Isaacson:
Hi all --
This is a bit of a weird one... when using XEmacs 21.5 inside
screen(1), and using multiple frames, XEmacs sometimes goes bonkers
when I resize the terminal window.
I've got a set of steps to reproduce the problem, using:
- RedHat Linux (tried EL3 and FC5)
- XEmacs 21.5.27
- screen 4.00.02
- Any type of terminal (PuTTY, xterm, etc.)
Here are the steps:
1. Open an 80x24 terminal window, and start screen.
2. Inside screen, start xemacs, and use C-x 5 2 to create a new
frame. Type "Hello".
3. Resize the terminal to something larger than 80x24. You should
notice that XEmacs APPEARS to handle the resize correctly -- your
"Hello" is in the top-left corner, and the modeline moves to the
bottom and spans the full width of the terminal.
4. Now try typing. Does everything work normally?
When I do this, XEmacs seems to behave as if it's inside a terminal
that's only 2 characters wide x 3 characters tall, positioned in the
top-left corner of the real terminal. If I press M-<, what I actually
see is:
H$ <-- truncated "Hello"
-- <-- the modeline
M\ <-- truncated "Mark set" from M-<
Recovering from this is very tricky. It's not enough to put the
terminal back to its previous size; I need to actually delete the
frame (C-x 5 0), and sometimes still adjust the size of the terminal
for it to really recover.
Using 21.4, everything seems to work correctly. And with no frames,
there's no problem. Anybody know what might be going on here? Any
suggestions for how I might track this down?
Thanks!
--
Ron Isaacson
Morgan Stanley
ron.isaacson(a)morganstanley.com / (212) 276-1144
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6182
days inactive
6188
days old
3 comments
3 participants
participants (3)
-
Aidan Kehoe -
Ron Isaacson -
Stephen J. Turnbull