Bug #16333: valgrind issues on mon in rocksdb - Ceph - Ceph

Actions

Copy link

Bug #16333

closed

valgrind issues on mon in rocksdb

Added by Samuel Just almost 8 years ago. Updated almost 8 years ago.

Status:

Resolved

Priority:

Urgent

Assignee:

Sage Weil

Category:

Target version:

% Done:

Source:

other

Tags:

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

sjust@teuthology:/a/yuriw-2016-06-14_08:41:16-rados-wip-yuri-testing2_2016_06_08-distro-basic-smithi/258957/remote

error>
<unique>0x2e</unique>
<tid>1</tid>
<kind>Leak_StillReachable</kind>
<xwhat>
<text>88 bytes in 1 blocks are still reachable in loss record 47 of 82</text>
<leakedbytes>88</leakedbytes>
<leakedblocks>1</leakedblocks>
</xwhat>
<stack>
<frame>
<ip>0x9A930E0</ip>
<obj>/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so</obj>
<fn>operator new(unsigned long)</fn>
</frame>
<frame>
<ip>0x5E8D05</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>allocate</fn>
<dir>/usr/include/c++/4.8/ext</dir>
<file>new_allocator.h</file>
<line>104</line>
</frame>
<frame>
<ip>0x5E8D05</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>std::_Hashtable<unsigned int, std::pair<unsigned int const, void ()(void)>, std::allocator<std::pair<unsigned int const, void ()(void)> &
gt;, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_allocate_buckets(unsigned long) [clone .isra.50]</fn>
<dir>/usr/include/c++/4.8/bits</dir>
<file>hashtable.h</file>
<line>779</line>
</frame>
<frame>
<ip>0x5E8E2A</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>_Hashtable</fn>
<dir>/usr/include/c++/4.8/bits</dir>
<file>hashtable.h</file>
<line>831</line>
</frame>
<frame>
<ip>0x5E8E2A</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>_Hashtable</fn>
<dir>/usr/include/c++/4.8/bits</dir>
<file>hashtable.h</file>
<line>397</line>
</frame>
<frame>
<ip>0x5E8E2A</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>unordered_map</fn>
<dir>/usr/include/c++/4.8/bits</dir>
<file>unordered_map.h</file>
<line>142</line>
</frame>
<frame>
<ip>0x5E8E2A</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta()</fn>
<dir>/srv/autobuild-ceph/gitbuilder.git/build/out~/ceph-10.2.0-2167-g7b42526/src/rocksdb/util</dir>
<file>thread_local.cc</file>
<line>172</line>
</frame>
<frame>
<ip>0x5E8F94</ip>
<obj>/usr/bin/ceph-mon</obj>
<fn>rocksdb::ThreadLocalPtr::Instance()</fn>
<dir>/srv/autobuild-ceph/gitbuilder.git/build/out~/ceph-10.2.0-2167-g7b42526/src/rocksdb/util</dir>
<file>thread_local.cc</file>
<line>135</line>
</frame>

Actions

Copy link

Updated by Sage Weil almost 8 years ago

Status changed from New to In Progress
Assignee set to Sage Weil

Actions

Copy link

Updated by Sage Weil almost 8 years ago

This is coming from env_posix.cc setting up thread local singletons:

//
Env* Env::Default() {
  // The following function call initializes the singletons of ThreadLocalPtr
  // right before the static default_env.  This guarantees default_env will
  // always being destructed before the ThreadLocalPtr singletons get
  // destructed as C++ guarantees that the destructions of static variables
  // is in the reverse order of their constructions.
  //
  // Since static members are destructed in the reverse order
  // of their construction, having this call here guarantees that
  // the destructor of static PosixEnv will go first, then the
  // the singletons of ThreadLocalPtr.
  ThreadLocalPtr::InitSingletons();
  static PosixEnv default_env;
  return &default_env;
}

Actions

Copy link