You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Jake Farrell (JIRA)" <ji...@apache.org> on 2015/07/21 04:21:05 UTC

[jira] [Updated] (THRIFT-3147) Segfault while receiving data

     [ https://issues.apache.org/jira/browse/THRIFT-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jake Farrell updated THRIFT-3147:
---------------------------------
    Fix Version/s:     (was: 0.9.2)
                   0.9.3

> Segfault while receiving data
> -----------------------------
>
>                 Key: THRIFT-3147
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3147
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Compiler, C++ - Library
>    Affects Versions: 0.9.2
>         Environment: Ubuntu 12.04
>            Reporter: julien greard
>             Fix For: 0.9.3
>
>
> Hello,
> I'm working on a Thrift Client/Server app for a while. I was working with 0.9.1 successfully and I wanted to try the 0.9.2.
> I now get a segfault when my client tries to reach the server:
> Thread [19] 14167 [core: 6] (Suspended : Signal : SIGSEGV:Segmentation fault)	
> 	apache::thrift::transport::TTransport::readAll() at TTransport.h:126 0x1f4ac60	
> 	apache::thrift::protocol::TBinaryProtocolT<apache::thrift::transport::TTransport>::readI32() at TBinaryProtocol.tcc:375 0x1f63794	
> 	apache::thrift::protocol::TBinaryProtocolT<apache::thrift::transport::TTransport>::readMessageBegin() at TBinaryProtocol.tcc:206 0x1f62fa5	
> 	apache::thrift::protocol::TVirtualProtocol<apache::thrift::protocol::TBinaryProtocolT<apache::thrift::transport::TTransport>, apache::thrift::protocol::TProtocolDefaults>::readMessageBegin_virt() at TVirtualProtocol.h:432 0x1f61d0e	
> 	apache::thrift::protocol::TProtocol::readMessageBegin() at TProtocol.h:531 0x26ca66e	
> 	apache::thrift::TDispatchProcessor::process() at TDispatchProcessor.h:113 0x26cac59	
> 	apache::thrift::server::TSimpleServer::serve() at TSimpleServer.cpp:100 0x7ffff0cbb714	
> 	evitech::ConfigurationThriftServer::open() at ConfigurationThriftServer.cpp:111 0x26c8c0e	
> 	evitech::DistantConfigurationManager::execute() at DistantConfigurationManager.cpp:62 0x26d22c2	
> 	evitech::Task::runOneIteration() at Task.cpp:408 0x26f8eec	
> 	<...more frames...>	
> On the server side, I have a C++ app with (snapshot of code):
>     _processor.reset(new jaguar_configuration::JaguarConfigurationServiceProcessor(_handler));
>     _protocolFactory.reset(new apache::thrift::protocol::TBinaryProtocolFactory());
>      _serverTransport.reset(new apache::thrift::transport::TServerSocket(_serverPort));
>     _transportFactory.reset(new apache::thrift::transport::TBufferedTransportFactory());
>     _server.reset(new apache::thrift::server::TSimpleServer(_processor, _serverTransport, _transportFactory, _protocolFactory));
>     _server.serve();
> On the client side, I run a python app with:
> - TSocket 
> - TBufferedTransport
> - TBinaryProtocol
> Here is the method I use (idl):
> void keep_alive(1: string identifier) throws (1:InvalidOperation op),
> I'm probably doing something wrong, but I've no idea what. I've seen in wireshark that I'm indeed sending the correct data on the correct side. If you need more samples to investigate let me know.
> What could have changed between 0.9.1 and 0.9.2 that could give me this result ?
> Thanks in advance,
> J. Greard



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)