"out of memory" error messages from the server

[Mark D. Baushke]

Hi Folks,

It seems that the server has problems communicating that it is
unable to allocate bytes... any suggestions on how this error
should be handled cleanly?

        -- Mark

Core was generated by `cvs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x28166c6d in vfprintf () from /usr/lib/libc.so.4
(gdb) bt
#0  0x28166c6d in vfprintf () from /usr/lib/libc.so.4
#1  0x28159971 in sprintf () from /usr/lib/libc.so.4
#2  0x8088480 in xmalloc (bytes=256) at subr.c:45
#3  0x804d1a4 in allocate_buffer_datas () at buffer.c:108
#4  0x804d1fc in get_buffer_data () at buffer.c:130
#5  0x804d2bd in buf_output (buf=0x80cf100, data=0xbfbffbf4 "cvs", len=3)
    at buffer.c:196
#6  0x8087a25 in cvs_outerr (str=0xbfbffbf4 "cvs", len=0) at server.c:6447
#7  0x805e133 in error (status=1, errnum=0, 
    message=0xbec003e8 "out of memory; can not allocate 256 bytes")
    at error.c:130
#8  0x808848d in xmalloc (bytes=256) at subr.c:47
#9  0x804d1a4 in allocate_buffer_datas () at buffer.c:108
#10 0x804d1fc in get_buffer_data () at buffer.c:130
#11 0x804d2bd in buf_output (buf=0x80cf100, data=0xbfbffbf4 "cvs", len=3)
    at buffer.c:196
#12 0x8087a25 in cvs_outerr (str=0xbfbffbf4 "cvs", len=0) at server.c:6447
#13 0x805e133 in error (status=1, errnum=0, 
    message=0xbec005a8 "out of memory; can not allocate 256 bytes")
    at error.c:130
#14 0x808848d in xmalloc (bytes=256) at subr.c:47
#15 0x804d1a4 in allocate_buffer_datas () at buffer.c:108
#16 0x804d1fc in get_buffer_data () at buffer.c:130
#17 0x804d2bd in buf_output (buf=0x80cf100, data=0xbfbffbf4 "cvs", len=3)
    at buffer.c:196
#18 0x8087a25 in cvs_outerr (str=0xbfbffbf4 "cvs", len=0) at server.c:6447
#19 0x805e133 in error (status=1, errnum=0, 
    message=0xbec00768 "out of memory; can not allocate 256 bytes")
    at error.c:130
[... and so on for a very large number of stack frames ...]