thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Nevzorov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (THRIFT-4888) TSSLSocket::close() server crash
Date Fri, 28 Jun 2019 07:43:00 GMT

    [ 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)

Mime
View raw message