Valgrind throws Invalid write of size 8 using smart pointers - c++11

I am trying to implement a binary tree with the following code:
Node* Node::addLeft(int v){
left = make_shared<Node> (v).get();
//cout<<"set left "<<left->value<<endl;
left->parent=this;
return this;
}
When running valgrind, I've got the following report:
==18345== Invalid write of size 8
==18345== at 0x400F26: Node::addLeft(int) (Ex9.2.cpp:264)
==18345== by 0x401182: main (Ex9.2.cpp:360)
==18345== Address 0x5ab61f8 is 40 bytes inside a block of size 48 free'd
==18345== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18345== by 0x402603: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2> >::deallocate(std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) (new_allocator.h:110)
==18345== by 0x4023DC: std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2> > >::deallocate(std::allocator<std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2> >&, std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) (alloc_traits.h:517)
==18345== by 0x40211D: std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr() (allocated_ptr.h:72)
==18345== by 0x402885: std::_Sp_counted_ptr_inplace<Node, std::allocator<Node>, (__gnu_cxx::_Lock_policy)2>::_M_destroy() (shared_ptr_base.h:539)
==18345== by 0x401649: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:167)
==18345== by 0x40135C: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:659)
==18345== by 0x401315: std::__shared_ptr<Node, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:925)
==18345== by 0x401331: std::shared_ptr<Node>::~shared_ptr() (shared_ptr.h:93)
==18345== by 0x400F19: Node::addLeft(int) (Ex9.2.cpp:262)
==18345== by 0x401182: main (Ex9.2.cpp:360)
Do you have an idea about this error?
Any help would be appreciated !

. I changed left member from a Node* to a shared_ptr. I guess now the temporary is still destroyed at the semicolon but the newly created Node object is not destroyed, as the ownership has been transferred to left member.

Related

GCC Backend Development - How do I fix `insn does not satisfy its constraints` when compiling a simple program?

I am working on writing a GCC backend for a new architecture. When I try to compile the following simple program with -O0 (note: this error does not occur when optimizations are enabled):
int main()
{
int a = 10;
a++;
}
I get this error:
test.c: In function ‘main’:
test.c:5:1: error: insn does not satisfy its constraints:
5 | }
| ^
(insn 8 7 9 (set (reg:SI 12)
(plus:SI (reg:SI 13)
(const_int 1 [0x1]))) "test.c":4:6 1 {addsi3}
(nil))
during RTL pass: final
test.c:5:1: internal compiler error: in final_scan_insn_1, at final.c:3012
0x65f4b2 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:108
0x65f4d8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x5e2fc8 final_scan_insn_1
../../gcc/gcc/final.c:3012
0xa23e0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:3152
0xa24099 final_1
../../gcc/gcc/final.c:2020
0xa249f2 rest_of_handle_final
../../gcc/gcc/final.c:4658
0xa249f2 execute
../../gcc/gcc/final.c:4736
Based on what the error message say's the problem seems to be with the constraints in addsi3. Here is the definition of addsi3:
(define_insn "addsi3"
[(set (match_operand:SI 0 "register_operand" "=r,r")
(plus:SI (match_operand:SI 1 "register_operand" "r,r")
(match_operand:SI 2 "reg_or_imm_operand" "r,I")))]
"1"
"#
add %0 %1 %2
addi %0 %1 %2")
The program compiles successfully if the constraints in the definition of addsi3 are removed. Here is the definition for the I constraint:
(define_constraint "I"
"A 30-bit immediate."
(and (match_code "const_int")
(match_test "ival >= -536870912 && ival <= 536870911")))
Here is the definition of the reg_or_imm_operand predicate.
(define_predicate "reg_or_imm_operand"
(ior (and (match_code "const_int")
(match_test "IN_RANGE (INTVAL (op), -536870912, 536870911)"))
(match_operand 0 "register_operand")))
If more specific information is needed please let me know and I will edit the question.
Thanks in advance. :)
The function main is declared as returning an integer, but the return statement is missing.
It should be better with :
int main()
{
int a = 10;
a++;
return 0;
}

DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./foo/my.dylib ./bar/exec returns 1 w/o running my executable

On macOS 10.12.6, I have a shared library and an executable (both built myself, SIP should not apply AFAIK) and I'd like to preload the library for the executable. It fails, with a return code of 1, and silently otherwise:
$ ./bar/exec
<does stuff>
$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./foo/my.dylib ./bar/exec
<returns immediately>
$ echo $?
1
# 1 is not an explicitly returned value from ./bar/exec
If I add either DYLD_PRINT_LIBRARIES or DYLD_PRINT_LIBRARIES_POST_LAUNCH options as documented in man dyld, they both show that both the library and the executable have been loaded successfully:
...
dyld: loaded: /full/path/to/exec
dyld: loaded: ./foo/my.dylib
...
If I try to run the executable with preload in either dtruss or lldb, it runs, without the library preloaded. This might make sense because these tools are SIP-protected.
How do I go about debugging this?
UPDATE
Thanks to #macmoonshine, I am able to reproduce the return code 1 exit under lldb by setting the preload environment from LLDB itself as opposed for LLDB:
(lldb) env DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./foo/my.dylib
(lldb) run
...
Process 24130 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
frame #0: 0x00007fffc8aac310 libsystem_kernel.dylib`__exit
...
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x00007fffc8aac310 libsystem_kernel.dylib`__exit
frame #1: 0x000000010008ebac my.dylib`my_init at my.c:86 [opt]
frame #2: 0x0000000100018a1b dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 385
frame #3: 0x0000000100018c1e dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
frame #4: 0x00000001000144aa dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 338
frame #5: 0x0000000100013524 dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 138
frame #6: 0x00000001000135b9 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 75
frame #7: 0x0000000100005434 dyld`dyld::initializeMainExecutable() + 125
frame #8: 0x00000001000098c6 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 3966
frame #9: 0x0000000100004249 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 470
frame #10: 0x0000000100004036 dyld`_dyld_start + 54
This is a start for debugging.
You can run your code in lldb, where you can set the environment with the env command:
env DYLD_FORCE_FLAT_NAMESPACE=1
env DYLD_INSERT_LIBRARIES=./foo/my.dylib
run
With lldb you can run your program until it crashes. If it exists abnormally with exit() (or _exit()), you should set symbolic breakpoints with b exitand b _exit. So you have the chance to get a backtrace where it fails.

Adding DTPerformanceSession.framework causes app to crash on run

I added DTPerformanceSession.framework to the OSX app Build Phases and when I run the app it crashes with the following error:
dyld`dyld_fatal_error:
0x7fff5fc0109c: int3
0x7fff5fc0109d: nop
Console message:
dyld: Library not loaded: #rpath/DTPerformanceSession.framework/Versions/A/DTPerformanceSession
Referenced from: /Users/Danger/Library/Developer/Xcode/DerivedData/HSCountingInputStream-dbhgckaaqtaiqueimpvpxllvygvt/Build/Products/Debug/HSCountingInputStream
Reason: image not found
Back trace:
* thread #1: tid = 0x5e40d, 0x00007fff5fc0109d dyld`dyld_fatal_error + 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x00007fff5fc0109d dyld`dyld_fatal_error + 1
frame #1: 0x00007fff5fc02138 dyld`dyld::halt(char const*) + 79
frame #2: 0x00007fff5fc059bd dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2733
frame #3: 0x00007fff5fc01397 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 761
frame #4: 0x00007fff5fc0105e dyld`_dyld_start + 54
Note: DTPerformanceSession.framework is at path:
/Applications/Xcode.app/Contents/Developer/Library/Frameworks
See the great page: Using code generated flags to debug with Instruments. Basically one just needs to add the framework, build and remove the framework, it is needed only for Xcode to find the include and only once. Alternatively add the framework and mark it "Optional".

Is there a bug in the boost asio HTTP Server 3 example or boost bug?

