|
From: | Holger Hans Peter Freyther |
Subject: | Re: [Help-smalltalk] Strategy to finding memleaks |
Date: | Sat, 09 Apr 2011 21:29:11 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.9 |
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?
[Prev in Thread] | Current Thread | [Next in Thread] |