[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 17 Jul 2011 23:17:58 +0300

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" <rupert.thur..._at_gmail.com> wrote:
> > On Jul 17, 9:54 am, Philip Martin <philip.mar..._at_wandisco.com> wrote:
> >
> > > "rupert.thurner" <rupert.thur..._at_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)
>
>
>
Received on 2011-07-17 22:18:47 CEST

This is an archived mail posted to the Subversion Dev mailing list.