Debian Bug report logs - #112770
ratpoison: C-t a kills ratpoison

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bruce McIntyre <bmcintyre@primus.com.au>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ratpoison: C-t a kills ratpoison

Date: Wed, 19 Sep 2001 23:31:30 +1000

Package: ratpoison
Version: 1.0.0-1
Severity: normal

C-t a, instead of invoking the clock, quits ratpoison (and, of course, X)
unexpectedly.

-- System Information
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux plato 2.2.19 #1 Wed Aug 15 20:45:27 EST 2001 ppc
Locale: LANG=en_AU, LC_CTYPE=en_AU

Versions of packages ratpoison depends on:
ii  libc6                         2.2.4-1    GNU C Library: Shared libraries an
ii  xlibs                         4.1.0-6    X Window System client libraries

Message #10 received at 112770@bugs.debian.org (full text, mbox, reply):

From: Gergely Nagy <algernon@debian.org>

To: Bruce McIntyre <bmcintyre@primus.com.au>, 112770@bugs.debian.org

Subject: Re: Bug#112770: ratpoison: C-t a kills ratpoison

Date: Fri, 21 Sep 2001 18:03:43 +0200

Thus spoke Bruce McIntyre <bmcintyre@primus.com.au> on 2001-09-19 23:31:30:
> C-t a, instead of invoking the clock, quits ratpoison (and, of course, X)
> unexpectedly.

I can't reproduce this on i386, it might be a ppc problem..
However, looking at the code, I can't think of anything related. Could
you do something for me?

Start X as usual, then attach gdb to ratpoison, by launching gdb, and
typing: attach <pid of ratpoison>

Then, try C-t a, which will probably crash ratpoison, so change back
to gdb, and type `backtrace', and `quit', then send me the output of
gdb.

If you want to be of even more help, you could try building a
debug-enabled version, by apt-get source -ing ratpoison, and typing
debian/rules binary DEB_BUILD_OPTIONS=debug,nostrip?

Then, when it compiled, you can install the resulting .deb, which will
have debug symbols in it, and repeat the gdb step above.

TIA,
-- 
Gergely Nagy \ mhp/|8]

Message #15 received at 112770@bugs.debian.org (full text, mbox, reply):

From: Gergely Nagy <algernon@debian.org>

To: 112770@bugs.debian.org

Subject: [FWD] Re: Bug#112770: ratpoison: C-t a kills ratpoison (from: bmcintyre@primus.com.au)

Date: Tue, 25 Sep 2001 18:09:25 +0200

Forwarded here to have a copy...

----- Forwarded message from Bruce McIntyre <bmcintyre@primus.com.au> -----

From: Bruce McIntyre <bmcintyre@primus.com.au>
Subject: Re: Bug#112770: ratpoison: C-t a kills ratpoison
To: Gergely Nagy <algernon@debian.org>
Date: Tue, 25 Sep 2001 15:10:18 +1000
Message-ID: <20010925151018.A20040@plato>
In-Reply-To: <20010921180343.E5980@iluvatar>
User-Agent: Mutt/1.3.22i

* Gergely Nagy (algernon@debian.org) wrote:
> Thus spoke Bruce McIntyre <bmcintyre@primus.com.au> on 2001-09-19 23:31:30:
> > C-t a, instead of invoking the clock, quits ratpoison (and, of course, X)
> > unexpectedly.
> 
> I can't reproduce this on i386, it might be a ppc problem..
> However, looking at the code, I can't think of anything related. Could
> you do something for me?
> 
> Start X as usual, then attach gdb to ratpoison, by launching gdb, and
> typing: attach <pid of ratpoison>
> 
> Then, try C-t a, which will probably crash ratpoison, so change back
> to gdb, and type `backtrace', and `quit', then send me the output of
> gdb.
> 
> If you want to be of even more help, you could try building a
> debug-enabled version, by apt-get source -ing ratpoison, and typing
> debian/rules binary DEB_BUILD_OPTIONS=debug,nostrip?
> 
> Then, when it compiled, you can install the resulting .deb, which will
> have debug symbols in it, and repeat the gdb step above.
> 
> TIA,
> -- 
> Gergely Nagy \ mhp/|8]

Ok,
I'm having trouble getting ratpoisons attention with the C-t key. It seems
that xterm is trapping them; furthermore ratpoison -c commands don't seem to work.
The previous problem was a no-brainer ( I misspelt ratpoison in
my .xsession file!)

No... when I have no xterm still C-t is not getting ratpoison's attention.
should I send you the gdb output from this ? Do I still do a backtrace?

-- 
Bruce McIntyre.

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

-- 
Gergely Nagy \ mhp/|8]

