On Wed, 05 Aug 2009 12:10:11 +0100 Alan Maguire <Alan.Maguire at Sun.COM> wrote:
> ...and it'd help if I provided a pointer to the webrev ;-) > > http://zhadum.east.sun.com/export/ws/amaguire/nwam1-fixes/webrev/ door_if.c:155 There should be a log here that we truncated the list. In the rare event it happens it will be a lot easier to diagnose that way. libnwam_backend.c:358 This should be at the top of the file. libnwam_files.c:456-7 objnames is only calloc()d if objname is NULL, yet you free it without a guard? There are several more examples of this close by. libnwam_files.c:482 You don't free objnames[i] on error exit eventhough it contains references to allocated memory. libnwam_files.c:528-540 The chunk of code that frees the list and sets the return value is in several different exit paths. Consider moving this to the end, setting state variables, and jumping to it. libnwam_known_wlan.c:173 This leaks memory if the first allocation succeeds but the second doesn't. libnwam_known_wlan.c:182 how do you know num_wlan is not 0? libnwam_known_wlan.c:215-221 This chunk of exit code is duplicated. Consider moving it to a common exit path. Michael > > Alan > > Alan Maguire wrote: > > hi folks > > > > I'm requesting code review for > > > > http://defect.opensolaris.org/bz/show_bug.cgi?id=10245 > > > > Background - the doors interactions in libnwam were > > broken. On the door server side, we were sometimes > > alloca()ing a return argument, rather than having a client > > pass in a maximally-sized buffer. In the course of fixing this > > I've addressed another architectural issue relating > > to the libnwam backend - namely that when we call > > any of the walk() functions for nwam objects, the > > walk was carried out by passing back an nvlist of nvlists, > > where each nvlist was a property list for each object. > > This obviously is problematic as the number of objects > > grows. This approach has been amended to passing > > back an nvlist containing a list of object names, each > > of which is read() individually. This increases the door > > traffic for walks, but with the performance improvements > > that accrue from moving away from dynamic allocation, > > the effects aren't apparent to the user. > > > > After all this I'm still seeing memory leaks in netcfgd unfortunately, > > and these leaks are missing caller information, so ::bufctl_audit > > doesn't shed any light on the origin. > > > > I'm also seeing a 24-byte memory leak in nwamcfg which > > only happens when we "list" all objects (doesn't happen > > for listing NCUs only for example). > > > > Any help in tracking down those leaks would be greatly > > appreciated, and if any additional background is required > > to make sense of these changes, don't hesitate to ask. > > Thanks! > > > > Alan > > _______________________________________________ > > nwam-dev mailing list > > nwam-dev at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/nwam-dev > > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
