Debian Bug report logs - #423141
ratpoison runs out of memory when truncating invalid multi byte sequences

Toggle useless messages

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: submit@bugs.debian.org

Subject: Ratpoison bad build?

Date: Wed, 9 May 2007 23:21:34 -0700

Package: ratpoison
Version: 1.4.1-3
Severity: normal

In the current binary package of ratpoison, it is possible to trigger an
abort() by opening many tabs in Opera (www.opera.com), and hitting
C-leftarrow, C-rightarrow (switch tabs), and C-t w repeatedly in quick
succession. The gdb backtrace shows abort() being triggered somewhere
inside xrealloc(), indicating some kind of memory corruption.

However, I built a local copy of ratpoison with debugging symbols
included, and could not trigger the bug. I rebuilt with
dpkg-buildpackage and could not trigger the bug either. Perhaps the
binary in the uploaded package wasn't correctly built somehow?


--T

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: Ratpoison bad build?

Date: Thu, 10 May 2007 09:46:14 +0200

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070510 08:26]:
> In the current binary package of ratpoison, it is possible to trigger an
> abort() by opening many tabs in Opera (www.opera.com), and hitting
> C-leftarrow, C-rightarrow (switch tabs), and C-t w repeatedly in quick
> succession. The gdb backtrace shows abort() being triggered somewhere
> inside xrealloc(), indicating some kind of memory corruption.
> However, I built a local copy of ratpoison with debugging symbols
> included, and could not trigger the bug. I rebuilt with
> dpkg-buildpackage and could not trigger the bug either. Perhaps the
> binary in the uploaded package wasn't correctly built somehow?

What architecture are you using?
Does the backtrace stop with xrealloc or does it show where this is
called?
Could you try to run it in valgrind or put a xtrace between ratpoison
and the server so I can see what opera is doing when switching tabs?

Hochachtungsvoll,
	Bernhard R. Link

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: Bug#423141: Ratpoison bad build?

Date: Thu, 10 May 2007 22:07:18 -0700

On Thu, May 10, 2007 at 09:46:14AM +0200, Bernhard R. Link wrote:
> * H. S. Teoh <hsteoh@quickfur.ath.cx> [070510 08:26]:
> > In the current binary package of ratpoison, it is possible to trigger an
> > abort() by opening many tabs in Opera (www.opera.com), and hitting
> > C-leftarrow, C-rightarrow (switch tabs), and C-t w repeatedly in quick
> > succession. The gdb backtrace shows abort() being triggered somewhere
> > inside xrealloc(), indicating some kind of memory corruption.
> > However, I built a local copy of ratpoison with debugging symbols
> > included, and could not trigger the bug. I rebuilt with
> > dpkg-buildpackage and could not trigger the bug either. Perhaps the
> > binary in the uploaded package wasn't correctly built somehow?
> 
> What architecture are you using?

i686 (Athlon Barton).


> Does the backtrace stop with xrealloc or does it show where this is
> called?

The backtrace stops with xrealloc, and gdb says something along the
lines of no stack frame being available to trace the higher calls.


> Could you try to run it in valgrind or put a xtrace between ratpoison
> and the server so I can see what opera is doing when switching tabs?
[...]

Hmm, the problem seems to have gone away after I upgraded to the latest
unstable. I can't reproduce the problem anymore. It may have been a
dynamic library issue with the X libraries (I know I've seen similar
hard-to-reproduce problems in the past due to sync problems with X
dynamic libraries). Close this bug if you wish, I'll reopen it if the
problems comes back.


--T

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

From: "Bernhard R. Link" <brlink@debian.org>

To: 423141-done@bugs.debian.org

Subject: Re: Bug#423141: Ratpoison bad build?

Date: Fri, 11 May 2007 10:01:34 +0200

package: ratpoison
version: 1.4.1-3

> Hmm, the problem seems to have gone away after I upgraded to the latest
> unstable. I can't reproduce the problem anymore. It may have been a
> dynamic library issue with the X libraries (I know I've seen similar
> hard-to-reproduce problems in the past due to sync problems with X
> dynamic libraries). Close this bug if you wish, I'll reopen it if the
> problems comes back.

Ok, I'll do so. Thanks for your investigation.

Hochachtungsvoll,
	Bernhard R. Link

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org, control@bugs.debian.org

Subject: Bug recurred

Date: Tue, 15 May 2007 23:40:07 -0700

reopen 423141
thanks

