
Hi, I have a strange problem. The destructor of a class calls join_all(). But it seems that he hangs there. Even though some other code behind the join_all() is executed before it finishs! Lets get concret: seal::~seal() { ThgPrgs.join_all(); cout<<"Crabd quits, goodbye"<<endl; } When i run my program, the last message is "Crabd quits, goodbye" and it should exit then, but it doesnt. If i stop it running in gdb an do a backtrace i get the following: #0 0xffffe410 in __kernel_vsyscall () #1 0xb7c796c8 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7d21e6a in boost::thread::join () from /usr/local/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1 #3 0xb7d224ee in boost::thread_group::join_all () from /usr/local/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1 #4 0x0808742c in ~seal (this=0x80c9890) at src/seal.cpp:20 #5 0x0808eb55 in checked_delete<seal> (x=0x80c9890) at /usr/local/include/boost/checked_delete.hpp:34 #6 0x0809566a in boost::detail::sp_counted_impl_p<seal>::dispose (this=0x80dc410) at /usr/local/include/boost/detail/sp_counted_impl.hpp:76 #7 0x0805950f in boost::detail::sp_counted_base::release (this=0x80dc410) at /usr/local/include/boost/detail/sp_counted_base_gcc_x86.hpp:145 #8 0x08059555 in ~shared_count (this=0x8103e04) at /usr/local/include/boost/detail/shared_count.hpp:159 #9 0x0808dd1c in ~shared_ptr (this=0x8103e00) at src/seal.h:39 #10 0x08089182 in ~tcp_connection (this=0x8103df8) at src/seal.cpp:212 #11 0x08094273 in checked_delete<tcp_connection> (x=0x8103df8) at /usr/local/include/boost/checked_delete.hpp:34 #12 0x080967d0 in boost::detail::sp_counted_impl_p<tcp_connection>::dispose (this=0x80dcf00) at /usr/local/include/boost/detail/sp_counted_impl.hpp:76 #13 0x0805950f in boost::detail::sp_counted_base::release (this=0x80dcf00) at /usr/local/include/boost/detail/sp_counted_base_gcc_x86.hpp:145 #14 0x08059555 in ~shared_count (this=0x80dc4e8) at /usr/local/include/boost/detail/shared_count.hpp:159 #15 0x0808ddc6 in ~shared_ptr (this=0x80dc4e4) at src/seal.h:66 #16 0x0808e69f in ~value (this=0x80dc4e4) at src/seal.cpp:232 #17 0x0808e700 in ~list3 (this=0x80dc4e0) at src/seal.cpp:232 #18 0x0808e766 in ~bind_t (this=0x80dc4d8) at src/seal.cpp:232 #19 0x080910a7 in ~accept_handler (this=0x80dc4c0) at /usr/local/include/boost/asio/detail/reactive_socket_service.hpp:1228 ---Type <return> to continue, or q <return> to quit--- #20 0x08095595 in ~op (this=0x80dc4b0) at /usr/local/include/boost/asio/detail/reactor_op_queue.hpp:355 #21 0x080918db in boost::asio::detail::reactor_op_queue<int>::op<boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp, boost::asio::detail::epoll_reactor<false>
::accept_handler<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, tcp_server, boost::shared_ptr<tcp_connection>, boost::asio::error const&>, boost::_bi::list3<boost::_bi::value<tcp_server*>, boost::_bi::value<boost::shared_ptr<tcp_connection> >, boost::arg<1> > > > ::destroy_handler (base=0x80dc4b0) at /usr/local/include/boost/asio/detail/reactor_op_queue.hpp:355 #22 0x080709d2 in boost::asio::detail::reactor_op_queue<int>::op_base::destroy (this=0x80dc4b0) at /usr/local/include/boost/asio/detail/reactor_op_queue.hpp:294 #23 0x0806df75 in boost::asio::detail::reactor_op_queue<int>::destroy_operations (this=0x80c99a8) at /usr/local/include/boost/asio/detail/reactor_op_queue.hpp:245 #24 0x0806d677 in boost::asio::detail::epoll_reactor<false>::shutdown_service (this=0x80c9970) at /usr/local/include/boost/asio/detail/epoll_reactor.hpp:108 #25 0x0806c2ec in ~service_registry (this=0x80c98d8) at /usr/local/include/boost/asio/detail/service_registry.hpp:53 #26 0x0806ba81 in ~io_service (this=0x80c98d4) at src/seal.cpp:8 #27 0x08087648 in ~seal (this=0x80c9890) at src/seal.cpp:32 #28 0x0808eb55 in checked_delete<seal> (x=0x80c9890) at /usr/local/include/boost/checked_delete.hpp:34 #29 0x0809566a in boost::detail::sp_counted_impl_p<seal>::dispose (this=0x80da710) at /usr/local/include/boost/detail/sp_counted_impl.hpp:76 #30 0x0805950f in boost::detail::sp_counted_base::release (this=0x80da710) at /usr/local/include/boost/detail/sp_counted_base_gcc_x86.hpp:145 #31 0x08059555 in ~shared_count (this=0xbfa2e124) at /usr/local/include/boost/detail/shared_count.hpp:159 #32 0x0808dd1c in ~shared_ptr (this=0xbfa2e120) at src/seal.h:39 #33 0x080a8d68 in boost::shared_ptr<seal>::reset (this=0x80c8824) at /usr/local/include/boost/shared_ptr.hpp:231 #34 0x080a863e in main (argc=1, argv=0xbfa2e204) at src/crabd.cpp:71
The class seal holds some other classes in shared_ptrs which are will be destroyed in this moment too. Some of them have also a join_all() in their destructors. Im wondering if they produce the lock? But the main question here is: I read "Crabd quits, goodbye" and after this i stop the program and i get in the backtrace from gdb the line "#4 0x0808742c in ~seal (this=0x80c9890) at src/seal.cpp:20". And Line 20 in seal.cpp is the line with join_all(). How is this possible, though join_all should block? Thanks for your help and for reading this. Manuel Jung, Germany

Manuel Jung wrote:
Hi,
I have a strange problem. The destructor of a class calls join_all(). But it seems that he hangs there. Even though some other code behind the join_all() is executed before it finishs! Lets get concret:
seal::~seal() { ThgPrgs.join_all(); cout<<"Crabd quits, goodbye"<<endl; }
Could you possibly post a small (complete) example that demonstrates the behaviour? I am not able to guess where to problem might be from looking at the destructor only. Btw.: join_all doesn't own the no-throw property. So your design possibly should we reworked anyways. Roland

Roland Schwarz wrote:
Manuel Jung wrote:
Hi,
I have a strange problem. The destructor of a class calls join_all(). But it seems that he hangs there. Even though some other code behind the join_all() is executed before it finishs! Lets get concret:
seal::~seal() { ThgPrgs.join_all(); cout<<"Crabd quits, goodbye"<<endl; }
Could you possibly post a small (complete) example that demonstrates the behaviour? I am not able to guess where to problem might be from looking at the destructor only.
Btw.: join_all doesn't own the no-throw property. So your design possibly should we reworked anyways.
Roland
Hi, Thanks for reading. For some reason i post two times the other on has a respond two. The destructor is called two times which should not be right, i will check that tomorow. Im sorry, but i cannot give a small example, thus the program and the code which may be connected with this problem is much too long. join_all dows not throw; But in which way should i change my design? Or do you mean i lack of exception handling? Though i catch errors in my real programcode, thus it throws errors even without it i shortend the code to the minimum. Cheers Manuel Jung
participants (2)
-
Manuel Jung
-
Roland Schwarz