don't bother with this, there is a better one coming soon
On Thu, Jul 22, 2010 at 11:15:09PM +0100, Nicholas Marriott wrote:
> Anyone seeing this or not seeing it please try this and let me know of
> any strangeness
>
>
> Index: server-client.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/tmux/server-client.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 server-client.c
> --- server-client.c 19 Jul 2010 18:27:38 -0000 1.35
> +++ server-client.c 22 Jul 2010 22:14:06 -0000
> @@ -29,6 +29,7 @@
>
> void server_client_handle_key(int, struct mouse_event *, void *);
> void server_client_repeat_timer(int, short, void *);
> +void server_client_check_backoff(struct client *);
> void server_client_check_redraw(struct client *);
> void server_client_set_title(struct client *);
> void server_client_reset_state(struct client *);
> @@ -393,6 +394,7 @@ server_client_loop(void)
> if (c == NULL || c->session == NULL)
> continue;
>
> + server_client_check_backoff(c);
> server_client_check_redraw(c);
> server_client_reset_state(c);
> }
> @@ -455,6 +457,18 @@ server_client_repeat_timer(unused int fd
>
> if (c->flags & CLIENT_REPEAT)
> c->flags &= ~(CLIENT_PREFIX|CLIENT_REPEAT);
> +}
> +
> +/* Check client backoff. */
> +void
> +server_client_check_backoff(struct client *c)
> +{
> + struct tty *tty = &c->tty;
> +
> + if (tty_backoff(tty)) {
> + tty_invalidate(tty);
> + server_redraw_client(c);
> + }
> }
>
> /* Check for client redraws. */
> Index: server-window.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/tmux/server-window.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 server-window.c
> --- server-window.c 19 Jul 2010 21:13:03 -0000 1.16
> +++ server-window.c 22 Jul 2010 22:14:06 -0000
> @@ -29,31 +29,6 @@ int server_window_check_activity(struct
> int server_window_check_content(
> struct session *, struct winlink *, struct window_pane *);
>
> -/* Check if this window should suspend reading. */
> -int
> -server_window_backoff(struct window_pane *wp)
> -{
> - struct client *c;
> - u_int i;
> -
> - if (!window_pane_visible(wp))
> - return (0);
> -
> - for (i = 0; i < ARRAY_LENGTH(&clients); i++) {
> - c = ARRAY_ITEM(&clients, i);
> - if (c == NULL || c->session == NULL)
> - continue;
> - if ((c->flags & (CLIENT_SUSPENDED|CLIENT_DEAD)) != 0)
> - continue;
> - if (c->session->curw->window != wp->window)
> - continue;
> -
> - if (EVBUFFER_LENGTH(c->tty.event->output) > BACKOFF_THRESHOLD)
> - return (1);
> - }
> - return (0);
> -}
> -
> /* Window functions that need to happen every loop. */
> void
> server_window_loop(void)
> @@ -68,17 +43,6 @@ server_window_loop(void)
> w = ARRAY_ITEM(&windows, i);
> if (w == NULL)
> continue;
> -
> - TAILQ_FOREACH(wp, &w->panes, entry) {
> - if (wp->fd == -1)
> - continue;
> - if (!(wp->flags & PANE_FREEZE)) {
> - if (server_window_backoff(wp))
> - bufferevent_disable(wp->event, EV_READ);
> - else
> - bufferevent_enable(wp->event, EV_READ);
> - }
> - }
>
> for (j = 0; j < ARRAY_LENGTH(&sessions); j++) {
> s = ARRAY_ITEM(&sessions, j);
> Index: tmux.h
> ===================================================================
> RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
> retrieving revision 1.235
> diff -u -p -r1.235 tmux.h
> --- tmux.h 14 Jul 2010 18:37:49 -0000 1.235
> +++ tmux.h 22 Jul 2010 22:14:08 -0000
> @@ -59,8 +59,8 @@ extern char **environ;
> /* Automatic name refresh interval, in milliseconds. */
> #define NAME_INTERVAL 500
>
> -/* Maximum data to buffer for output before suspending reading from panes. */
> -#define BACKOFF_THRESHOLD 1024
> +/* Maximum data to buffer for output before suspending writing to a tty. */
> +#define BACKOFF_THRESHOLD 8192
>
> /*
> * Maximum sizes of strings in message data. Don't forget to bump
> @@ -1017,6 +1017,7 @@ struct tty {
> #define TTY_UTF8 0x8
> #define TTY_STARTED 0x10
> #define TTY_OPENED 0x20
> +#define TTY_BACKOFF 0x40
> int flags;
>
> int term_flags;
> @@ -1376,6 +1377,7 @@ void tty_putc(struct tty *, u_char);
> void tty_pututf8(struct tty *, const struct grid_utf8 *);
> void tty_init(struct tty *, int, char *);
> int tty_resize(struct tty *);
> +void tty_invalidate(struct tty *);
> void tty_start_tty(struct tty *);
> void tty_stop_tty(struct tty *);
> void tty_set_title(struct tty *, const char *);
> @@ -1384,6 +1386,7 @@ void tty_draw_line(struct tty *, struct
> int tty_open(struct tty *, const char *, char **);
> void tty_close(struct tty *);
> void tty_free(struct tty *);
> +int tty_backoff(struct tty *);
> void tty_write(void (*)(
> struct tty *, const struct tty_ctx *), const struct tty_ctx *);
> void tty_cmd_alignmenttest(struct tty *, const struct tty_ctx *);
> Index: tty.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/tmux/tty.c,v
> retrieving revision 1.88
> diff -u -p -r1.88 tty.c
> --- tty.c 5 Jun 2010 16:47:11 -0000 1.88
> +++ tty.c 22 Jul 2010 22:14:08 -0000
> @@ -95,6 +95,15 @@ tty_resize(struct tty *tty)
> tty->sx = sx;
> tty->sy = sy;
>
> + tty_invalidate(tty);
> +
> + return (1);
> +}
> +
> +/* Invalidate any cached position data. */
> +void
> +tty_invalidate(struct tty *tty)
> +{
> tty->cx = UINT_MAX;
> tty->cy = UINT_MAX;
>
> @@ -109,8 +118,6 @@ tty_resize(struct tty *tty)
> tty_cursor(tty, 0, 0);
> tty_region(tty, 0, tty->sy - 1);
> }
> -
> - return (1);
> }
>
> int
> @@ -208,11 +215,7 @@ tty_start_tty(struct tty *tty)
> if (tty_term_has(tty->term, TTYC_KMOUS))
> tty_puts(tty, "\033[?1000l");
>
> - tty->cx = UINT_MAX;
> - tty->cy = UINT_MAX;
> -
> - tty->rlower = UINT_MAX;
> - tty->rupper = UINT_MAX;
> + tty_invalidate(tty);
>
> tty->mode = MODE_CURSOR;
>
> @@ -257,6 +260,28 @@ tty_stop_tty(struct tty *tty)
> fcntl(tty->fd, F_SETFL, mode & ~O_NONBLOCK);
> }
>
> +/*
> + * Check if the backoff state has changed on this tty. Returns 1 if the tty
> has
> + * changed state so it is no longer restricted. Backoff is only enforced when
> + * going through tty_write (updates from the windows), internal redraw goes
> + * directly to the output buffer.
> + */
> +int
> +tty_backoff(struct tty *tty)
> +{
> + if (tty->flags & TTY_BACKOFF) {
> + if (EVBUFFER_LENGTH(tty->event->output) != 0)
> + return (0);
> + tty->flags &= ~TTY_BACKOFF;
> + return (1);
> + } else {
> + if (EVBUFFER_LENGTH(tty->event->output) <= BACKOFF_THRESHOLD)
> + return (0);
> + tty->flags |= TTY_BACKOFF;
> + return (0);
> + }
> +}
> +
> void
> tty_fill_acs(struct tty *tty)
> {
> @@ -578,7 +603,9 @@ tty_write(void (*cmdfn)(
> continue;
>
> if (c->session->curw->window == wp->window) {
> - if (c->tty.flags & TTY_FREEZE || c->tty.term == NULL)
> + if (c->tty.term == NULL)
> + continue;
> + if (c->tty.flags & (TTY_FREEZE|TTY_BACKOFF))
> continue;
> cmdfn(&c->tty, ctx);
> }
>
>
>
> On Thu, Jul 22, 2010 at 09:20:13AM +0100, Nicholas Marriott wrote:
> > yes, this is a known problem when a stale client is left behind, it used
> > to happen because we did not pick up HUP, but we do now
> >
> > micahcowan and i started discussing this as a potential problem with ssh
> > before, because ssh will not know to disconnect the client (tcp will not
> > tell it), so tmux will never know either, but we were both called away
> > and didn't finish the conversation
> >
> > probably what is happening is that ssh or the pty buffers fill and it is
> > no longer reading from the pty so it hits the backoff limit and reading
> > from any windows shown on that client is suspended
> >
> > maybe we are doing backoff the wrong way. maybe a better way would be to
> > suspend /writing/ to the client until the buffer drains, then flush the
> > pending data and force a redraw. this might be harder to achieve though
> >
> >
> > On Wed, Jul 21, 2010 at 09:54:53PM -0400, Samer Atiani wrote:
> > > The problem has happened to me again, but I was able to fix it after it
> > > occured.
> > > I typed "C-b : lsc" *and it returned this:
> > > /dev/pts/4: 0 [208x62 xterm] * * * * * * * * * * * * * * * * * * * * *
> > > * *
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > > * *
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * [0/2]
> > > /dev/pts/5: 0 [208x62 xterm]
> > > so I detached and from the terminal I typed:
> > > tmux detach -t /dev/pts/4
> > > so that the result of the statement "tmux list-clients" is nothing.
> > > Then I
> > > attached again with tmux attach and all was fixed.
> > > Now onto finding what was using /dev/pts/4:
> > > $ ls -al | grep ssh
> > > ... [output redacted]
> > > 5 S satiani * 1943 *1874 *0 *80 * 0 - 19735 poll_s 15:03 ? * * *
> > > *00:00:00
> > > sshd: sati...@pts/4
> > > ...*[output redacted]
> > > 5 S satiani *26350 26286 *0 *80 * 0 - 19735 poll_s 21:35 ? * * *
> > > *00:00:00
> > > sshd: sati...@pts/5
> > > ...*[output redacted]
> > > So it looks like there is a stale ssh connection to the machine
> > > (process
> > > 1943) that was never closed properly after my connection died. Since I
> > > was
> > > still attached to tmux at the time my connection died I think thats
> > > what
> > > caused it. Indeed, I was able to reproduce the problem:
> > > Reproduction steps:
> > > On Windows XP:
> > > 1- Open a VPN connection to the network hosting the target machine.
> > > 2- PuTTY to the machine, open a new tmux session.
> > > 3- Without closing PuTTY or tmux, disconnect the VPN connection.
> > > 4- Reopen the VPN and reconnect to the machine, check your ssh
> > > connection
> > > processes and confirm that there is a stale connection from your
> > > interrupted session.
> > > 5- Attach tmux. At first it appears you can type a few keystrokes, but
> > > eventually the windows will freeze. You should still be able to use
> > > tmux
> > > keybindings to execute tmux commands but the windows themselves won't
> > > respond to your keystrokes unless you switch to another window and then
> > > back to the original window.
> > > I can reliably reproduce this problem using the steps outlined above.
> > > You
> > > can fix the problem either by issuing a tmux detach on the pts of the
> > > stale connection or from outside tmux by killing the stale connection.
> > > Samer
> > > On Wed, Jul 21, 2010 at 3:59 PM, Richard Morse
> > > <[1]remo...@partners.org>
> > > wrote:
> > >
> > > This is tmux running locally.
> > >
> > > Ricky
> > > On Jul 21, 2010, at 3:58 PM, Nicholas Marriott wrote:
> > >
> > > > over ssh or running natively?
> > > >
> > > > sounds like problems with SIGWINCH or TIOCGWINSZ
> > > >
> > > >
> > > > On Wed, Jul 21, 2010 at 03:55:35PM -0400, Richard Morse wrote:
> > > >> Is it related to changing the terminal size (ie, the PuTTY window
> > > size) too quickly? I've just discovered that quickly changing the
> > > size
> > > of the Terminal.app window can sometimes cause tmux to stop updating
> > > the
> > > screen until the window is sized back to the size it had been...
> > > >>
> > > >> Ricky
> > > >>
> > > >> On Jul 21, 2010, at 3:17 PM, Samer Atiani wrote:
> > > >>
> > > >>> Yes, its 1.4.14b , sorry.
> > > >>>
> > > >>> As I said I can't reproduce it, so I don't know exactly the
> > > sequence
> > > of
> > > >>> events that leads to this behavior, nor do I have this problem
> > > happening to
> > > >>> me now so I can answer your other questions.
> > > >>>
> > > >>> However, I'll keep you posted the next time it happens.
> > > >>>
> > > >>> Many thanks for your help,
> > > >>> Samer
> > > >>>
> > > >>> On Wed, Jul 21, 2010 at 3:13 PM, Nicholas Marriott <
> > > >>> [2]nicholas.marri...@gmail.com> wrote:
> > > >>>
> > > >>>> I take it that is 1.4.14b libevent.
> > > >>>>
> > > >>>> So are you doing anything particular when it happens? Running
> > > any
> > > >>>> particular program?
> > > >>>>
> > > >>>> After it freezes, can you still detach tmux? What does "C-b :
> > > lsc"
> > > say
> > > >>>> after it happens? Does C-b r fix it?
> > > >>>>
> > > >>>>
> > > >>>> On Wed, Jul 21, 2010 at 03:10:49PM -0400, Samer Atiani wrote:
> > > >>>>> *libevent version: 1.4.1b-stable
> > > >>>>> *tmux version: 1.2
> > > >>>>> *platform: ubuntu 9.10, debian squeeze
> > > >>>>> *TERM inside tmux: screen
> > > >>>>> *TERM outside tmux: xterm
> > > >>>>>
> > > >>>>> *On Wed, Jul 21, 2010 at 2:59 PM, Nicholas Marriott
> > > >>>>> *<[1][3]nicholas.marri...@gmail.com> wrote:
> > > >>>>>
> > > >>>>> * *What tmux version, what platform is it running on, what is
> > > TERM
> > > set
> > > >>>> to
> > > >>>>> * *inside and outside tmux, what version of libevent?
> > > >>>>>
> > > >>>>> * *On Wed, Jul 21, 2010 at 02:46:26PM -0400, Samer Atiani
> > > wrote:
> > > >>>>>> * *Hello,
> > > >>>>>> * *I'm having a weird problem were tmux windows stop reacting
> > > to
> > > >>>> my
> > > >>>>>> * *keystrokes interactively, this problem only happens to me
> > > in
> > > >>>> PuTTY.
> > > >>>>>> * *When the problem happens, tmux bindings still work (I can
> > > >>>> switch
> > > >>>>> * *between
> > > >>>>>> * *windows, go into command/copy mode, etc.), however, when I
> > > type
> > > >>>>> * *something
> > > >>>>>> * *into the window the terminal doesn't respond to my
> > > keystrokes.
> > > >>>>> * *Whats
> > > >>>>>> * *interesting is that if I switch to another window and then
> > > back
> > > >>>>> * *into the
> > > >>>>>> * *original window, *whatever I originally typed before
> > > switching
> > > >>>> will
> > > >>>>> * *be
> > > >>>>>> * *visible now.
> > > >>>>>> * *I do not know how to reproduce this problem, so far it
> > > happens
> > > >>>>>> * *sporadically (it has happened to me twice today so far).
> > > >>>>>> * *Can you please help me with resolving this problem?
> > > >>>>>> * *Samer
> > > >>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > >
> > > ------------------------------------------------------------------------------
> > > >>>>>> This SF.net email is sponsored by Sprint
> > > >>>>>> What will you do first with EVO, the first 4G phone?
> > > >>>>>> Visit [2][4]sprint.com/first -- [3]
> > > >>>> [5]http://p.sf.net/sfu/sprint-com-first
> > > >>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> tmux-users mailing list
> > > >>>>>> [4][6]tmux-us...@lists.sourceforge.net
> > > >>>>>> [5][7]https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > >>>>>
> > > >>>>> References
> > > >>>>>
> > > >>>>> *Visible links
> > > >>>>> *1. mailto:[8]nicholas.marri...@gmail.com
> > > >>>>> *2. [9]http://sprint.com/first
> > > >>>>> *3. [10]http://p.sf.net/sfu/sprint-com-first
> > > >>>>> *4. mailto:[11]tmux-us...@lists.sourceforge.net
> > > >>>>> *5. [12]https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > >>>>
> > > >>>
> > >
> > > ------------------------------------------------------------------------------
> > > >>> This SF.net email is sponsored by Sprint
> > > >>> What will you do first with EVO, the first 4G phone?
> > > >>> Visit [13]sprint.com/first --
> > >
> > > [14]http://p.sf.net/sfu/sprint-com-first_______________________________________________
> > > >>> tmux-users mailing list
> > > >>> [15]tmux-us...@lists.sourceforge.net
> > > >>> [16]https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > >>
> > > >>
> > > >>
> > > >> The information in this e-mail is intended only for the person to
> > > whom it is
> > > >> addressed. If you believe this e-mail was sent to you in error and
> > > the e-mail
> > > >> contains patient information, please contact the Partners
> > > Compliance
> > > HelpLine at
> > > >> [17]http://www.partners.org/complianceline . If the e-mail was
> > > sent
> > > to you in error
> > > >> but does not contain patient information, please contact the
> > > sender
> > > and properly
> > > >> dispose of the e-mail.
> > > >>
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:remo...@partners.org
> > > 2. mailto:nicholas.marri...@gmail.com
> > > 3. mailto:nicholas.marri...@gmail.com
> > > 4. http://sprint.com/first
> > > 5. http://p.sf.net/sfu/sprint-com-first
> > > 6. mailto:tmux-users@lists.sourceforge.net
> > > 7. https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > 8. mailto:nicholas.marri...@gmail.com
> > > 9. http://sprint.com/first
> > > 10. http://p.sf.net/sfu/sprint-com-first
> > > 11. mailto:tmux-users@lists.sourceforge.net
> > > 12. https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > 13. http://sprint.com/first
> > > 14.
> > > http://p.sf.net/sfu/sprint-com-first_______________________________________________
> > > 15. mailto:tmux-users@lists.sourceforge.net
> > > 16. https://lists.sourceforge.net/lists/listinfo/tmux-users
> > > 17. http://www.partners.org/complianceline
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > tmux-users mailing list
> > tmux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/tmux-users
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