Hi, today the bug recurred. I had put in an xmessage command after
ratpoison in my .Xsession file in order to catch ratpoison crashing, so
I was able to poke around the environment a little after the crash to
determine what was going on. It appears that ratpoison is running out of
virtual memory when I hit C-t w, for some reason. I wasn't running any
memory hog except perhaps Opera, but then I never had things crashing
because of lack of memory---at least, not unless I run something that
uses a LOT of memory, and I can't imagine ratpoison opening a little
window needing *that* much memory. Just this morning I was running a
memory-hogging process that took up tens of MBs, and ratpoison didn't
have any trouble opening the window list then.

The message I'm getting is:

ratpoison: Virtual memory exhausted
[2]    Abort                         ratpoison


Strangely enough, after restarting ratpoison several times (while
keeping the xmessage open so the session won't logout), the problem went
away. All I did during that time was to save an email I was in the
middle of typing (only ~200 lines, in mutt, which is text-based, so
again I can't imagine how that could make a difference).

Memory usage while the crash was happening:

MemTotal:       255164 kB
MemFree:         28648 kB
Buffers:         15784 kB
Cached:         100048 kB
SwapCached:      21264 kB
Active:         152716 kB
Inactive:        62508 kB
SwapTotal:      120476 kB
SwapFree:        51108 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:       91168 kB
Mapped:          22316 kB
Slab:             7724 kB
SReclaimable:     3048 kB
SUnreclaim:       4676 kB
PageTables:       1136 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:    248056 kB
Committed_AS:   682740 kB
VmallocTotal:   777940 kB
VmallocUsed:      9328 kB
VmallocChunk:   768524 kB


Memory usage after things started working again:

MemTotal:       255164 kB
MemFree:         29304 kB
Buffers:         17892 kB
Cached:         101952 kB
SwapCached:      21524 kB
Active:         150060 kB
Inactive:        64584 kB
SwapTotal:      120476 kB
SwapFree:        52460 kB
Dirty:              24 kB
Writeback:           0 kB
AnonPages:       86412 kB
Mapped:          19588 kB
Slab:             7744 kB
SReclaimable:     3048 kB
SUnreclaim:       4696 kB
PageTables:       1124 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:    248056 kB
Committed_AS:   674644 kB
VmallocTotal:   777940 kB
VmallocUsed:      9328 kB
VmallocChunk:   768524 kB


I don't see that much of a difference in memory usage, so I'm not
convinced that it's simply because I have too little RAM. I suspect
there may be some other factor that perhaps triggers a bug in ratpoison
causing it to try to allocate an unusually large amount of memory.


--T

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: Bug recurred

Date: Fri, 18 May 2007 15:26:07 +0200

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070516 08:42]:
> Hi, today the bug recurred. I had put in an xmessage command after
> ratpoison in my .Xsession file in order to catch ratpoison crashing, so
> I was able to poke around the environment a little after the crash to
> determine what was going on. It appears that ratpoison is running out of
> virtual memory when I hit C-t w, for some reason. I wasn't running any
> memory hog except perhaps Opera, but then I never had things crashing
> because of lack of memory---at least, not unless I run something that
> uses a LOT of memory, and I can't imagine ratpoison opening a little
> window needing *that* much memory. Just this morning I was running a
> memory-hogging process that took up tens of MBs, and ratpoison didn't
> have any trouble opening the window list then.

Problems with running out of memory are always hard to localize.
Could you try something of the following:

1) running ratpoison in valgrind (using the --leak-check=full option)
to see if that finds any memory holes (it will almost always find a bit
of memory lost in the end, but that is just state information not free'd
in the end but not really lost while running). (valgrind will most
likely also complain about uninitialized usages in Xlibs, that is
harmless, too).
Running in valgrind might slow ratpoison down considerably. On a slow
computer just try to run Opera or what you think it can reproduce it
directly and quit then to take a look at what valgrind outputted.

2) Checking what ratpoison is actually requesting the money itself.
Looking for it's pid and then looking at the Vm values in
/proc/<pid>/status. This should also be possible while it runs.
Intresting is if the values increase over long running of ratpoison.

Hochachtungsvoll,
	Bernhard R. Link

Message #37 received at 423141-close@bugs.debian.org (full text, mbox, reply):

From: brlink@debian.org (Bernhard R. Link)

To: 423141-close@bugs.debian.org

Subject: Bug#423141: fixed in ratpoison 1.4.1-4

Date: Fri, 01 Jun 2007 19:17:03 +0000

Source: ratpoison
Source-Version: 1.4.1-4

We believe that the bug you reported is fixed in the latest version of
ratpoison, which is due to be installed in the Debian FTP archive:

