[torqueusers] hunting for memory leaks (1.2.0p6)

Garrick Staples garrick at usc.edu
Mon Sep 26 13:46:12 MDT 2005


On Tue, Sep 20, 2005 at 03:24:07PM -0400, Wolfgang Wander alleged:
> ----------------------------------------------------------------------
> Furtheremore in svr_recov.c this leak here seems intentional, or is
> it?
> ----------------------------------------------------------------------
>   if (pdef->at_decode(&tempat,pdef->at_name,NULL,buf) < 0)
>     {
>     sprintf(log_buffer,"decode of acl %s failed",
>       pdef->at_name);
> 
>     log_err(errno,"recov_acl",log_buffer);
>     }
>   else if (pdef->at_set(pattr,&tempat,SET) != 0)
>     {
>     sprintf(log_buffer,"set of acl %s failed",
>       pdef->at_name);
> 
>     log_err(errno,"recov_acl",log_buffer);
>     }
> 
>   pdef->at_free(&tempat); /* at_free is set to free_noop and leave
>                              attributes dangling? wwc */

The idea is to prevent 'unset server managers' from working and locking
you out.  You can see that a few other server attributes also use
free_noop() in svr_attr_def.c.

Yes, this is a memory leak, but it only happens once at startup.  It
would be cleaner to change managers' at_action back to free_arst() but
the protection of free_noop() is a real benefit.

The long-term solution is to have default, min, and max values in
'struct attribute_def'.

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torqueusers/attachments/20050926/ccfdfc34/attachment.bin


More information about the torqueusers mailing list