[
https://issues.apache.org/jira/browse/THRIFT-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874731#comment-16874731
]
Vladimir Nevzorov edited comment on THRIFT-4888 at 6/28/19 7:42 AM:
--------------------------------------------------------------------
[~jking3], thank you for your replies!
I have Debian 9.5. I didn't install openssl by my own.
OpenSSL 1.1.0j
1. I havn't tried 0.12.0
I see [similar issue here|https://issues.apache.org/jira/browse/THRIFT-4885]
with 0.10.0.
Now I'm gonna check server code. Next step - link against the debug OpenSSL...
as you wrote.
Documentation [warning|http://thrift.apache.org/lib/cpp#0110]
A bit worried about this warning:
_In older releases, if a TSSLSocketFactory's lifetime was not at least as long
as the TSSLSockets it created, we silently reverted openssl to unsafe
multithread behavior and so the results were undefined. Changes were made in
0.11.0 that cause either an assertion or a core instead of undefined behavior.
The lifetime of a TSSLSocketFactory must be longer than any TSSLSocket that it
creates, otherwise openssl will be cleaned up too early. If the static boolean
is set to disable openssl initialization and cleanup and leave it up to the
consuming application, this requirement is not needed._
And this:
_SIGPIPE signal_
_Applications running OpenSSL over network connections may crash if SIGPIPE is
not ignored. This happens when they receive a connection reset by remote peer
exception, which somehow triggers a SIGPIPE signal. If not handled, this signal
would kill the application._
was (Author: avovana):
[~jking3], thank you for your replies!
I have Debian 9.5. I didn't install openssl by my own.
OpenSSL 1.1.0j
1. I havn't tried 0.12.0
I see similar issue here with 0.10.0.
Now I'm gonna check server code. Next step - link against the debug OpenSSL...
as you wrote.
Documentation [warning|http://thrift.apache.org/lib/cpp#0110]
A bit worried about this warning:
_In older releases, if a TSSLSocketFactory's lifetime was not at least as long
as the TSSLSockets it created, we silently reverted openssl to unsafe
multithread behavior and so the results were undefined. Changes were made in
0.11.0 that cause either an assertion or a core instead of undefined behavior.
The lifetime of a TSSLSocketFactory must be longer than any TSSLSocket that it
creates, otherwise openssl will be cleaned up too early. If the static boolean
is set to disable openssl initialization and cleanup and leave it up to the
consuming application, this requirement is not needed._
And this:
_SIGPIPE signal_
_Applications running OpenSSL over network connections may crash if SIGPIPE is
not ignored. This happens when they receive a connection reset by remote peer
exception, which somehow triggers a SIGPIPE signal. If not handled, this signal
would kill the application._
> TSSLSocket::close() server crash
> --------------------------------
>
> Key: THRIFT-4888
> URL: https://issues.apache.org/jira/browse/THRIFT-4888
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.10.0
> Reporter: Vladimir Nevzorov
> Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> *Client* gets info from the server and terminates succesfully.
> But *Server* crashes when *client* _TBufferedTransport_ calls close().
>
> Client code:
> {code:java}
> int main() {
> std::cout << "C++ client in network mode start..." << std::endl;
> shared_ptr<AllowAllAccessManager> acc_mgr(new AllowAllAccessManager());
> shared_ptr<apache::thrift::transport::TSSLSocketFactory>
> ssl_tx_transp_factory(
> new qkd_api_client::SSLSocketTransportFactory(CLIENT_TX_CERT_PATH,
> CLIENT_TX_KEY_PATH,
> TRUSTED_CA_PATH,
> acc_mgr)
> );
> shared_ptr<TBufferedTransport> transp_tx(
> new
> TBufferedTransport(ssl_tx_transp_factory->createSocket(TX_SERVER_ADDR,
> SERVER_PORT)));
> auto client_tx =
> qkd_network_api::v1::NetworkApiServiceClient(boost::shared_ptr<TProtocol>(new
> TBinaryProtocol(transp_tx)));
> try {
> transp_tx->open();
> qkd_network_api::v1::Info info_tx;
> client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
>
> Server output:
> {code:java}
> write 0x00007f2a0992c1cd
> <unknown> 0x00007f2a07d65d05
> BIO_write 0x00007f2a07d607cb
> <unknown> 0x00007f2a08165c9b
> <unknown> 0x00007f2a081664d0
> <unknown> 0x00007f2a0816e9b1
> <unknown> 0x00007f2a0816ce05
> SSL_shutdown 0x00007f2a081770c9
> apache::thrift::transport::TSSLSocket::close 0x00007f2a0842aa51
> apache::thrift::server::TConnectedClient::cleanup 0x00007f2a08433196
> apache::thrift::server::TConnectedClient::run 0x00007f2a08432d65
> apache::thrift::server::TThreadedServer::TConnectedClientRunner::run
> 0x00007f2a0843a5f8
> apache::thrift::concurrency::PthreadThread::threadMain 0x00007f2a0843e5ff
> start_thread 0x00007f2a099234a4
> clone 0x00007f2a051e2d0f
> {code}
>
> If client open() and close() transport without calling interface method -
> server works fine.
>
> {code:c++}
> ...
> transp_tx->open();
> // client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
> When I use python client - all works fine.
>
> Help me, please.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
