Using valgrind 3.8.0 on a freebsd system, I get this report:
==23046== Possible data race during read of size 8 at 0x12D2C5A0 by thread #65
==23046== Locks held: none
==23046== at 0x41C11F6: memmove (in /lib/libc.so.7)
==23046== by 0x1030375: variable_list** std::__copy_move<false, true,
std::random_access_iterator_tag>::__copy_m<variable_list*>(variable_list*
const*, variable_list* const*, variable_list**) (stl_algobase.h:377)
==23046== by 0x10303BD: variable_list** std::__copy_move_a<false,
variable_list**, variable_list**>(variable_list**, variable_list**,
variable_list**) (stl_algobase.h:396)
==23046== by 0x1030405: variable_list** std::__copy_move_a2<false,
variable_list**, variable_list**>(variable_list**, variable_list**,
variable_list**) (stl_algobase.h:435)
==23046== by 0x1030447: variable_list** std::copy<variable_list**,
variable_list**>(variable_list**, variable_list**, variable_list**)
(stl_algobase.h:466)
==23046== by 0x1030473: variable_list**
std::__uninitialized_copy<true>::uninitialized_copy<variable_list**,
variable_list**>(variable_list**, variable_list**, variable_list**)
(stl_uninitialized.h:98)
==23046== by 0x103049A: variable_list**
std::uninitialized_copy<variable_list**, variable_list**>(variable_list**,
variable_list**, variable_list**) (stl_uninitialized.h:122)
==23046== by 0x10304C5: variable_list**
std::__uninitialized_copy_a<variable_list**, variable_list**,
variable_list*>(variable_list**, variable_list**, variable_list**,
std::allocator<variable_list*>&) (stl_uninitialized.h:262)
==23046== by 0x10304F4: variable_list**
std::__uninitialized_move_a<variable_list**, variable_list**,
std::allocator<variable_list*> >(variable_list**, variable_list**,
variable_list**, std::allocator<variable_list*>&) (stl_uninitialized.h:272)
==23046== by 0x103074A: std::vector<variable_list*,
std::allocator<variable_list*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<variable_list**,
std::vector<variable_list*, std::allocator<variable_list*> > >, variable_list*
const&) (vector.tcc:316)
==23046== by 0x10308DC: std::vector<variable_list*,
std::allocator<variable_list*>
>::insert(__gnu_cxx::__normal_iterator<variable_list**,
std::vector<variable_list*, std::allocator<variable_list*> > >, variable_list*
const&) (vector.tcc:113)
==23046== by 0x102E417: snmpNotification::addVarbind(snmpVarbind const&,
unsigned long) (snmpNotification.cpp:392)
==23046==
==23046== This conflicts with a previous write of size 8 by thread #43
==23046== Locks held: 3, at addresses 0xFDA2148 0xFE2B020 (and 1 that can't be
shown)
==23046== at 0x11D4CA3:
pdbBulkUpdateRecord::pdbBulkUpdateRecord(pdbBulkUpdateRecord const&)
(BulkUpdateDefs.h:36)
==23046== by 0x1212730:
__gnu_cxx::new_allocator<pdbBulkUpdateRecord>::construct(pdbBulkUpdateRecord*,
pdbBulkUpdateRecord const&) (new_allocator.h:108)
==23046== by 0x1216A4C: std::vector<pdbBulkUpdateRecord,
std::allocator<pdbBulkUpdateRecord> >::push_back(pdbBulkUpdateRecord const&)
(stl_vector.h:690)
What could cause a lock to have an address that can't be shown?
Phil
-----
Phil Longstaff
Senior Software Engineer
x2904
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