Message #20 received at 112770@bugs.debian.org (full text, mbox, reply):

From: Gergely Nagy <algernon@debian.org>

To: Bruce McIntyre <bmcintyre@primus.com.au>, 112770@bugs.debian.org

Subject: Re: Bug#112770: ratpoison: C-t a kills ratpoison

Date: Tue, 25 Sep 2001 18:11:26 +0200

Thus spoke Bruce McIntyre <bmcintyre@primus.com.au> on 2001-09-25 15:10:18:
> Ok,
> I'm having trouble getting ratpoisons attention with the C-t key. It seems
> that xterm is trapping them; furthermore ratpoison -c commands don't seem to work.
> The previous problem was a no-brainer ( I misspelt ratpoison in
> my .xsession file!)
>

That seems strange. I'm forwarding this upstream..

> No... when I have no xterm still C-t is not getting ratpoison's attention.
> should I send you the gdb output from this ? Do I still do a backtrace?

Well.. I guess I couldn't do much with it right now.. We'll see what
upstream says.

-- 
Gergely Nagy \ mhp/|8]

Message #29 received at 112770@bugs.debian.org (full text, mbox, reply):

From: Lukas Geyer <geyer@ml.kva.se>

To: "debian-powerpc@lists.debian.org" <debian-powerpc@lists.debian.org>

Cc: <112770@bugs.debian.org>

Subject: Re: Can anyone help with #112770?

Date: Sun, 20 Jan 2002 17:32:11 +0100 (CET)

On Sat, 19 Jan 2002, Chris Tillman wrote:

> The upshot is that powerpc compilers enforce the correct usage of
> varargs, where most i386 compilers do not. It's not really a powerpc
> specific problem.

Yep, and here is a patch, against the current sid source, untested, maybe
someone should test this or rather redesign the interface relating to
xvsprintf() and stuff. The manpage to vsnprintf() explicitly says that the
va_list contains something undefined afterwards, so one cannot call it
twice in a row without va_end(), va_start() in between.

Lukas

The patch:

