From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3d5d84f983b9566c6c007392f3c55ed4@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 21 May 2009 12:06:31 -0400
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] aux/acidleak pool pathology
Topicbox-Message-UUID: fbfa9294-ead4-11e9-9d60-3106f5b1d025

without getting to deep in the details of the pool
library, the reallocation loop aux/acidleak sends
realloc off the deep end.

here's an example; i've added an abort so i can see
how big acidleak is getting

	rb2; ps -a | grep xyz
	xyz           15104    0:29   0:02    45132K Pread    fs [upas/fs -np]
	rb2; leak 15104
	aux/acidleak: realloc 12280320 fails
	acidleak 25325: suicide: sys: trap: fault read addr=0x0 pc=0x00004a14
	rb2; ps -a | grep leak
	xyz           25325    0:02   0:03  2022876K Broken   aux/acidleak
	xyz           25328    0:00   0:00      156K Pread    grep leak

obviously the Brdline loop in main is reallocating data and block
so they don't fit in their previous buckets and pool sbrk's more
memory.  it would seem that pool is missing the fact that
at some point the old, now-empty blocks are big enough
when merged.  however  libc/port/pool.c:/^poolreallocl
appears to have the proper logic.

- erik