You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "rupert.thurner" <ru...@gmail.com> on 2011/07/17 07:56:27 UTC
python bindings leak memory (Re: 1.7.0-beta1 up for testing)
On Jul 13, 10:29 pm, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> There aren't any known release-blocking issues, but this is still a
> beta release. As you may expect, these prereleases are intended for
> intrepid users and testers only. Aside from the aforementioned
> revision number issue, the new release scripts appear to be behaving
> themselves, though any reports to the contrary would be of great
> interest.
>
> I'd like to get a complete set of 3 *nix and 3 Windows signatures for
> this release. Barring any catastrophes, this will be the only beta,
> and we'll start the RC train in a week or two.
>
> Please send sigs here:http://work.hyrumwright.org/pub/svn/collect_sigs.py
it seems that the python bindings leak memory, and there seems no test
covering this?
rupert.
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
>
> > "rupert.thurner" <ru...@gmail.com> writes:
> > > it seems that the python bindings leak memory, and there seems no test
> > > covering this?
>
> > It's possible. Please provide more details.
>
> the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> tried to do is:
> python svnmem.py
> valgrind python svnmem.py
i am not really sure how to debug this correctly. using valgrind for
mercurials hgsubversion, also using log and replay, it ends up with
500 MB of allocated memory after retrieving 5000 revisions:
$ valgrind --track-origins=yes hg clone svn://gcc.gnu.org/svn/gcc
....
[r5381] rms: [CROSS_COMPILE]: Include mips/a.out.h.
[r5382] rms: (ENQUIRE, CROSS_TEST): New variables.
[r5383] rms: (L_bb): Test inhibit_libc.
[r5384] rms: Comment change.
[r5385] rms: (INIT_CUMULATIVE_ARGS): Pass just the return value type
to aggregate_value_p.
[r5386] bson: Initial revision
[r5387] bson: added declaration for `trampoline' bytecode segment.
^Cpulled 5385 revisions
updating to branch default
557 files updated, 0 files merged, 0 files removed, 0 files
unresolved
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x80CEF97: ??? (in /usr/bin/python2.7)
==15203== by 0x80BE3C5: PyDict_Clear (in /usr/bin/python2.7)
==15203== by 0x80BE3E0: ??? (in /usr/bin/python2.7)
==15203== by 0x80F2833: ??? (in /usr/bin/python2.7)
==15203== by 0x8074B53: PyGC_Collect (in /usr/bin/python2.7)
==15203== by 0x8070F49: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Address 0x51f7010 is 1,392 bytes inside a block of size
1,536 free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x80BE3E0: ??? (in /usr/bin/python2.7)
==15203== by 0x80F2833: ??? (in /usr/bin/python2.7)
==15203== by 0x8074B53: PyGC_Collect (in /usr/bin/python2.7)
==15203== by 0x8070F49: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81395BA: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Address 0x44ce010 is not stack'd, malloc'd or (recently)
free'd
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== Address 0x51f9010 is 320 bytes inside a block of size 352
free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x42919C9: fclose@@GLIBC_2.1 (iofclose.c:88)
==15203== by 0x80A7544: ??? (in /usr/bin/python2.7)
==15203== by 0x810D8CA: ??? (in /usr/bin/python2.7)
==15203== by 0x81048B0: ??? (in /usr/bin/python2.7)
==15203== by 0x80E1207: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==15203== by 0x8105A60: ??? (in /usr/bin/python2.7)
==15203== by 0x80A4649: PyObject_Call (in /usr/bin/python2.7)
==15203== by 0x80A603E: ??? (in /usr/bin/python2.7)
==15203== by 0x80A4649: PyObject_Call (in /usr/bin/python2.7)
==15203== by 0x80DAD42: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==15203== by 0x80E11E6: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==15203==
==15203== Conditional jump or move depends on uninitialised value(s)
==15203== at 0x80C131F: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Uninitialised value was created by a heap allocation
==15203== at 0x4026864: malloc (vg_replace_malloc.c:236)
==15203== by 0x80C11C8: PyObject_Malloc (in /usr/bin/python2.7)
==15203== by 0x80C5817: PyString_FromStringAndSize (in /usr/bin/
python2.7)
==15203== by 0x80E7C00: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D93: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x813ADB7: PyMarshal_ReadObjectFromString (in /usr/
bin/
python2.7)
==15203== by 0x813AE84: PyMarshal_ReadLastObjectFromFile (in /usr/
bin/python2.7)
==15203== by 0x8138C14: ??? (in /usr/bin/python2.7)
==15203==
==15203== Use of uninitialised value of size 4
==15203== at 0x80C132C: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Uninitialised value was created by a heap allocation
==15203== at 0x4026864: malloc (vg_replace_malloc.c:236)
==15203== by 0x80C11C8: PyObject_Malloc (in /usr/bin/python2.7)
==15203== by 0x80C5817: PyString_FromStringAndSize (in /usr/bin/
python2.7)
==15203== by 0x80E7C00: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D93: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x813ADB7: PyMarshal_ReadObjectFromString (in /usr/
bin/
python2.7)
==15203== by 0x813AE84: PyMarshal_ReadLastObjectFromFile (in /usr/
bin/python2.7)
==15203== by 0x8138C14: ??? (in /usr/bin/python2.7)
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8160CA6: PyGrammar_RemoveAccelerators (in /usr/bin/
python2.7)
==15203== by 0x8070FC1: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203== Address 0x4929010 is 32 bytes inside a block of size 668
free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x8160CA6: PyGrammar_RemoveAccelerators (in /usr/bin/
python2.7)
==15203== by 0x8070FC1: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203==
==15203==
==15203== HEAP SUMMARY:
==15203== in use at exit: 522,966,454 bytes in 10,803 blocks
==15203== total heap usage: 14,067,230 allocs, 14,056,427 frees,
59,559,225,904 bytes allocated
==15203==
==15203== LEAK SUMMARY:
==15203== definitely lost: 168 bytes in 7 blocks
==15203== indirectly lost: 0 bytes in 0 blocks
==15203== possibly lost: 158,392 bytes in 435 blocks
==15203== still reachable: 522,807,894 bytes in 10,361 blocks
==15203== suppressed: 0 bytes in 0 blocks
==15203== Rerun with --leak-check=full to see details of leaked
memory
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> On Jul 17, 10:16 pm, Philip Martin <ph...@wandisco.com> wrote:
>> "rupert.thurner" <ru...@gmail.com> writes:
>> > now it works ... and running it for 100'000 revisions slowly increases
>> > #!/usr/bin/python
>>
>> > import svn.client
>> > import svn.core
>> > import svn.ra
>>
>> > pool = svn.core.Pool()
>> > client = svn.client.create_context(pool)
>> > client.config = svn.core.svn_config_get_config(None)
>> > client.auth_baton =
>> > svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>>
>> > ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
>> > pool)
>> > def rcvr(orig_paths, rev, author, date, message, pool):
>> > if orig_paths is not None:
>> > for x in orig_paths:
>> > orig_paths[x]._parent_pool.destroy()
>>
>> Destroying pools like that was a workaround for a bug that has been
>> fixed. It's only safe if nothing uses, or explictily destroys, the
>> pool.
>
> how are the pools correctly destroyed?
According to the issue 3052 it was fixed by r868618:
r868618 | djames | 2007-12-19 01:10:36 +0000 (Wed, 19 Dec 2007) | 11 lines
Fix a major memory leak in the Python object duplication code.
> i tried to use the subversion
> test cases to find a small example for replay, but it seems to be not
> tested at all? is there some documentation you could point to which
> shows how to use replay correctly?
The bindings test coverage is limited, it would help if more tests were
written. The best I can suggest is the C API and the svnsync usage:
http://subversion.apache.org/docs/api/latest/svn__ra_8h.html
http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/main.c
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 10:16 pm, Philip Martin <ph...@wandisco.com> wrote:
> "rupert.thurner" <ru...@gmail.com> writes:
> > now it works ... and running it for 100'000 revisions slowly increases
> > #!/usr/bin/python
>
> > import svn.client
> > import svn.core
> > import svn.ra
>
> > pool = svn.core.Pool()
> > client = svn.client.create_context(pool)
> > client.config = svn.core.svn_config_get_config(None)
> > client.auth_baton =
> > svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> > ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> > pool)
> > def rcvr(orig_paths, rev, author, date, message, pool):
> > if orig_paths is not None:
> > for x in orig_paths:
> > orig_paths[x]._parent_pool.destroy()
>
> Destroying pools like that was a workaround for a bug that has been
> fixed. It's only safe if nothing uses, or explictily destroys, the
> pool.
how are the pools correctly destroyed? i tried to use the subversion
test cases to find a small example for replay, but it seems to be not
tested at all? is there some documentation you could point to which
shows how to use replay correctly?
rupert
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> now it works ... and running it for 100'000 revisions slowly increases
> the memory. but the main problem seems to be replay. you have an
> example? i did not find anything in the test subversion testcases.
I don't understand: are you saying there is a problem in replay? How do
you know if you don't have an example? Are you using some other program?
> #!/usr/bin/python
>
> import svn.client
> import svn.core
> import svn.ra
>
> pool = svn.core.Pool()
> client = svn.client.create_context(pool)
> client.config = svn.core.svn_config_get_config(None)
> client.auth_baton =
> svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> pool)
> def rcvr(orig_paths, rev, author, date, message, pool):
> if orig_paths is not None:
> for x in orig_paths:
> orig_paths[x]._parent_pool.destroy()
Destroying pools like that was a workaround for a bug that has been
fixed. It's only safe if nothing uses, or explictily destroys, the
pool.
> print rev
> svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Does it occur over neon, serf, or both?
rupert.thurner wrote on Sun, Jul 17, 2011 at 12:55:53 -0700:
> On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> > On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
> >
> > > "rupert.thurner" <ru...@gmail.com> writes:
> > > > it seems that the python bindings leak memory, and there seems no test
> > > > covering this?
> >
> > > It's possible. Please provide more details.
> >
> > the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> > tried to do is:
> > python svnmem.py
> > valgrind python svnmem.py
> >
> > for a start, i tried to run the test case fromhttp://subversion.tigris.org/issues/show_bug.cgi?id=3052with
> > svn-1.6.12, but it produces a segmentation fault here. see below for
> > the script.
> now it works ... and running it for 100'000 revisions slowly increases
> the memory. but the main problem seems to be replay. you have an
> example? i did not find anything in the test subversion testcases.
>
>
> #!/usr/bin/python
>
> import svn.client
> import svn.core
> import svn.ra
>
> pool = svn.core.Pool()
> client = svn.client.create_context(pool)
> client.config = svn.core.svn_config_get_config(None)
> client.auth_baton =
> svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> pool)
> def rcvr(orig_paths, rev, author, date, message, pool):
> if orig_paths is not None:
> for x in orig_paths:
> orig_paths[x]._parent_pool.destroy()
> print rev
> svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
>
> client = svn.client.create_context(pool)
>
>
>
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
>
> > "rupert.thurner" <ru...@gmail.com> writes:
> > > it seems that the python bindings leak memory, and there seems no test
> > > covering this?
>
> > It's possible. Please provide more details.
>
> the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> tried to do is:
> python svnmem.py
> valgrind python svnmem.py
>
> for a start, i tried to run the test case fromhttp://subversion.tigris.org/issues/show_bug.cgi?id=3052with
> svn-1.6.12, but it produces a segmentation fault here. see below for
> the script.
now it works ... and running it for 100'000 revisions slowly increases
the memory. but the main problem seems to be replay. you have an
example? i did not find anything in the test subversion testcases.
#!/usr/bin/python
import svn.client
import svn.core
import svn.ra
pool = svn.core.Pool()
client = svn.client.create_context(pool)
client.config = svn.core.svn_config_get_config(None)
client.auth_baton =
svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
pool)
def rcvr(orig_paths, rev, author, date, message, pool):
if orig_paths is not None:
for x in orig_paths:
orig_paths[x]._parent_pool.destroy()
print rev
svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
client = svn.client.create_context(pool)
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
> "rupert.thurner" <ru...@gmail.com> writes:
> > it seems that the python bindings leak memory, and there seems no test
> > covering this?
>
> It's possible. Please provide more details.
the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
tried to do is:
python svnmem.py
valgrind python svnmem.py
for a start, i tried to run the test case from
http://subversion.tigris.org/issues/show_bug.cgi?id=3052 with
svn-1.6.12, but it produces a segmentation fault here. see below for
the script.
#!/usr/bin/python
import svn.client
import svn.core
import svn.ra
pool = svn.core.Pool()
client = svn.client.create_context()
ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client)
def rcvr(orig_paths, rev, author, date, message, pool):
if orig_paths is not None:
for x in orig_paths:
orig_paths[x]._parent_pool.destroy()
print rev
svn.ra.get_log(ra, [""], 0, 700000, 0, True, False, rcvr)
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> it seems that the python bindings leak memory, and there seems no test
> covering this?
It's possible. Please provide more details.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com