程序在tls_get_addr调用中挂出

如何解决程序在tls_get_addr调用中挂出

我们有一个非常奇怪的问题，程序开始挂起#include <stdlib.h> #include <stdio.h> #include <string.h> #include <sys/stat.h> #include <unistd.h> int read_file(char* filename,char **buffer) { FILE* file1; file1 = fopen(filename,"r"); //gets the size of the file struct stat st; stat(filename,&st); int size = st.st_size; *buffer = malloc(size); fread(*buffer,size,1,file1); fclose(file1); return size; } void write_file(char* filename,char*buffer,int size) { FILE* file2 = fopen(filename,"w"); int k; for (k = size - 1; k >= 0; k--) { fwrite(buffer + k,file2); } fclose(file2); } int main(int argc,char *argv[]) { char* buffer; char* filename1; char* filename2; int filesize; //create an array and for loop to call the fread more than once filename1 = "Bible.txt"; filename2 = "reverse.txt"; filesize = read_file(filename1,&buffer); write_file(filename2,buffer,filesize); free(buffer); return 0; } 库的使用，从建立在boost::asio上的日志库中调用。 仅当我们链接我们的库时，这种情况才会发生（该库在我们的任何其他项目中都可以正常工作）。如果在日志初始化之前在模块的初始化函数中创建boost::log对象，则程序将开始工作，但这当然不是决定。我们还尝试仅添加大小相同或更大的数组，但是不行，仅套接字对象有效。

GDB显示以下内容：

boost::asio::ip::tcp::socket

或者这个：

#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::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

其他都一样。

无法深入了解，因为它不是在本地计算机上复制，而是仅在kube群集上复制。也许您可以指出我，什么会导致这种行为？

9月22日，20：23 UTC： valgrind显示了与helgrind有关的内容，但可能是数据争用，可能与问题无关。其他工具只是挂出，即使在执行-TERM kill之后也没有指向任何对象。今天确定，另一个进程（添加相同的链接后）也挂在同一步骤上，但是至少有3-4个具有相同库的应用程序即使在重建后也可以正常运行。看起来某处违反了ODR。尝试链接的应用程序无法以与工作应用程序相同的链接顺序工作-没什么区别，仍然挂出。

解决方法

嗯，这确实很难，但是我们确定问题所在。那是glibc兼容性的问题。构建机器是使用libc-23的jessie，工作机器是使用libc-19的jessie（至少我认为这是一个问题，可能是其他系统库）。我们很难调试，我们尝试用相同的选项编译所有库（为分叉库构建机器，用-O2编译库，用-O0建立库），无济于事。

但是，当我们在构建和运行上都从jessie转移到debian时，一切都开始正常工作（都具有libc-24）。这很困难而且很长，因为我们有很多库，但是，解决了这个问题。希望您永远不会遇到此类问题。