diff -purN ratpoison-1.0.0.cvs.20020117/src/bar.c ratpoison-1.0.0.cvs.20020117.mod/src/bar.c
--- ratpoison-1.0.0.cvs.20020117/src/bar.c	Fri Dec 21 12:58:56 2001
+++ ratpoison-1.0.0.cvs.20020117.mod/src/bar.c	Sun Jan 20 17:21:28 2002
@@ -124,7 +124,7 @@ marked_message_printf (int mark_start, i
   va_list ap;

   va_start (ap, fmt);
-  buffer = xvsprintf (fmt, ap);
+  xvsprintf (buffer, fmt, ap);
   va_end (ap);

   marked_message (buffer, mark_start, mark_end);
diff -purN ratpoison-1.0.0.cvs.20020117/src/main.c ratpoison-1.0.0.cvs.20020117.mod/src/main.c
--- ratpoison-1.0.0.cvs.20020117/src/main.c	Wed Jan 16 21:55:17 2002
+++ ratpoison-1.0.0.cvs.20020117.mod/src/main.c	Sun Jan 20 17:02:22 2002
@@ -126,47 +126,13 @@ xstrdup (char *s)

 /* Return a new string based on fmt. */
 char *
-xvsprintf (char *fmt, va_list ap)
-{
-  int size, nchars;
-  char *buffer;
-
-  /* A resonable starting value. */
-  size = strlen (fmt) + 1;
-  buffer = (char *)xmalloc (size);
-
-  nchars = vsnprintf (buffer, size, fmt, ap);
-
-  /* From the GNU Libc manual: In versions of the GNU C library prior
-     to 2.1 the return value is the number of characters stored, not
-     including the terminating null; unless there was not enough space
-     in S to store the result in which case `-1' is returned. */
-  if (nchars == -1)
-    {
-      do
-	{
-	  size *= 2;
-	  buffer = (char *)xrealloc (buffer, size);
-	} while (vsnprintf (buffer, size, fmt, ap) == -1);
-    }
-  else if (nchars >= size)
-    {
-      buffer = (char *)xrealloc (buffer, nchars + 1);
-      vsnprintf (buffer, nchars + 1, fmt, ap);
-    }
-
-  return buffer;
-}
-
-/* Return a new string based on fmt. */
-char *
 xsprintf (char *fmt, ...)
 {
   char *buffer;
   va_list ap;

   va_start (ap, fmt);
-  buffer = xvsprintf (fmt, ap);
+  xvsprintf (buffer, fmt, ap);
   va_end (ap);

   return buffer;
diff -purN ratpoison-1.0.0.cvs.20020117/src/ratpoison.h ratpoison-1.0.0.cvs.20020117.mod/src/ratpoison.h
--- ratpoison-1.0.0.cvs.20020117/src/ratpoison.h	Fri Dec 21 12:58:56 2001
+++ ratpoison-1.0.0.cvs.20020117.mod/src/ratpoison.h	Sun Jan 20 17:05:22 2002
@@ -70,6 +70,43 @@ void *xmalloc (size_t size);
 void *xrealloc (void *ptr, size_t size);
 char *xstrdup (char *s);
 char *xsprintf (char *fmt, ...);
-char *xvsprintf (char *fmt, va_list ap);
+
+/* Return a new string based on fmt. */
+
+/*
+ * This should be replaced by something cleaner. Maybe the authors
+ * should (re)read the manpages of vsnprintf and stdarg and redesign
+ * this interface.
+ */
+#define xvsprintf(buf,fmt,ap) \
+{ \
+  int size = strlen(fmt) + 1; \
+  int nchars; \
+  \
+  buf = xmalloc(size); \
+  nchars = vsnprintf (buf, size, fmt, ap); \
+  \
+  /* From the GNU Libc manual: In versions of the GNU C library prior  \
+     to 2.1 the return value is the number of characters stored, not   \
+     including the terminating null; unless there was not enough space \
+     in S to store the result in which case `-1' is returned. */       \
+  if (nchars == -1) \
+    { \
+      do \
+	{ \
+	  size *= 2; \
+	  buf = xrealloc (buf, size); \
+	  va_end(ap); \
+	  va_start(ap, fmt); \
+	} while (vsnprintf (buf, size, fmt, ap) == -1); \
+    } \
+  else if (nchars >= size) \
+    { \
+      buf = xrealloc (buf, nchars + 1); \
+      va_end(ap); \
+      va_start(ap, fmt); \
+      vsnprintf (buf, nchars + 1, fmt, ap); \
+    } \
+}

 #endif /* ! _RATPOISON_H */
diff -purN ratpoison-1.0.0.cvs.20020117/src/sbuf.c ratpoison-1.0.0.cvs.20020117.mod/src/sbuf.c
--- ratpoison-1.0.0.cvs.20020117/src/sbuf.c	Fri Dec 21 12:58:56 2001
+++ ratpoison-1.0.0.cvs.20020117.mod/src/sbuf.c	Sun Jan 20 17:00:58 2002
@@ -98,7 +98,7 @@ sbuf_printf (struct sbuf *b, char *fmt,
   free (b->data);

   va_start (ap, fmt);
-  b->data = xvsprintf (fmt, ap);
+  xvsprintf (b->data, fmt, ap);
   va_end (ap);

   return b->data;
@@ -111,7 +111,7 @@ sbuf_printf_concat (struct sbuf *b, char
   va_list ap;

   va_start (ap, fmt);
-  buffer = xvsprintf (fmt, ap);
+  xvsprintf (buffer, fmt, ap);
   va_end (ap);

   sbuf_concat (b, buffer);

Message #40 received at 112770@bugs.debian.org (full text, mbox, reply):

From: Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>

To: Lukas Geyer <geyer@ml.kva.se>

Cc: "debian-powerpc@lists.debian.org" <debian-powerpc@lists.debian.org>, <112770@bugs.debian.org>

Subject: Re: Can anyone help with #112770?

Date: Mon, 21 Jan 2002 13:09:17 +0100 (CET)

> > The upshot is that powerpc compilers enforce the correct usage of
> > varargs, where most i386 compilers do not. It's not really a powerpc
> > specific problem.

In this case it's rather incorrect usage on PowerPC leading to disastrous
results, while you can get away with incorrect usage on other platforms
more easily. The compiler only enforces correct use of data types in
va_arg(). Improper reuse of va_list data isn't caught.

> Yep, and here is a patch, against the current sid source, untested, maybe
> someone should test this or rather redesign the interface relating to
> xvsprintf() and stuff. The manpage to vsnprintf() explicitly says that the
> va_list contains something undefined afterwards, so one cannot call it
> twice in a row without va_end(), va_start() in between.

Looks OK to me.

	Michael

Message #51 received at 112770-done@bugs.debian.org (full text, mbox, reply):

From: Jonathan Walther <krooger@debian.org>

To: 112770-done@bugs.debian.org

Subject: fixed

Date: Mon, 10 Jun 2002 03:11:10 -0700

[Message part 1 (text/plain, inline)]

The latest upload of this package fixes that problem

Jonathan

-- 
                    Geek House Productions, Ltd.

 Providing Unix & Internet Contracting and Consulting,
 QA Testing, Technical Documentation, Systems Design & Implementation,
 General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.