ratpoison_1.4.1-4.diff.gz
  to pool/main/r/ratpoison/ratpoison_1.4.1-4.diff.gz
ratpoison_1.4.1-4.dsc
  to pool/main/r/ratpoison/ratpoison_1.4.1-4.dsc
ratpoison_1.4.1-4_sparc.deb
  to pool/main/r/ratpoison/ratpoison_1.4.1-4_sparc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 423141@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard R. Link <brlink@debian.org> (supplier of updated ratpoison package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 01 Jun 2007 20:04:18 +0200
Source: ratpoison
Binary: ratpoison
Architecture: source sparc
Version: 1.4.1-4
Distribution: unstable
Urgency: low
Maintainer: Bernhard R. Link <brlink@debian.org>
Changed-By: Bernhard R. Link <brlink@debian.org>
Description: 
 ratpoison  - keyboard-only window manager
Closes: 423141
Changes: 
 ratpoison (1.4.1-4) unstable; urgency=low
 .
   * close memory hole in dealing with utf-8 window titles (Closes: 423141)
Files: 
 24e4e0fe42c5029a3a5708acef35137e 671 x11 extra ratpoison_1.4.1-4.dsc
 4c4cbe994e979b29bf50a509b1527bd7 44077 x11 extra ratpoison_1.4.1-4.diff.gz
 60cd206332ec118175a6b0f403d135fd 174518 x11 extra ratpoison_1.4.1-4_sparc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGYG8mTrAWvKplQe4RAtM7AJ9MdXSBow8nzzeclAxL14aoJGxq+ACcCFbd
eQIM/WmT8yDaW02lTa84xdE=
=UIlt
-----END PGP SIGNATURE-----

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: control@bugs.debian.org, 423141@bugs.debian.org

Subject: Bug reproduced, found cause of problem

Date: Fri, 29 Jun 2007 21:31:25 -0700

reopen 423141
thanks

Hi, the bug recurred again today, and I finally discovered the cause. It
is because I have Opera currently viewing a page that contains a ®
entity in its <title> attribute. When I switch to this tab, Opera uses
it as its window title, and then C-t w causes ratpoison to exit with
status 134. I managed to capture the error message as well: "Virtual
memory exhausted". If I switch to another tab whose title doesn't
contain this character, C-t w works fine.

Perhaps this is a UTF-8 issue that hasn't been fully resolved? I'm not
sure what other characters may cause this problem, but I can
consistently crash ratpoison this way.

Anyway, if you want to reproduce this bug, you can create a simple HTML
file and open it in Opera, then hit C-t w. Something like this:

<html><head><title>Crash page&reg;</title></head><body></body></html>

I'm running in a UTF-8 locale, if that makes a difference. Also, my
.ratpoisonrc looks like:

set winfmt %n%s%80t
set wingravity center
set font -misc-fixed-medium-r-normal-*-18-*-*-*-*-*-iso10646-1


I suspect it may be a combination of UTF-8 locale, font, and special
character in window title, that triggers this bug in ratpoison. The font
referenced in above is from the xfonts-efont-unicode (or
xfonts-efont-unicode-ib) package.

I also attached valgrind to ratpoison, and here is the output:

==24073== Memcheck, a memory error detector.
==24073== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==24073== Using LibVEX rev 1732, a library for dynamic binary translation.
==24073== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==24073== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation framework.
==24073== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==24073== For more details, rerun with: -v
==24073== 
==24073== Source and destination overlap in mempcpy(0x42EC678, 0x42EC678, 25)
==24073==    at 0x4023B24: mempcpy (mc_replace_strmem.c:116)
==24073==    by 0x41A06F4: _IO_default_xsputn (in /lib/libc-2.5.so)
==24073==    by 0x417C202: vfprintf (in /lib/libc-2.5.so)
==24073==    by 0x4195C1B: vsprintf (in /lib/libc-2.5.so)
==24073==    by 0x4181F2D: sprintf (in /lib/libc-2.5.so)
==24073==    by 0x40BF9A0: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x40BFAC5: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x40C0424: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x40722B6: XCreateOC (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x40667B6: XCreateFontSet (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x805BFCD: (within /usr/bin/ratpoison)
==24073==    by 0x805CEDB: (within /usr/bin/ratpoison)
==24073== 
==24073== Invalid read of size 4
==24073==    at 0x4016530: (within /lib/ld-2.5.so)
==24073==    by 0x4006009: (within /lib/ld-2.5.so)
==24073==    by 0x40084F5: (within /lib/ld-2.5.so)
==24073==    by 0x40121D4: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==    by 0x4288B60: dlopen (in /lib/libdl-2.5.so)
==24073==    by 0x4061448: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==24073==  Address 0x42EDAD8 is 24 bytes inside a block of size 25 alloc'd
==24073==    at 0x40224B0: malloc (vg_replace_malloc.c:149)
==24073==    by 0x4008AF3: (within /lib/ld-2.5.so)
==24073==    by 0x40121D4: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==    by 0x4288B60: dlopen (in /lib/libdl-2.5.so)
==24073==    by 0x4061448: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x4061CAC: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==24073== 
==24073== Invalid read of size 4
==24073==    at 0x4016530: (within /lib/ld-2.5.so)
==24073==    by 0x4006009: (within /lib/ld-2.5.so)
==24073==    by 0x40084F5: (within /lib/ld-2.5.so)
==24073==    by 0x400C616: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x400CBDA: (within /lib/ld-2.5.so)
==24073==    by 0x4012234: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==  Address 0x42EDE10 is 24 bytes inside a block of size 25 alloc'd
==24073==    at 0x40224B0: malloc (vg_replace_malloc.c:149)
==24073==    by 0x4008AF3: (within /lib/ld-2.5.so)
==24073==    by 0x400C616: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x400CBDA: (within /lib/ld-2.5.so)
==24073==    by 0x4012234: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==    by 0x4288B60: dlopen (in /lib/libdl-2.5.so)
==24073== 
==24073== Conditional jump or move depends on uninitialised value(s)
==24073==    at 0x400B3CC: (within /lib/ld-2.5.so)
==24073==    by 0x401230B: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==    by 0x4288B60: dlopen (in /lib/libdl-2.5.so)
==24073==    by 0x4061448: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x4061CAC: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x805F232: (within /usr/bin/ratpoison)
==24073== 
==24073== Conditional jump or move depends on uninitialised value(s)
==24073==    at 0x400B0CA: (within /lib/ld-2.5.so)
==24073==    by 0x401230B: (within /lib/ld-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x4011C5D: (within /lib/ld-2.5.so)
==24073==    by 0x4288C2C: (within /lib/libdl-2.5.so)
==24073==    by 0x400E255: (within /lib/ld-2.5.so)
==24073==    by 0x428929B: (within /lib/libdl-2.5.so)
==24073==    by 0x4288B60: dlopen (in /lib/libdl-2.5.so)
==24073==    by 0x4061448: (within /usr/lib/libX11.so.6.2.0)
==24073==    by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x4061CAC: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==24073==    by 0x805F232: (within /usr/bin/ratpoison)
ratpoison: Virtual memory exhausted==24073== 
==24073== ERROR SUMMARY: 35 errors from 5 contexts (suppressed: 31 from 1)
==24073== malloc/free: in use at exit: 100,738,676 bytes in 1,266 blocks.
==24073== malloc/free: 2,421 allocs, 1,155 frees, 402,784,955 bytes allocated.
==24073== For counts of detected errors, rerun with: -v
==24073== searching for pointers to 1,266 not-freed blocks.
==24073== checked 229,156 bytes.
==24073== 
==24073== LEAK SUMMARY:
==24073==    definitely lost: 20 bytes in 1 blocks.
==24073==      possibly lost: 4,316 bytes in 146 blocks.
==24073==    still reachable: 100,734,340 bytes in 1,119 blocks.
==24073==         suppressed: 0 bytes in 0 blocks.
==24073== Rerun with --leak-check=full to see details of leaked memory.


Hope this helps to find the real cause of the bug. Please let me know if
you want me to re-run valgrind with different options. I've setup my
.xsession so that it runs ratpoison in a loop, displaying a prompt
whether to restart ratpoison if it crashes. So I should be able to try
out different things more easily without having to interrupt my session.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: P.S.

Date: Fri, 29 Jun 2007 21:39:17 -0700

Also, I might add, this only happens with Opera window titles. I tried
to set my rxvt title to a string containing the ® character, but it
displayed correctly. I'm not sure if this could be a bug in Opera (maybe
it's not encoding the window title properly---I'm not sure how to check
since ratpoison crashes outright trying to display it). But in any case,
ratpoison shouldn't crash.


T

-- 
Let's eat some disquits while we format the biskettes.

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sat, 30 Jun 2007 11:11:25 +0200

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 06:45]:
> Also, I might add, this only happens with Opera window titles. I tried
> to set my rxvt title to a string containing the &reg; character, but it
> displayed correctly. I'm not sure if this could be a bug in Opera (maybe
> it's not encoding the window title properly---I'm not sure how to check
> since ratpoison crashes outright trying to display it). But in any case,
> ratpoison shouldn't crash.

Could you send me the output of xprop on that window when it displays
that character? That would make it easier to try to reproduce it.

Especially as ratpoison is not doing much with the content, it might
also be a problem within xlibs. Could you mail me the versions
of ratpoison and its dependencies?
(For example the output of "dpkg -s ratpoison libx11-6 libxext6 | grep Version")

Hochachtungsvoll,
	Bernhard R. Link

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sat, 30 Jun 2007 06:57:13 -0700

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

On Sat, Jun 30, 2007 at 11:11:25AM +0200, Bernhard R. Link wrote:
> * H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 06:45]:
> > Also, I might add, this only happens with Opera window titles. I
> > tried to set my rxvt title to a string containing the &reg;
> > character, but it displayed correctly. I'm not sure if this could be
> > a bug in Opera (maybe it's not encoding the window title
> > properly---I'm not sure how to check since ratpoison crashes
> > outright trying to display it). But in any case, ratpoison shouldn't
> > crash.
> 
> Could you send me the output of xprop on that window when it displays
> that character? That would make it easier to try to reproduce it.

