[PVFS2-developers] 1: small mem/bug fix
Walter B. Ligon III
walt at clemson.edu
Wed Jun 8 18:34:50 EDT 2005
> Robert Latham wrote:
> > On Fri, May 27, 2005 at 05:12:05AM -0400, Beilloin, David wrote:
> >>1°) small mem leak in src/client/sysint/client-state-machine.c
> >>details: the first call to PINT_client_state_machine_post create a
> >>job context through CLIENT_SM_INIT_ONCE but at this level we don't
> >>know when to free this context
> >>in src/client/sysint/initialize a PVFS_sys_job_context is allocated
> >>and freed in src/client/sysint/finalize. as it is not use anywhere,
> >>I supposed that it was aimed for this ??
> >>solution : just make pint_client_sm_context point to PVFS_sys_job_context
> > I don't think I understand your proposed solution very well. Not
> > saying it's wrong, just that it's dealing with code I'm not terribly
> > familiar with. Can anybody tell me more about the intended use of
> > PVFS_sys_job_context and pint_client_sm_context, and if David's
> > suggestion to just have pint_client_sm_context point to
> > PVFS_sys_job_context makes sense?
> From my interpretation of the code, I think that David is right. They
> were both probably meant to serve the same purpose- to be the general
> purpose context that all of the client side jobs get posted to.
> PVFS_sys_job_context just isn't used anymore. From a code
> beautification point of view it might be better to completely get rid of
> one variable or the other rather than assigning the two to be equal, but
> either way has the same effect in the end as long as the context is
> opened during initialize and closed during finalize.
> Good catch- those variables are confusing!
Yeah, I'm slogging through the client right now.
If they were meant to be the same let's definitely get rid of one,
leaving around a shadow that points the other leaves the potential for
futher confusion. The final name chosen should be a PINT variant as it
is certainly an internal variable.
More information about the PVFS2-developers