Michael Meskes wrote:
On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote:
Not exactly sure what you are asking about - descriptors and auto
allocating.
So I guess you don't use either feature. :-)
The program processes about 800000 packets a day, which can update
several tables.
It runs continously reading udp packets from systems at remote locations
coming in over the internet.
But the code for processing all thoss statements is the same, with and
without threading enabled.
One code that differs is allocation of sqlca, but given that this
structure has a mere 215 bytes (about). Even if it was allocated 800000
times it would make up for a memory loss of about 164MB. Which brings up
the question how long the application runs until it segfaults.
As Tom already pointed out, without more information there simply is no
way for us to find out what's going on. We are more than willing to dig
into it, but we need more to be able to.
Michael
Ok I tryed valgrind and after a while it dies with a valgrind
assertion error before providing any
useful data.
So I tried linking with -lc_r and it appears to have stopped the leak.
Without -lc_r
using "top" my app quickly climbed over 150mbyte in memory size - it
is now staying steady
at about 8mb - which is about what it ran when I compiled the ecpg lib
without --enable-thread-safety
enabled.
Now why does this make a difference in ecpg?
HTH,
Steve
If anyone cares below is the valgrind assertion failure:
valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb
!= ((void*)0)' failed.
==4166== at 0xB802BE1F: (within /usr/local/lib/valgrind/stage2)
==4166== by 0xB802BE1E: (within /usr/local/lib/valgrind/stage2)
==4166== by 0xB802BE5D: vgPlain_core_assert_fail (in
/usr/local/lib/valgrind/stage2)
==4166== by 0xB8028091: vgPlain_arena_malloc (in
/usr/local/lib/valgrind/stage2)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==4166== at 0x3C03894B: calloc (in
/usr/local/lib/valgrind/vgpreload_memcheck.so)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: valgrind.kde.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
-
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