Ah, so *that's* how I can get info out of the window without a WM. :-)
The output is attached.


> Especially as ratpoison is not doing much with the content, it might
> also be a problem within xlibs. Could you mail me the versions
> of ratpoison and its dependencies?
[...]

ii  libc6          2.5-9+b1       GNU C Library: Shared libraries
ii  libreadline5   5.2-3          GNU readline and history libraries, run-time
ii  libx11-6       2:1.0.3-7      X11 client-side library
ii  libxext6       1:1.0.3-2      X11 miscellaneous extension library
ii  libxinerama1   1:1.0.2-1      X11 Xinerama extension library
ii  libxtst6       1:1.0.1-5      X11 Testing -- Resource extension library
ii  ratpoison      1.4.1-4        keyboard-only window manager


Hope this helps to track down the problem.


T

-- 
"Life is all a great joke, but only the brave ever get the point." --
Kenneth Rexroth

[xprop.out (text/plain, attachment)]

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sat, 30 Jun 2007 18:57:01 +0200

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 16:00]:
> Hope this helps to track down the problem.

Could you try the attached program, if it also causes the crash?
(Needs libx11-dev installed and compile with
 gcc xfakewindow.c -o xfakewindow -lX11)

Hochachtungsvoll,
	Bernhard R. Link

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sat, 30 Jun 2007 11:03:24 -0700

