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?
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
