程序在抛出异常时挂起

时间:2016-06-05 00:07:49

标签: c++ exception glibc hang libstdc++

我在共享主机上运行C ++程序(Web服务器)时遇到问题。

程序在我的开发机器上运行正常,但是当我尝试在主机上运行它时,它会在尝试抛出异常时挂起。

它试图抛出异常并不是一个问题;如果它成功抛出异常,异常将被捕获几个堆栈帧,并且Web服务器将继续运行。

这里是悬挂线程的堆栈跟踪:

#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x00007f18e559669a in _L_lock_1088 () from /home/nr/lib/glibc-2.14.1/lib/libpthread.so.0
#2  0x00007f18e55964fa in __pthread_mutex_lock (mutex=0x7f18e66b6930) at pthread_mutex_lock.c:82
#3  0x00007f18e530f3db in __dl_iterate_phdr (callback=0x970100 <_Unwind_IteratePhdrCallback>, data=0x7f18e2fe9040) at dl-iteratephdr.c:42
#4  0x00000000009714e3 in _Unwind_Find_FDE ()
#5  0x000000000096daf6 in uw_frame_state_for ()
#6  0x000000000096ed40 in uw_init_context_1 ()
#7  0x000000000096f53e in _Unwind_RaiseException ()
#8  0x00000000008dfe7b in __cxa_throw () at ../../../../gcc-5.1/libstdc++-v3/libsupc++/eh_throw.cc:82
#9  0x000000000054ff6e in Wt::WEnvironment::getCookie(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () at /home/nr/dev/libraries/wt-3.3.4/src/Wt/WEnvironment.C:435
#10 0x000000000069a372 in Wt::WebSession::handleRequest(Wt::WebSession::Handler&) () at /home/nr/dev/libraries/wt-3.3.4/src/web/WebSession.C:1388
#11 0x000000000068a21c in Wt::WebController::handleRequest(Wt::WebRequest*) () at /home/nr/dev/libraries/wt-3.3.4/src/web/WebController.C:713
#12 0x00000000004d815b in boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Wt::WebController, Wt::WebRequest*>, boost::_bi::list2<boost::_bi::value<Wt::WebController*>, boost::_bi::value<http::server::HTTPRequest*> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) () at /home/nr/dev/dist/boost/include/boost/bind/mem_fn_template.hpp:165
#13 0x000000000056e4a2 in Wt::WIOService::run() () at /home/nr/dev/dist/boost/include/boost/asio/detail/task_io_service_operation.hpp:38
#14 0x0000000000810ff3 in thread_proxy ()
#15 0x00007f18e5593cea in start_thread (arg=0x7f18e2fec700) at pthread_create.c:301
#16 0x00007f18e52d8fcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

由于它在开发机器上工作正常,我怀疑问题可能与开发机器上存在的不同版本的共享库有关,而不是托管机器,但我不知道具体是什么。我确实可以静态地链接我可以包含的所有东西,包括libstdc ++,正是为了避免这样的问题。

对于如何进一步诊断此问题的任何建议表示赞赏。

编辑:如果有帮助,开发机器运行 Debian Jessie ,而主机运行 CentOS 6.8

1 个答案:

答案 0 :(得分:1)

我弄明白了这个问题。它确实与开发与托管机器上存在的不同版本的共享库有关。

我已经静态链接所有C ++库,只有C库保持动态链接。值得注意的是, glibc 保持动态链接,因为它不能很好地支持静态链接。

开发机器上安装的glibc版本是2.19;在主机上,它是2.12。

当我最初尝试在主机上运行程序时,我收到了以下形式的错误:

./myapp: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./myapp)

(它要求2.14而不是2.19的原因是我的程序实际使用的功能,存在于2.14及更高版本中,并且glibc版本向后兼容。)

为了解决这个问题,我构建了glibc 2.14,将其二进制文件上传到托管计算机,并使用LD_LIBRARY_PATH将程序指向它们。这使得上面的错误消失了,但我现在得到了悬念,促使我发布了这个问题。

事实证明,挂起的原因是有一个glibc组件,其路径在编译时被烘焙到可执行文件中,并且不被LD_LIBRARY_PATH覆盖 - 加载器({ {1}})。

所以,我正在使用托管机器的glibc 2.12加载程序,以及glibc 2.14中的其余库 - 这些都不起作用。

我通过更改在开发机器上生成程序的链接器命令解决了这个问题,硬编码到主机上glibc 2.14加载器的路径,如this answer中所述(非常感谢@EmployedRussian,写那个!)。