Understand. Thanks!
Becky
--
Becky Ligon
HPC Admin Staff
PVFS/OrangeFS Developer
Clemson University/Omnibond.com OrangeFS Support
864-650-4065
> On 07/08/2011 09:44 AM, Becky Ligon wrote:
>> Thanks for explaining that. So, if we had just freed the op but not
>> unregistered it, there still wou
On 07/08/2011 09:44 AM, Becky Ligon wrote:
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
With the safe_register functions, yes. With the fast_register
functions, no.
-Phil
___
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:
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 hand
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 unr
That may be. The thing that is a little tricky is that technically the
mgmt code can be run in a handful of different modes (thread pool,
thread per op, polling etc.) and we weren't entirely sure if one of the
other modes would need the entry to survive longer than the
complete_op() function o
Yes. I agree. That's exactly what I had found, too, but I think that code
belongs inside of the PINT_manager_complete_op function. Thoughts?
Becky
On Thu, Jul 7, 2011 at 5:06 PM, Benjamin Severs wrote:
> Thanks to some direction by Phil Carns, we've managed to correct the memory
> leak that w
Thanks to some direction by Phil Carns, we've managed to correct the memory
leak that was affecting directio operations. Below is the patch that addresses
the issue. The problem was that once all the *fast* calls were switched to
*safe* calls, the proper cleanup routines were never being calle