boost library version 1.53
Debian Linux 6.0 ( Linux 2.6.32-5-amd64 on x86_64 )
It is hard to test own software when valgrind log contains lots of warnings.
So with no changes I built the HTTP server3 example and run it under the Valgrind.
Take a look, please. Did I miss something?
valgrind --tool=helgrind --log-file=valgrind.log ./server3 0.0.0.0 83 5 /root/server3
Here is the Helgrind log (edited to 30000 body characters limit, full log http://pastebin.com/Vkbr9vsA):
Helgrind, a thread error detector
Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al.
Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
Command: ./server3 0.0.0.0 83 5 /root/server3
Parent PID: 8662
Lock at 0x524F5E0 was first observed
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x5043388: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
by 0x5CE5A7C: clone (clone.S:112)
Possible data race during read of size 8 at 0x524F4E8 by thread #3
Locks held: none
at 0x5043356: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
by 0x5CE5A7C: clone (clone.S:112)
This conflicts with a previous write of size 8 by thread #2
Locks held: 1, at address 0x524F5E0
at 0x5043416: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
by 0x5CE5A7C: clone (clone.S:112)
----------------------------------------------------------------
Possible data race during read of size 4 at 0x524F60C by thread #3
Locks held: none
at 0x50496D4: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043361: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
by 0x5CE5A7C: clone (clone.S:112)
This conflicts with a previous write of size 4 by thread #2
Locks held: none
at 0x525C27B: pthread_key_create (pthread_key_create.c:44)
by 0x525C82F: pthread_once (pthread_once.S:104)
by 0x50496D3: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043361: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
----------------------------------------------------------------
Possible data race during read of size 8 at 0x524F4E8 by thread #1
Locks held: 1, at address 0x61A1E20
at 0x5043356: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043478: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5047875: boost::detail::interruption_checker::interruption_checker(pthread_mutex_t*, pthread_cond_t*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5044002: boost::thread::join_noexcept() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x42660E: boost::thread::join() (thread.hpp:751)
by 0x4215C5: http::server3::server::run() (server.cpp:63)
by 0x41A65B: main (main.cpp:37)
----------------------------------------------------------------
Possible data race during read of size 4 at 0x524F60C by thread #1
Locks held: 1, at address 0x61A1E20
at 0x50496D4: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043361: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043478: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5047875: boost::detail::interruption_checker::interruption_checker(pthread_mutex_t*, pthread_cond_t*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5044002: boost::thread::join_noexcept() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x42660E: boost::thread::join() (thread.hpp:751)
by 0x4215C5: http::server3::server::run() (server.cpp:63)
by 0x41A65B: main (main.cpp:37)
This conflicts with a previous write of size 4 by thread #2
Locks held: none
at 0x525C27B: pthread_key_create (pthread_key_create.c:44)
by 0x525C82F: pthread_once (pthread_once.S:104)
by 0x50496D3: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043361: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x5043498: boost::detail::set_current_thread_data(boost::detail::thread_data_base*) (in /usr/lib/libboost_thread.so.1.53.0)
by 0x504380E: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
----------------------------------------------------------------
Possible data race during write of size 4 at 0x61A36B8 by thread #6
Locks held: none
at 0x4223B0: boost::asio::detail::epoll_reactor::descriptor_state::set_ready_events(unsigned int) (epoll_reactor.hpp:68)
by 0x4228A5: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (epoll_reactor.ipp:430)
by 0x423629: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:396)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
by 0x42EB34: boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()(boost::asio::io_service*) const (mem_fn_template.hpp:49)
by 0x42EA72: unsigned long boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (bind.hpp:243)
by 0x42E91E: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >::operator()() (bind_template.hpp:20)
by 0x42E65D: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > >::run() (thread.hpp:117)
by 0x5043818: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
by 0x5256B4F: start_thread (pthread_create.c:304)
Address 0x61A36B8 is 24 bytes inside a block of size 160 alloc'd
at 0x4C28A3A: operator new(unsigned long) (vg_replace_malloc.c:298)
by 0x42806A: boost::asio::detail::epoll_reactor::descriptor_state* boost::asio::detail::object_pool_access::create<boost::asio::detail::epoll_reactor::descriptor_state>() (object_pool.hpp:35)
by 0x4267B8: boost::asio::detail::object_pool<boost::asio::detail::epoll_reactor::descriptor_state>::alloc() (object_pool.hpp:89)
by 0x4229E3: boost::asio::detail::epoll_reactor::allocate_descriptor_state() (epoll_reactor.ipp:512)
by 0x4223D4: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (epoll_reactor.ipp:151)
by 0x424405: boost::asio::detail::reactive_socket_service_base::do_assign(boost::asio::detail::reactive_socket_service_base::base_implementation_type&, int, int const&, boost::system::error_code&) (reactive_socket_service_base.ipp:182)
by 0x42DA98: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (reactive_socket_service.hpp:117)
by 0x42D75C: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (stream_socket_service.hpp:138)
by 0x42D263: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (basic_socket.hpp:285)
by 0x42CAD7: boost::asio::detail::reactive_socket_accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ip::tcp>::do_perform(boost::asio::detail::reactor_op*) (reactive_socket_accept_op.hpp:66)
by 0x409DE0: boost::asio::detail::reactor_op::perform() (reactor_op.hpp:40)
by 0x422C2F: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:622)
----------------------------------------------------------------
Possible data race during write of size 8 at 0x61A36A8 by thread #6
Locks held: none
at 0x410E9E: void boost::asio::detail::op_queue_access::next<boost::asio::detail::task_io_service_operation, boost::asio::detail::task_io_service_operation>(boost::asio::detail::task_io_service_operation*&, boost::asio::detail::task_io_service_operation*) (op_queue.hpp:41)
by 0x40EBEE: boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>::push(boost::asio::detail::task_io_service_operation*) (op_queue.hpp:107)
by 0x4228BB: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (epoll_reactor.ipp:431)
by 0x423629: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:396)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
by 0x42EB34: boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()(boost::asio::io_service*) const (mem_fn_template.hpp:49)
by 0x42EA72: unsigned long boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (bind.hpp:243)
by 0x42E91E: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >::operator()() (bind_template.hpp:20)
by 0x42E65D: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > >::run() (thread.hpp:117)
by 0x5043818: ??? (in /usr/lib/libboost_thread.so.1.53.0)
by 0x4C2D6FE: mythread_wrapper (hg_intercepts.c:219)
Address 0x61A36A8 is 8 bytes inside a block of size 160 alloc'd
at 0x4C28A3A: operator new(unsigned long) (vg_replace_malloc.c:298)
by 0x42806A: boost::asio::detail::epoll_reactor::descriptor_state* boost::asio::detail::object_pool_access::create<boost::asio::detail::epoll_reactor::descriptor_state>() (object_pool.hpp:35)
by 0x4267B8: boost::asio::detail::object_pool<boost::asio::detail::epoll_reactor::descriptor_state>::alloc() (object_pool.hpp:89)
by 0x4229E3: boost::asio::detail::epoll_reactor::allocate_descriptor_state() (epoll_reactor.ipp:512)
by 0x4223D4: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (epoll_reactor.ipp:151)
by 0x424405: boost::asio::detail::reactive_socket_service_base::do_assign(boost::asio::detail::reactive_socket_service_base::base_implementation_type&, int, int const&, boost::system::error_code&) (reactive_socket_service_base.ipp:182)
by 0x42DA98: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (reactive_socket_service.hpp:117)
by 0x42D75C: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (stream_socket_service.hpp:138)
by 0x42D263: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (basic_socket.hpp:285)
by 0x42CAD7: boost::asio::detail::reactive_socket_accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ip::tcp>::do_perform(boost::asio::detail::reactor_op*) (reactive_socket_accept_op.hpp:66)
by 0x409DE0: boost::asio::detail::reactor_op::perform() (reactor_op.hpp:40)
by 0x422C2F: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:622)
----------------------------------------------------------------
Thread #2: lock order "0x64C720 before 0x619E550" violated
Observed (incorrect) order is: acquisition of lock at 0x619E550
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408545: boost::asio::detail::posix_mutex::lock() (posix_mutex.hpp:52)
by 0x40D9E1: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (scoped_lock.hpp:36)
by 0x422BD3: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:611)
by 0x422D38: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (epoll_reactor.ipp:648)
by 0x409C69: boost::asio::detail::task_io_service_operation::complete(boost::asio::detail::task_io_service&, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37)
by 0x4236AD: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:412)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
by 0x42EB34: boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()(boost::asio::io_service*) const (mem_fn_template.hpp:49)
by 0x42EA72: unsigned long boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (bind.hpp:243)
by 0x42E91E: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >::operator()() (bind_template.hpp:20)
followed by a later acquisition of lock at 0x64C720
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408845: boost::asio::detail::posix_static_mutex::lock() (posix_static_mutex.hpp:44)
by 0x40E523: boost::asio::detail::scoped_lock<boost::asio::detail::posix_static_mutex>::scoped_lock(boost::asio::detail::posix_static_mutex&) (scoped_lock.hpp:36)
by 0x424EE7: boost::asio::detail::signal_set_service::deliver_signal(int) (signal_set_service.ipp:431)
by 0x42477C: boost::asio::detail::signal_set_service::pipe_read_op::do_perform(boost::asio::detail::reactor_op*) (signal_set_service.ipp:95)
by 0x409DE0: boost::asio::detail::reactor_op::perform() (reactor_op.hpp:40)
by 0x422C2F: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:622)
by 0x422D38: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (epoll_reactor.ipp:648)
by 0x409C69: boost::asio::detail::task_io_service_operation::complete(boost::asio::detail::task_io_service&, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37)
by 0x4236AD: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:412)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
Required order was established by acquisition of lock at 0x64C720
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408845: boost::asio::detail::posix_static_mutex::lock() (posix_static_mutex.hpp:44)
by 0x40E523: boost::asio::detail::scoped_lock<boost::asio::detail::posix_static_mutex>::scoped_lock(boost::asio::detail::posix_static_mutex&) (scoped_lock.hpp:36)
by 0x425060: boost::asio::detail::signal_set_service::add_service(boost::asio::detail::signal_set_service*) (signal_set_service.ipp:467)
by 0x4248BB: boost::asio::detail::signal_set_service::signal_set_service(boost::asio::io_service&) (signal_set_service.ipp:128)
by 0x42558B: boost::asio::signal_set_service::signal_set_service(boost::asio::io_service&) (signal_set_service.hpp:53)
by 0x42B628: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::signal_set_service>(boost::asio::io_service&) (service_registry.hpp:81)
by 0x408742: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (service_registry.ipp:123)
by 0x42A92F: boost::asio::signal_set_service& boost::asio::detail::service_registry::use_service<boost::asio::signal_set_service>() (service_registry.hpp:48)
by 0x42984A: boost::asio::signal_set_service& boost::asio::use_service<boost::asio::signal_set_service>(boost::asio::io_service&) (io_service.hpp:33)
by 0x428633: boost::asio::basic_io_object<boost::asio::signal_set_service, false>::basic_io_object(boost::asio::io_service&) (basic_io_object.hpp:90)
by 0x42753A: boost::asio::basic_signal_set<boost::asio::signal_set_service>::basic_signal_set(boost::asio::io_service&) (basic_signal_set.hpp:106)
followed by a later acquisition of lock at 0x619E550
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408545: boost::asio::detail::posix_mutex::lock() (posix_mutex.hpp:52)
by 0x40D9E1: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (scoped_lock.hpp:36)
by 0x4224E4: boost::asio::detail::epoll_reactor::register_internal_descriptor(int, int, boost::asio::detail::epoll_reactor::descriptor_state*&, boost::asio::detail::reactor_op*) (epoll_reactor.ipp:179)
by 0x4250FC: boost::asio::detail::signal_set_service::add_service(boost::asio::detail::signal_set_service*) (signal_set_service.ipp:485)
by 0x4248BB: boost::asio::detail::signal_set_service::signal_set_service(boost::asio::io_service&) (signal_set_service.ipp:128)
by 0x42558B: boost::asio::signal_set_service::signal_set_service(boost::asio::io_service&) (signal_set_service.hpp:53)
by 0x42B628: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::signal_set_service>(boost::asio::io_service&) (service_registry.hpp:81)
by 0x408742: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (service_registry.ipp:123)
by 0x42A92F: boost::asio::signal_set_service& boost::asio::detail::service_registry::use_service<boost::asio::signal_set_service>() (service_registry.hpp:48)
by 0x42984A: boost::asio::signal_set_service& boost::asio::use_service<boost::asio::signal_set_service>(boost::asio::io_service&) (io_service.hpp:33)
by 0x428633: boost::asio::basic_io_object<boost::asio::signal_set_service, false>::basic_io_object(boost::asio::io_service&) (basic_io_object.hpp:90)
----------------------------------------------------------------
Thread #1: lock order "0x619E550 before 0x64C720" violated
Observed (incorrect) order is: acquisition of lock at 0x64C720
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408845: boost::asio::detail::posix_static_mutex::lock() (posix_static_mutex.hpp:44)
by 0x40E523: boost::asio::detail::scoped_lock<boost::asio::detail::posix_static_mutex>::scoped_lock(boost::asio::detail::posix_static_mutex&) (scoped_lock.hpp:36)
by 0x425166: boost::asio::detail::signal_set_service::remove_service(boost::asio::detail::signal_set_service*) (signal_set_service.ipp:492)
by 0x4248F0: boost::asio::detail::signal_set_service::shutdown_service() (signal_set_service.ipp:138)
by 0x42564D: boost::asio::signal_set_service::shutdown_service() (signal_set_service.hpp:110)
by 0x41AA69: boost::asio::detail::service_registry::~service_registry() (service_registry.ipp:37)
by 0x41AB32: boost::asio::io_service::~io_service() (io_service.ipp:53)
by 0x41B178: http::server3::server::~server() (in /root/server3/server3)
by 0x41A66A: main (main.cpp:37)
followed by a later acquisition of lock at 0x619E550
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408545: boost::asio::detail::posix_mutex::lock() (posix_mutex.hpp:52)
by 0x40D9E1: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (scoped_lock.hpp:36)
by 0x40AC3A: boost::asio::detail::epoll_reactor::deregister_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&, bool) (epoll_reactor.ipp:307)
by 0x4251BC: boost::asio::detail::signal_set_service::remove_service(boost::asio::detail::signal_set_service*) (signal_set_service.ipp:499)
by 0x4248F0: boost::asio::detail::signal_set_service::shutdown_service() (signal_set_service.ipp:138)
by 0x42564D: boost::asio::signal_set_service::shutdown_service() (signal_set_service.hpp:110)
by 0x41AA69: boost::asio::detail::service_registry::~service_registry() (service_registry.ipp:37)
by 0x41AB32: boost::asio::io_service::~io_service() (io_service.ipp:53)
by 0x41B178: http::server3::server::~server() (in /root/server3/server3)
by 0x41A66A: main (main.cpp:37)
Required order was established by acquisition of lock at 0x619E550
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408545: boost::asio::detail::posix_mutex::lock() (posix_mutex.hpp:52)
by 0x40D9E1: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (scoped_lock.hpp:36)
by 0x422BD3: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:611)
by 0x422D38: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (epoll_reactor.ipp:648)
by 0x409C69: boost::asio::detail::task_io_service_operation::complete(boost::asio::detail::task_io_service&, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37)
by 0x4236AD: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:412)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
by 0x42EB34: boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()(boost::asio::io_service*) const (mem_fn_template.hpp:49)
by 0x42EA72: unsigned long boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (bind.hpp:243)
by 0x42E91E: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >::operator()() (bind_template.hpp:20)
followed by a later acquisition of lock at 0x64C720
at 0x4C2C692: pthread_mutex_lock (hg_intercepts.c:495)
by 0x408845: boost::asio::detail::posix_static_mutex::lock() (posix_static_mutex.hpp:44)
by 0x40E523: boost::asio::detail::scoped_lock<boost::asio::detail::posix_static_mutex>::scoped_lock(boost::asio::detail::posix_static_mutex&) (scoped_lock.hpp:36)
by 0x424EE7: boost::asio::detail::signal_set_service::deliver_signal(int) (signal_set_service.ipp:431)
by 0x42477C: boost::asio::detail::signal_set_service::pipe_read_op::do_perform(boost::asio::detail::reactor_op*) (signal_set_service.ipp:95)
by 0x409DE0: boost::asio::detail::reactor_op::perform() (reactor_op.hpp:40)
by 0x422C2F: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:622)
by 0x422D38: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (epoll_reactor.ipp:648)
by 0x409C69: boost::asio::detail::task_io_service_operation::complete(boost::asio::detail::task_io_service&, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37)
by 0x4236AD: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (task_io_service.ipp:412)
by 0x423302: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:153)
by 0x42393A: boost::asio::io_service::run() (io_service.ipp:59)
The HTTP Server 3 example uses a pool of threads. And while Valgrind is an immensely useful suite of programs, using it correctly requires a bit of tact. As the helgrind documentation states, it is best to start using helgrind early in a project. Throwing an existing multi-threaded program at helgrind is very likely to report many false positives in my experience. As an example, helgrind cannot always detect data races when using posix condition variables, this quote is from the helgrind documentation I linked previously
Avoid POSIX condition variables. If you can, use POSIX semaphores
(sem_t, sem_post, sem_wait) to do inter-thread event signalling.
Semaphores with an initial value of zero are particularly useful for
this.
It is possible this is the cause of the false positives you have cited. Both the Asio and Thread libraries use condition variables as part of their implementation. I very much doubt the possible data races or incorrect lock ordering is due to a bug in either library. It's worth quoting Jeff Atwood's First Rule of Programming here
An essential part of being a humble programmer is realizing that
whenever there's a problem with the code you've written, it's always
your fault. It is possible that a bug exists in the OS, the compiler,
or a third-party product -- but this should not be your first thought.
It is much more likely that the bug exists in the application code
under development.

