[
https://issues.apache.org/jira/browse/THRIFT-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
julien greard resolved THRIFT-3147.
-----------------------------------
Resolution: Not A Problem
Fix Version/s: 0.9.2
not a bug after all - it was a compilation issue, my compiler was mixing 0.9.1
and 0.9.2 sources... It works well after deleting 0.9.1 sources
> 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.2
>
>
> 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)
