Hi John, I confirmed that using a writeLock in ibis::category::prepareMembers resolves the segfault. The suggested fix is attached.
category.cpp.diff
Description: category.cpp.diff
Steve On Dec 28, 2015, at 10:35 PM, Enns, Steven <[email protected]> wrote: > Hi John, > > I believe I have discovered a race condition in release 2.0.2: > > 1. ibis::category::prepareMembers() assigns to ibis::column::idx with a new > ibis::direkte instance at category.cpp:260 > 2. the memory limit is reached on another thread, > ibis::fileManager::invokeCleaners() -> ibis::part::cleaner::operator() -> > ibis::part::unloadIndexes() -> ibis::column::unloadIndex() which deletes and > assigns null to ibis::column::idx at column.cpp:5879 > 3. ibis::category::prepareMembers() attempts to invoke methods on > ibis::column::idx, causing SIGSEGV at category.cpp:262 > > The race exists despite acquiring locks during both assignments to > ibis::column::idx because one is a mutexLock on ibis::column::mutex whereas > the other is a softWriteLock on ibis::column::rwlock. > > To reproduce: reduce the fileManager memory limit and query a large set of > data using many threads. > > Steve > > PS. Do I understand ibis::fileManager::invokeCleaners correctly: any time > the memory limit is hit, every index thatÂ’s not currently in use gets > unloaded? > _______________________________________________ > 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
