Re: [Help-smalltalk] Strategy to finding memleaks

[Holger Hans Peter Freyther]

On 04/09/2011 08:15 PM, Paolo Bonzini wrote:

> Leaks in C code should be "obvious" by comparing ObjectMemory values
> with those from top(1).
> 
> Also they wouldn't be fixed by Smalltalk GC. :)
> 
> Memory fragmentation can be fixed by "ObjectMemory compact" without a
> previous  GC.

I will keep digging but to rule out Postgres memory leaks I was creating a
minimal stub and changed the libname in the package.xml.


gcc -shared -o libzpq.so
void *PQconnectdb()
{
        return 24;
}

void *PQexec()
{
        return 23;
}

void PQclear()
{
        return;
}

int PQstatus()
{
        return 0;
}

int PQresultStatus()
{
        return 2;
}

the Smalltalk code is this:

top := DBI.Connection
         connect: 'dbi:PostgreSQL:dbname=w;hostname=b'
         user: 'd' password: 'c'.

m := 0.
1 to: 10000000 do: [:each |
     (top select: 'SELECT * FROM topups') release.

        (each \\ 100) = 0 ifTrue: [
                | inst |
                inst := DBI.PostgreSQL.PGResultSet allInstances size.
                inst >= m ifTrue: [m := inst. inst printNl]]
]


so somehow if I call release on the ResultSet it is removing itself from the
finalizer list and the objects are GCed faster. Do you remember the reason why
a new process is started to finalize objects instead of doing it within the
process that waits for the Semaphore?