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.
