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
