Hey Stefan,
On IRC, you asked:
[6:26pm] stsp: question for when you come back from dinner: in
ra_serf, log.c, end_log() -- the log reciever gets info->pool, which
is the same pool the xml parser state uses
[6:27pm] stsp: i wonder if the receiver should be passed a proper
scratch_pool instead
[6:27pm] stsp: maybe even make info->pool a subpool of
parser->state->pool and destroy it at the end of end_log() (assuming
the life cycle of the info ends there?)
I honestly don't have an answer. The pool usage in there is pretty
crazy. Before starting on this recent memory-usage bug, I spent a bit
of time cleaning up some pools, but it really needs a lot more. The
hierarchy of pools is really difficult, especially in the presence of
an editor. I tweaked svn_delta_editor_t docstrings a while ago to try
and clear up the usage of each pool, but Ev1 is scary. I'm going to be
happy to move to Ev2 simply to get better clarity on pool
usage/lifetimes (ie. remove file/dir batons).
I have been working in update.c and util.c, and haven't applied
eyeballs to log.c. It certainly sounds like the log receiver should
get a scratch_pool from somewhere rather than sharing the XML pool.
(verified the receiver type in svn_types.h, and that is definitely a
scratch_pool)
Regarding info->pool... dunno. Again, the pool lifetimes in ra_serf
are just not clear. A lot of the invocations/callbacks are not making
it easy (my work referenced above was simply to unwind the levels of
callback-ness)
Cheers,
-g
Received on 2011-07-20 01:46:13 CEST