问题描述
我们有一个非常奇怪的问题，程序开始挂起#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对象，则程序将开始工作，但这当然不是决定。我们还尝试仅添加大小相同或更大的数组，但是不行，仅套接字对象有效。
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）。这很困难而且很长，因为我们有很多库，但是，解决了这个问题。希望您永远不会遇到此类问题。