On Sat, Jun 30, 2007 at 06:57:01PM +0200, Bernhard R. Link wrote:
> * H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 16:00]:
> > Hope this helps to track down the problem.
> 
> Could you try the attached program, if it also causes the crash?
> (Needs libx11-dev installed and compile with
>  gcc xfakewindow.c -o xfakewindow -lX11)
[...]

Did you forget the attachment?


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice,
c-moss, binary trees... and bugs.

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sun, 1 Jul 2007 11:59:59 +0200

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

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 20:06]:
> > Could you try the attached program, if it also causes the crash?
> > (Needs libx11-dev installed and compile with
> >  gcc xfakewindow.c -o xfakewindow -lX11)
> [...]
> Did you forget the attachment?

Second attempt...

Hochachtungsvoll,
	Bernhard R. Link

[xfakewindow.c (text/x-csrc, attachment)]

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sun, 1 Jul 2007 06:33:11 -0700

On Sun, Jul 01, 2007 at 11:59:59AM +0200, Bernhard R. Link wrote:
> * H. S. Teoh <hsteoh@quickfur.ath.cx> [070630 20:06]:
> > > Could you try the attached program, if it also causes the crash?
> > > (Needs libx11-dev installed and compile with
> > >  gcc xfakewindow.c -o xfakewindow -lX11)
> > [...]
> > Did you forget the attachment?
> 
> Second attempt...
[...]

Yep, it crashes. Although, the way the program is written is rather
tricky to test, since it exits on keystrokes, so I have to hit C-t w
before starting it. :-) I guess this also has a side benefit of testing
an alternate code path in ratpoison that leads to the same crash
(updating of window list rather than just displaying it).


T

-- 
Never ascribe to malice that which is adequately explained by
incompetence. -- Napoleon Bonaparte

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: Re: Bug#423141: P.S.

