I was thinking that perhaps the issue was that I keep the ibis::part and ibis::table pointers around through the life of the application. However, I just experimented with deleting these at some point after a query, but I still see memory leaks reported for array_t.
It's possible that these memory leaks could be false positives reported by the memory profiling tool, but it's too early to say so far. I'm continuing to simplify my test scenario to see if I can pinpoint something on my side. It might also help for you to have some idea of what the memory profiler is doing in case that might trigger an idea for you. Here is a stack overflow answer that sheds some light on what the leak detection can and can't find: http://stackoverflow.com/a/3705629/516581. Michael On Mon, Sep 10, 2012 at 12:56 PM, K. John Wu <[email protected]> wrote: > Hi, Michael, > > The storage object pointed by the variable actual is deleted in the > function ibis::array_t<T>::freeMemory. The delete operator is invoked > if the storage object is not managed by the file manager > (actual-filename() == 0) and there is no other objects pointing to the > same storage space (actual->inUse() == 0). > > If you have deleted all FastBit related objects, then it is possible > the one of the threads have mismanaged the reference counting. I can > suggest two ways for us to track down the problem. (1) Give us a > sample data and a sample query that can reproduce the problem. This > would be the preferred method. (2) Turn ibis::gVerbose to 10, and > give us the log message files it produces. This might give us enough > of a clue to what could be the problem. > > Thanks. > > John > > > On 9/10/12 12:38 PM, Michael Beauregard wrote: >> Hey there, >> >> I found a memory leak in Fastbit while memory profiling with XCode >> Instruments. The leak occurs in array_t.cpp line 36 because the >> 'actual' instance of ibis::fileManager::storage is apparently never >> deleted. I was thinking it might be a quick fix for me, but after >> looking at it I think the ownership semantics of that object might not >> be trivial. >> >> Let me know if I can help. >> >> Michael >> _______________________________________________ >> FastBit-users mailing list >> [email protected] >> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >> _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