"undefined reference to 'pantheios_log_3_no_test'"

I'm having trouble linking with Pantheios on Linux with gcc4.6 with the following error:
In function `pantheios::internal::log_dispatch_3(int, unsigned int, char const*, unsigned int, char const*, unsigned int, char const*)':
sig_writing_sink.cpp:(.text._ZN9pantheios8internal14log_dispatch_3EijPKcjS2_jS2_[pantheios::internal::log_dispatch_3(int, unsigned int, char const*, unsigned int, char const*, unsigned int, char const*)]+0x6d): undefined reference to `pantheios_log_3_no_test'
collect2: ld returned 1 exit status
I'm linking with:
libpantheios.1.core.gcc46.mt.a
libpantheios.1.fe.simple.gcc46.mt.a
libpantheios.1.be.fprintf.gcc46.mt.a
libpantheios.1.bec.fprintf.gcc46.mt.a
libpantheios.1.util.gcc46.mt.a
libpantheios.1.appl.gcc46.mt.a
libpantheios.1.core.gcc46.mt.a
Where is pantheios_log_3_no_test?
What am I missing?
Turns out that in gcc, symbols are only linked forward, so dependent symbols in a given lib will only be resolved from the libs that follow it in the link list. See here for some more details.
By moving other statically linked libs to before Pantheios, the linker succeeded.

Resources