Thanks for explaining that. So, if we had just freed the op but not unregistered it, there still would have been a memory leak?
Becky -- Becky Ligon HPC Admin Staff PVFS/OrangeFS Developer Clemson University/Omnibond.com OrangeFS Support 864-650-4065 > On 07/08/2011 09:16 AM, Becky Ligon wrote: >> Good point, Phil. >> >> Before Sam's bug fix, the free(op-entry) was in the complete-op >> function. >> However, he didn't have the unregister() and I don't know why. So, >> maybe, >> putting the unregister() and free() outside of complete-op() IS the >> better >> way to handle it. It seems that there never was an unregister() and I'm >> wondering if that could have been causing problems as well, i.e., one >> reason why the bug fix was needed in the first place. >> >> Becky > > There were two related issues here. The first was switching from > fast_register to safe_register, which if I understand correctly was done > to prevent a possible segfault if someone tried to access an operation > id that had already been completed. (the fast one is "fast" rather than > "safe" because it does no error checking and will map whatever ID you > give it to a pointer in memory whether it is valid or not; you can only > use it when you are confident about how the IDs will be used by > callers). There is another difference between those two ID generators, > though: the fast_register doesn't technically need matching unregister > calls because the fast_unregister is a noop, but safe_register _does_ > require matching unregister calls to free some book keeping data > structures. That's why those unregisters were added as part of that > change. In the original code it would have been better to use the > unregister calls just for symmetry, but it wasn't hurting anything to > leave them out. > > -Phil > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
