Question

I have a simple use case for a Thrift Server(TSimpleServer) wherein I have a couple of threads spawned(besides the main thread). One of the newly spawned threads enters the Thrift event loop (i.e server.serve()). Upon receiving a signal in the main thread I invoke server.stop() which is causing the error posted below.

At first I thought it was an uncaught exception. However wrapping both the invocations of server.serve() and server.stop() in try-catch‘es didn’t help isolate the problem. Any thoughts/suggestions(on what I should be doing)? Most Thrift tutorials/guides/examples seem to talk about server start but don’t seem to mention the stop scenario, any pointers/best-practices/suggestions in this regard would be great. Thanks.

Also, I am using thrift-0.7.0.

Error details:

Thrift: Fri Nov 18 21:22:47 2011 TServerTransport died on accept: TTransportExc\
eption: Interrupted
*** glibc detected *** ./build/mc_daemon: munmap_chunk(): invalid poi\
nter: 0x0000000000695f18 ***
Segmentation fault (core dumped)

Also here’s the stack-trace:

#0  0x00007fb751c92f08 in ?? () from /lib/libc.so.6
#1  0x00007fb7524bb0eb in apache::thrift::server::TSimpleServer::serve (
    this=0x1e5bca0) at src/server/TSimpleServer.cpp:140
#2  0x000000000046ce15 in a::b::server_thread::operator() (
    this=0x695f18)
    at /path/to/server_thread.cpp:80
#3  0x000000000046c1a9 in boost::detail::thread_data<boost::reference_wrapper<a\
ds::data_load::server_thread> >::run (this=0x1e5bd80)
    at /usr/include/boost/thread/detail/thread.hpp:81
#4  0x00007fb7526f2b70 in thread_proxy ()
   from /usr/lib/libboost_thread.so.1.40.0
#5  0x00007fb7516fd9ca in start_thread () from /lib/libpthread.so.0
#6  0x00007fb7519fa70d in clone () from /lib/libc.so.6
#7  0x0000000000000000 in ?? ()

Edit 1: I have added pseudo-code for the main thread, the thrift server thread and the background thread.

Edit 2: I seem to have resolved the original issue as noted in my answer below. However this solution leads to two rather undesirable/questionable design choices: (i) I had to introduce a thrift endpoint to enable a mechanism to stop the server (ii) The handler class for the thrift service(which is usually required to instantiate a server object) now requires a means to signal back to the server to stop, introducing a circular dependency of sorts.

Any suggestions on these design issues/choices would be greatly appreciated.

Answer 1

My problem seems to have stemmed from my code/design wherein I had signal-handler code in the main thread invoking stop on the server which was started in a ‘server thread’. Changing this behavior(as noted in the pastebin code-snippets) helped resolve this issue.