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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
