Program hangs out on tls_get_addr call - c++

Question

We have some very strange problem, program starts to hang out on boost::asio library usage, called from our logging library builded on boost::log.
That happens only if we link our library in (this library works just fine in any other our project). Program starts to work if we create boost::asio::ip::tcp::socket object in initialization function of module, before log initialization, but it's not a decision of course. We also tried to add just array of same size, or more, but no, only socket object works.
GDB shows following:
#0 __pthread_mutex_unlock_usercnt (mutex=0xf779e504 <_rtld_global+1220>,
decr=1) at pthread_mutex_unlock.c:57
#1 0xf777db5e in tls_get_addr_tail (ti=0xf681388c, dtv=0x8bc4410,
the_map=0x8b31c48, the_map#entry=0x0) at dl-tls.c:730
#2 0xf778eed9 in ___tls_get_addr (ti=<optimized out>) at dl-tls.c:778
#3 0xf658ba8f in boost::asio::detail::keyword_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::task_io_service, boost::asio::detail::task_io_service_thread_info>::context>::operator boost::asio::detail::call_stack<boost::asio::detail::task_io_service, boost::asio::detail::task_io_service_thread_info>::context*() const () from /usr/local/lib/libcommon.so.0
#4 0xf6580de5 in boost::asio::detail::call_stack<boost::asio::detail::task_io_service, boost::asio::detail::task_io_service_thread_info>::top() ()
from /usr/local/lib/libcommon.so.0
#5 0xf657259e in boost::asio::asio_handler_allocate(unsigned int, ...) ()
from /usr/local/lib/libcommon.so.0
#6 0xf3491aa0 in void* boost_asio_handler_alloc_helpers::allocate<boost::function<void (boost::system::error_code const&)> >(unsigned int, boost::function<void (boost::system::error_code const&)>&) () from /usr/local/lib/liblog.so.0
#7 0xf348f43e in void boost::asio::detail::reactive_socket_service<boost::asio::ip::udp>::async_connect<boost::function<void (boost::system::error_code const&)> >(boost::asio::detail::reactive_socket_service<boost::asio::ip::udp>::implementation_type&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, boost::function<void (boost::system::error_code const&)>&) ()
#8 0xf348b22a in boost::asio::async_result<boost::asio::handler_type<boost::function<void (boost::system::error_code const&)>, void (boost::system::error_code)>::type>::type boost::asio::datagram_socket_service<boost::asio::ip::udp>::async_connect<boost::function<void (boost::system::error_code const&)> >(boost::asio::detail::reactive_socket_service<boost::asio::ip::udp>::implementation_type&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, boost::function<void (boost::system::error_code const&)>&&) () from /usr/local/lib/liblog.so.0
#9 0xf3487eab in boost::asio::async_result<boost::asio::handler_type<boost::function<void (boost::system::error_code const&)>, void (boost::system::error_code)>::type>::type boost::asio::basic_socket<boost::asio::ip::udp, boost::asio::datagram_socket_service<boost::asio::ip::udp> >::async_connect<boost::function<void (boost::system::error_code const&)> >(boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, boost::function<void (boost::system::error_code const&)>&&)
() from /usr/local/lib/liblog.so.0
#10 0xf347c50f in syslog_udp_device::syslog_connect() ()
from /usr/local/lib/liblog.so.0
or this:
#0 0xf775de5d in __GI___pthread_mutex_lock (
mutex=0xf779e504 <_rtld_global+1220>) at ../nptl/pthread_mutex_lock.c:114
#1 0xf777db37 in tls_get_addr_tail (ti=0xf681388c, dtv=0x8bc4410,
the_map=0x8b31c48, the_map#entry=0x0) at dl-tls.c:722
#2 0xf778eed9 in ___tls_get_addr (ti=<optimized out>) at dl-tls.c:778
Others are the same.
No way to look deeper, cause it's not reproduce on local machine, only on kube cluster. May be you can to point me, what can cause this behaviour?
22 Sep, 20:23 UTC:
valgrind shows something with helgrind, but it's possible dataraces, that probably have no relation to problem. Other tools just hangs out and points nothing even after process -TERM kill. Determine today that another process (after adding same linkage) also hangs out on same step, but we have at least 3-4 apps with same libs, that works, even after rebuilds. Looks like ODR violation somewhere. Tried to link application that don't work with same link order as in worked app - no difference, still hangs out.

Answer 1

Well, that was really hard, but we determine problem. That was problem in glibc compatibility. Build machine was jessie with libc-23 and working machine was jessie with libc-19 (at least I think, that was a problem, may be other system libs). We debug that very hard, we try to compile all our libraries with same options (build machine for forked libraries build them with -O2 and our libraries with -O0), not helped.
But when we move from jessie to debian stretch on both build and running - all starts to work fine (both have libc-24). That was hard and long, cause we have many libraries, but, that solved the problem. Hope, you will never stack in such problem.