Bug in backend/lib/stringinfo.c:enlargeStringInfo()

Hi,

for some time a postgres process on one of our web servers repeatedly 
gets into an infinite loop. This happens very rarely, about once in a 
week. Today I installed gdb on the server to trace down the problem.

I found out that the process was looping in enlargeStringInfo() in 
backend/lib/stringinfo.c. The call trace was

#0  0x0810e490 in enlargeStringInfo ()
#1  0x081138e4 in pq_getmessage ()
#2  0x0816561b in SocketBackend ()
#3  0x081657bb in ReadCommand ()
#4  0x08167a5e in PostgresMain ()
#5  0x08144353 in BackendFork ()
#6  0x08143d33 in BackendStartup ()
#7  0x08142516 in ServerLoop ()
#8  0x08142057 in PostmasterMain ()
#9  0x08114a4d in main ()
#10 0x400e8857 in __libc_start_main () from /lib/libc.so.6

The "needed" argument to enlargeStringInfo was 0x5454502b, apparently 
caused by another bug, which I have yet to find.

So the following loop never stops

	while (needed > newlen)
		newlen = 2 * newlen;

because needed and newlen are compared as signed integers. (If "newlen" 
has grown to 0x40000000 it's still smaller than "needed". Multiplying by 
2 overflows and yields 0x80000000, which is negative, thus still smaller 
than "needed". Multiplying by 2 again yields 0, ...)

The numbers should be compared as unsigned ints. Or the maximum string 
length should be restricted.

On the other hand I wonder if it's desired to even try the following 
memory allocation of at least a GB of RAM. The pq_getmessage() that 
called enlargeStringInfo() has a "maxlen" argument of 0, that seems to 
mean unlimited.

The real cause of the problem seems to be a frontend/backend 
communication problem. The "needed" argument 0x5454502b comes from a 
4-byte length field which string content is 'TTP/'. Looks like a part of 
a HTTP request to me.

I'm using Apache/mod_perl/DBI to access Postgres. Can I log the 
frontend/backend communication somehow?

Nick Wellnhofer



-- 
aevum gmbh
leopoldstr. 87
80802 münchen
germany

fon: +4989 38380653
fax: +4989 38799384
wellnhofer@aevum.de
http://aevum.de/