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
