bugzilla-daemon at main.slony.info bugzilla-daemon at main.slony.info
Wed Aug 22 15:36:11 PDT 2012
http://www.slony.info/bugzilla/show_bug.cgi?id=275

Christopher Browne <cbbrowne at ca.afilias.info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Christopher Browne <cbbrowne at ca.afilias.info> 2012-08-22 15:36:11 PDT ---
The change looks to be working OK, which is good, and the notion that we
weren't freeing allocated objects in all cases would certainly be a cause for
this.

Ulrich, I'd be very interested to see the output of Valgrind that you got for
this.

What I got as output was pretty limited, and didn't point particularly at the
monitoring thread.  Here's the sort of thing that I saw:

==24108== 
==24108== HEAP SUMMARY:
==24108==     in use at exit: 25,201 bytes in 18 blocks
==24108==   total heap usage: 116 allocs, 98 frees, 119,324 bytes allocated
==24108== 
==24108== 5 bytes in 1 blocks are definitely lost in loss record 1 of 9
==24108==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==24108==    by 0x52F3911: strdup (strdup.c:43)
==24108==    by 0x416A20: set_config_option (confoptions.c:946)
==24108==    by 0x404E44: main (slon.c:182)
==24108== 
==24108== 45 bytes in 4 blocks are definitely lost in loss record 4 of 9
==24108==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==24108==    by 0x52F3911: strdup (strdup.c:43)
==24108==    by 0x416CC0: InitializeConfOptions (confoptions.c:611)
==24108==    by 0x404E44: main (slon.c:182)
==24108== 
==24108== LEAK SUMMARY:
==24108==    definitely lost: 50 bytes in 5 blocks
==24108==    indirectly lost: 0 bytes in 0 blocks
==24108==      possibly lost: 0 bytes in 0 blocks
==24108==    still reachable: 25,151 bytes in 13 blocks
==24108==         suppressed: 0 bytes in 0 blocks
==24108== Reachable blocks (those to which a pointer was found) are not shown.
==24108== To see them, rerun with: --leak-check=full --show-reachable=yes
==24108== 
==24108== For counts of detected and suppressed errors, rerun with: -v
==24108== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
==24443== Memcheck, a memory error detector
==24443== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24443== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24443== Command: /var/lib/postgresql/dbs/postgresql-9.1/bin/slon -f
/tmp/slony-regress.anaU4j/slon-conf.1
==24443== 

I'm not at all objecting to the patch, which seems pretty reasonable.  But if
we can get a little more documentation here, it's conceivable we could come up
with a test that we ought to run periodically to verify that we haven't got
leaks.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the Slony1-bugs mailing list