Date: Sun, 1 Jul 2007 15:52:04 +0200

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070701 15:40]:
> Yep, it crashes. Although, the way the program is written is rather
> tricky to test, since it exits on keystrokes, so I have to hit C-t w
> before starting it. :-)

oh, sorry. I don't have any modifiers in my escape key. I guess that's
why that was no problem for me.

> I guess this also has a side benefit of testing
> an alternate code path in ratpoison that leads to the same crash
> (updating of window list rather than just displaying it).

Thanks for testing this. Now I 'only' have to find out why it crashes for
you but not for me. (Though I have not yet tested with your fonts or
with a real X server (opposed to Xephyr) or the same libs (except
libx11)).
That may need some days before I can tell more. (Or have ideas for new testcases...)

Hochachtungsvoll,
	Bernhard R. Link

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org

Subject: more questions about #423141

Date: Wed, 11 Jul 2007 11:06:16 +0200

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

* Bernhard R. Link <brlink@debian.org> [070701 15:55]:
> Thanks for testing this. Now I 'only' have to find out why it crashes for
> you but not for me. (Though I have not yet tested with your fonts or
> with a real X server (opposed to Xephyr) or the same libs (except
> libx11)).

After learning a lot about how Xlib caches its events, extending xtrace
to tell me more about some obscure extensions xlib is using and finding
(most likely totally) unrelated bugs in ratpoison while searching for
this one, and trying to reproduce with all things the same version I'm
still lost. So here some more tests and questions, though I have to
admit they are mostly guessing into the dark...

> That may need some days before I can tell more. (Or have ideas for new testcases...)
> * H. S. Teoh <hsteoh@quickfur.ath.cx> [070701 15:40]:
> > Yep, it crashes. Although, the way the program is written is rather
> > tricky to test, since it exits on keystrokes, so I have to hit C-t w
> > before starting it. :-)

Attached is a new version of the test program, that should be less
sesnsitive to key events.

Could you test if it also shows the behaviour of aborting when showing
the window list after program started? (and not while the program is
running).

There is a loop to 1000 near the end of the program. Does it also happen
if that loop is removed?

Does it also happen without the font or the winfmt set?
(try starting ratpoison with -f /dev/null to make it omit your
.ratpoisonrc). Both the test program and opera would be intresting.

What locale is your ratpoison running with? Does the bug still show up,
if ratpoison is running in en_US (without .UTF-8) locale?
(You might need to generate that first to make sure it can be used, if
it is not in /etc/locale.gen yet).

Is a locally build ratpoison still unable to reproduce the problem?
(if it is now with more knowledge what triggers it, a backtrace with
 debug symbols would be intresting).

Even without debug symbols for ratpoison, does the backtrace give any
further hints where this happens? (well, there is a good chance that
even if this place is located, it might just be something else wanting
memory after the faulty part ate all of it, but at least there is a
chance it is the buggy part).
Installing libx11-dbg might give more hints if xlib calls are involved.

Could you try running ratpoison in valgrind --tool=massif and send me
the .txt files it generates? (Best one time for opera and one time for
the xfakewindow program)

Thanks in advance,
	Bernhard R. Link

[xfakewindow.c (text/x-csrc, attachment)]

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: more questions about #423141

Date: Mon, 13 Aug 2007 20:30:51 -0700

Hi, sorry for taking so long to reply. Things just kept coming up.


On Wed, Jul 11, 2007 at 11:06:16AM +0200, Bernhard R. Link wrote:
[...]
> > That may need some days before I can tell more. (Or have ideas for
> > new testcases...)
> > * H. S. Teoh <hsteoh@quickfur.ath.cx> [070701 15:40]:
> > > Yep, it crashes. Although, the way the program is written is rather
> > > tricky to test, since it exits on keystrokes, so I have to hit C-t w
> > > before starting it. :-)
> 
> Attached is a new version of the test program, that should be less
> sesnsitive to key events.
> 
> Could you test if it also shows the behaviour of aborting when showing
> the window list after program started? (and not while the program is
> running).

Ratpoison crashes both when I start the program then hit C-t w, and when
I hit C-t w then run the program while the window list is still visible.


> There is a loop to 1000 near the end of the program. Does it also
> happen if that loop is removed?

Yes, still happens.


> Does it also happen without the font or the winfmt set?
> (try starting ratpoison with -f /dev/null to make it omit your
> .ratpoisonrc). Both the test program and opera would be intresting.

Actually, I think I found the real bug!! My .ratpoisonrc looks like:

	set winfmt %n%s%80t
	set wingravity center
	set font -misc-fixed-medium-r-normal-*-18-*-*-*-*-*-iso10646-1

After commenting out the winfmt line, ratpoison doesn't crash anymore
with the test program, or with Opera. I see that the special symbols
don't show up in the window list (e.g., on the Intel page, the
registered trademark symbol is omitted from the window title). Looks
like a pointer bug in format_string() (src/format.c) perhaps?


> What locale is your ratpoison running with?

en_US.UTF-8


I'll try to run through the rest of your suggestions later, but I think
we've found the culprit. I'll take a peek at format_string() to see if
there's anything obviously wrong with it.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

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

From: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

To: 423141@bugs.debian.org

Subject: Re: more questions about #423141

Date: Mon, 13 Aug 2007 21:10:16 -0700

Hi,

Now that I know where the bug is, I've managed to reproduce it with a
debug build of ratpoison. Using gdb backtrace, I've located the
problematic code: the xvsprintf() function in main.c. Towards the end of
this function, there is this bit of code:

-------------------------------------------------------------
      nchars = vsnprintf (buffer, size, fmt, ap_copy);
#if defined(va_copy) || defined(__va_copy)
      va_end (ap_copy);
#endif

      if (nchars > -1 && nchars < size)
        return buffer;
      else if (nchars > -1)
        size = nchars + 1;
      else
        size *= 2;
-------------------------------------------------------------

The last else clause is blatantly wrong: if vsnprintf() returns a
negative value (according to the manpage, this occurs if there is an
output error), then this code will double the size and try to format it
again.  Since the problem is not caused by the buffer size, but by an
output error (which I suppose is caused by the presence of characters in
the output which for some reason is in the wrong encoding), doubling the
buffer size solves nothing at all. So it just loops until size is larger
than the amount of available RAM, and then the allocator calls abort()
and dies.

I'd like to confirm my analysis with an actual code fix, but I'm not
sure exactly what to do if vsnprintf() returns a negative value. The
only clean way I know of is to use wide-character formatting functions,
but it's non-trivial to do this with this code, and I'm not even sure if
ratpoison is setting the locale properly in the first place. Maybe when
I get more time I'll take another look at this.

In the meantime, I hope this info may help you find a fix.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>

Cc: 423141@bugs.debian.org, ratpoison-devel@nongnu.org

Subject: Re: Bug#423141: more questions about #423141

Date: Tue, 14 Aug 2007 10:34:39 +0200

I'm CCing ratpoison's mailinglist, so people there can look at this, too.
For those on the list: the history of this thread can be found at
http://bugs.debian.org/423141

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070814 06:13]:
> Now that I know where the bug is, I've managed to reproduce it with a
> debug build of ratpoison. Using gdb backtrace, I've located the
> problematic code: the xvsprintf() function in main.c. Towards the end of
> this function, there is this bit of code:
> 
> -------------------------------------------------------------
>       nchars = vsnprintf (buffer, size, fmt, ap_copy);
> #if defined(va_copy) || defined(__va_copy)
>       va_end (ap_copy);
> #endif
> 
>       if (nchars > -1 && nchars < size)
>         return buffer;
>       else if (nchars > -1)
>         size = nchars + 1;
>       else
>         size *= 2;
> -------------------------------------------------------------
> 
> The last else clause is blatantly wrong: if vsnprintf() returns a
> negative value (according to the manpage, this occurs if there is an
> output error), then this code will double the size and try to format it
> again.  Since the problem is not caused by the buffer size, but by an
> output error (which I suppose is caused by the presence of characters in
> the output which for some reason is in the wrong encoding), doubling the
> buffer size solves nothing at all. So it just loops until size is larger
> than the amount of available RAM, and then the allocator calls abort()
> and dies.

I'm guessing the reason for this is history (from vsprintf manpage):
| NOTES
|   The glibc implementation of the functions snprintf() and vsnprintf()
|   conforms to the C99 standard, i.e., behaves as described above, since
|   glibc version 2.1. Until glibc 2.0.6 they would return -1 when the output
|   was truncated.

> I'd like to confirm my analysis with an actual code fix, but I'm not
> sure exactly what to do if vsnprintf() returns a negative value. The
> only clean way I know of is to use wide-character formatting functions,
> but it's non-trivial to do this with this code, and I'm not even sure if
> ratpoison is setting the locale properly in the first place. Maybe when
> I get more time I'll take another look at this.

I guess there are three issues here:

1) I'd guess it is better to saveguard this and add some maximum number
   of characters to test for (at least with negative return values).
   This would help against other possible future problems causing -1
   returns.

