Re: --enable-thread-safety bug
От | Steve Clark |
---|---|
Тема | Re: --enable-thread-safety bug |
Дата | |
Msg-id | 47E69388.5070503@netwolves.com обсуждение исходный текст |
Ответ на | Re: --enable-thread-safety bug (Michael Meskes <meskes@postgresql.org>) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: