[email protected]
[Top] [All Lists]

Bug#317632: marked as forwarded (putty: Putty and Pterm work okay, but s

Subject: Bug#317632: marked as forwarded putty: Putty and Pterm work okay, but start exceptionally slow
From: Debian Bug Tracking System
Date: Sat, 15 Apr 2006 03:03:14 -0700
Your message dated Sat, 15 Apr 2006 11:49:57 +0100
with message-id <[email protected]>
has caused the Debian Bug report #317632,
regarding putty: Putty and Pterm work okay, but start exceptionally slow
to be marked as having been forwarded to the upstream software
author(s) [email protected]

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Subject: : Bug#336390: pterm: on 64 bit machines, on startup, doesn't display text until mouse event or focus loss]
From: Colin Watson
Date: Sat, 15 Apr 2006 11:49:57 +0100
Peter's patch works well for me; I'm going to apply it to the Debian
package because the problem annoys me on my amd64 system. I agree with
Peter's assessment that it isn't perfectly portable, though.

(Sorry for the delay in forwarding this.)


Colin Watson                                       [[email protected]]

----- Forwarded message from [email protected] -----

Subject: Bug#336390: pterm: on 64 bit machines, on startup, doesn't display 
text until mouse event or focus loss
Reply-To: [email protected], [email protected]
Original-Sender: Peter Maydell <[email protected]>
X-Debian-PR-Message: report 336390
X-Debian-PR-Package: pterm
To: [email protected]
From: [email protected]
Date: Sun, 30 Oct 2005 00:33:50 +0100
Delivered-To: [email protected]
Delivered-To: [email protected]
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on 
X-Spam-Status: No, score=0.0 required=4.5 tests=BAYES_50,NO_REAL_NAME 
        autolearn=no version=3.0.3

Package: pterm
Version: 0.58-1

I start pterm. It brings up its window, which is cleared to black
with the cursor in the top left corner. After this, nothing happens: the
expected shell prompt isn't printed. Pressing keys has no visible effect.
When I click the mouse on the window or use the window manager to switch
away this causes pterm to suddenly update, printing the shell prompt plus
any characters corresponding to keys I had pressed earlier (and if say
I had pressed 'ls<RET>' I also get the ls output now).

I only see this on Alpha. I'm using the ratpoison window manager, which
is prone to showing up bugs in applications because it tends to map them
and give them the first Expose event very early.

Interesting things:
If I put a sleep(5) just before the call to gtk_main() at the bottom of
gtkwin.c then the problem goes away: pterm sleeps for five seconds and
then displays the prompt fine.
If I put a call to term_invalidate(inst->term) just before gtk_main()
this also causes the problem to disappear.

---begin true but irrelevant stuff---

I thought that the the problem was that the gtkwin front end quietly
drops any drawing events that occur before we've managed to map the
window, but this doesn't seem to be what's actually happening when
I insert debugging printf()s. Still, maybe the code should be changed?

get_ctx() just returns NULL if inst->area->window is NULL, in which
case the code in terminal.c will do no redrawing (but will clear
its internal flag to say no update is required). This is decidedly
unfortunate because the gtkwin's Expose event handler does a blit
of its internal pixmap onto the window: and the pixmap is blank
because we never drew onto it. (Note the completely bogus comment
in expose_area(), incidentally.) 
Probably the correct approach is to have get_ctx return NULL only
if inst->pixmap is NULL. The code in do_text and do_cursor which
copies from inst->pixmap to inst->window will have to be conditional
on inst->window not being NULL. Dropping drawing events before
inst->pixmap is created will be fine because in configure_area()
where we create the pixmap we subsequently do a term_invalidate().

I also notice that we call gdk_draw_pixmap() for what looks like
a whole screen blit after every call to do_text() or do_cursor().
Wouldn't it be better to just do that once in free_ctx()?


Actual problem:
The gtkwin.c timer code implicitly assumes sizeof(int)==sizeof(long).
On alpha, long is 64 bit, so timer ticks as returned by GETTICKCOUNT()
are 64 bits (and at time of writing well overflowing into the high
word). However, we pass this through to the timer_trigger() routine
with GINT_TO_POINTER() and then retrieve it with GPOINTER_TO_INT().
Unfortunately on alpha GPOINTER_TO_INT(x) is defined as
((gint)  (glong) (x)), which truncates the count to 32 bits.
The upshot is that the next timeout is scheduled for aeons in the
future, and we never actually draw anything.


--- gtkwin.c.orig       2005-10-29 22:58:37.000000000 +0100
+++ gtkwin.c    2005-10-30 00:22:57.000000000 +0100
@@ -1187,14 +1187,14 @@
 static gint timer_trigger(gpointer data)
-    long now = GPOINTER_TO_INT(data);
+    long now = (long)(data);
     long next;
     long ticks;
     if (run_timers(now, &next)) {
        ticks = next - GETTICKCOUNT();
        timer_id = gtk_timeout_add(ticks > 0 ? ticks : 1, timer_trigger,
-                                  GINT_TO_POINTER(next));
+                                  (gpointer)(next));
@@ -1216,7 +1216,7 @@
        ticks = 1;                     /* just in case */
     timer_id = gtk_timeout_add(ticks, timer_trigger,
-                              GINT_TO_POINTER(next));
+                              (gpointer)(next));
 void fd_input_func(gpointer data, gint sourcefd, GdkInputCondition condition)

Disclaimer: works for me on the Alpha, but totally untested on
32 bit machines. Almost certainly won't work on systems where
pointers are 32 bit but long is 64 bit.

I think that we only ever have one outstanding timer (since
timer_id is a single global, not an array), so we could just
keep 'next' in a global, rather than trying to stuff it into
a pointer and pull it back out again; maybe that'd be cleaner?

Or we could force timer ticks to be 32 bit integers on all

-- PMM

----- End forwarded message -----

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#317632: marked as forwarded (putty: Putty and Pterm work okay, but start exceptionally slow), Debian Bug Tracking System <=