2) It might be some problem with giving invalid utf-8 characters into
   this function. While searching for the reason of this bug I found
   some problems when both ratpoison and the clients use a UTF-8
   locale (though that causes only misdisplays for me).
   It's in cvs since July 19th. (I also though I uploaded a Debian
   package with a backport of that patch, but I seem to have forgotten
   it).

3) finally vsnprinf might indeed the wrong function for that. I've not
   yet looked into that. But looking at the manpage I'd guess that that
   should only generate displaying problems (as the number means bytes
   and not characters). I guess this needs someone knowing this issues
   to look into it.

> In the meantime, I hope this info may help you find a fix.

Thanks a lot for tracking this down.

Hochachtungsvoll,
	Bernhard R. Link

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

From: "Bernhard R. Link" <brlink@debian.org>

To: "H. S. Teoh" <hsteoh@quickfur.ath.cx>, 423141@bugs.debian.org

Subject: Re: Bug#423141: more questions about #423141

Date: Tue, 14 Aug 2007 20:40:47 +0200

package ratpoison
tags 423141 = pending
thanks

* H. S. Teoh <hsteoh@quickfur.ath.cx> [070814 06:13]:
> In the meantime, I hope this info may help you find a fix.

Thanks again for following up, now I can reproduce it and
the patch[1] to fix utf-8 window characters with ratpoison running
in utf-8 locale does indeed removed the provocaton for this bug.

(I'm still wondering why I was not able to reproduce it earlier.
Perhaps when I tried the exact same config with the exact same
version of the libraries and all possible locale settings, I must
have somehow mixed up something up. (Perhaps some filename for the
config was wrong when restarting in unicode locale, or I was just
too fixated on the font and forget to repeat to set the format when
testing in utf locale. Well, at least it is found...).)

I'll upload a new Debian package with that fix and something against
other causes to make sprintf fail soon.

Hochachtungsvoll,
	Bernhard R. Link

[1] http://lists.nongnu.org/archive/html/ratpoison-devel/2007-07/txtmZVayY63PB.txt

Message #122 received at 423141-close@bugs.debian.org (full text, mbox, reply):

From: brlink@debian.org (Bernhard R. Link)

To: 423141-close@bugs.debian.org

Subject: Bug#423141: fixed in ratpoison 1.4.1-5

Date: Wed, 15 Aug 2007 15:17:10 +0000

Source: ratpoison
Source-Version: 1.4.1-5

We believe that the bug you reported is fixed in the latest version of
ratpoison, which is due to be installed in the Debian FTP archive:

ratpoison_1.4.1-5.diff.gz
  to pool/main/r/ratpoison/ratpoison_1.4.1-5.diff.gz
ratpoison_1.4.1-5.dsc
  to pool/main/r/ratpoison/ratpoison_1.4.1-5.dsc
ratpoison_1.4.1-5_sparc.deb
  to pool/main/r/ratpoison/ratpoison_1.4.1-5_sparc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 423141@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard R. Link <brlink@debian.org> (supplier of updated ratpoison package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 15 Aug 2007 12:24:28 +0200
Source: ratpoison
Binary: ratpoison
Architecture: source sparc
Version: 1.4.1-5
Distribution: unstable
Urgency: low
Maintainer: Bernhard R. Link <brlink@debian.org>
Changed-By: Bernhard R. Link <brlink@debian.org>
Description: 
 ratpoison  - keyboard-only window manager
Closes: 423141 438063
Changes: 
 ratpoison (1.4.1-5) unstable; urgency=low
 .
   * backport of some patches to 1.4.1:
   - nodoubleclassreading.diff: reduce X server communication a bit
   - noabortonconverterror.diff: don't abort (by requesting infinite
     amount of memory) if there is an string truncation error. (Closes: 423141)
   - utf8locale.diff: also handle utf8 window titles correctly if ratpoison
     itself is running in utf8 locale. (Closes: 438063)
   * adopt to new menu layout
Files: 
 ec23ff07db7f316ab5134246bde56c97 671 x11 extra ratpoison_1.4.1-5.dsc
 4eb7738cdff5c4d7bc050a014da36043 47050 x11 extra ratpoison_1.4.1-5.diff.gz
 764973a493199ab8e3e4648c86008d84 174866 x11 extra ratpoison_1.4.1-5_sparc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGwxYcTrAWvKplQe4RAo89AJoCj3An73JS0KDBDa70BnIjfTTWuwCeK1Sq
5FRVzkJ+Pz1NHgqjnoJzrBI=
=wfft
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.