Archived
This forum has been archived. Please start a new discussion on GitHub.
idle timeout and IceSSL
in Bug Reports
Hi !
Ice-2.0.0
Platform: Linux 2.4.21 i686
Compiler: gcc 3.2.3
The attachment contains a tarball with the code.
Unpack it and do obvious modifications in 'Makefile' and 'config'.
Then build the executables with 'make'.
Start the server with
./server --Ice.Config=config
and the client in other window:
./client --Ice.Config=config
The client will prompt with "> ". Type 's' and the client will terminate. So far so good.
Now start the client again and wait 2 minutes (to be sure).
Type 's' again and now you will get:
./client: error: T2: END error:
SslClientTransceiver.cpp:305: IceSSL::CertificateVerificationException:
Certificate signature failure.
1 - Thread ID: 3055422384
1 - Error: 218665121
1 - Message: error:0D0890A1:lib(13):func(137):reason(161)
1 - Location: a_verify.c, 141
2 - Thread ID: 3055422384
2 - Error: 336134278
2 - Message: error:14090086:lib(20):func(144):reason(134)
2 - Location: s3_clnt.c, 843
--
Cheers, Nikolai
Ice-2.0.0
Platform: Linux 2.4.21 i686
Compiler: gcc 3.2.3
The attachment contains a tarball with the code.
Unpack it and do obvious modifications in 'Makefile' and 'config'.
Then build the executables with 'make'.
Start the server with
./server --Ice.Config=config
and the client in other window:
./client --Ice.Config=config
The client will prompt with "> ". Type 's' and the client will terminate. So far so good.
Now start the client again and wait 2 minutes (to be sure).
Type 's' again and now you will get:
./client: error: T2: END error:
SslClientTransceiver.cpp:305: IceSSL::CertificateVerificationException:
Certificate signature failure.
1 - Thread ID: 3055422384
1 - Error: 218665121
1 - Message: error:0D0890A1:lib(13):func(137):reason(161)
1 - Location: a_verify.c, 141
2 - Thread ID: 3055422384
2 - Error: 336134278
2 - Message: error:14090086:lib(20):func(144):reason(134)
2 - Location: s3_clnt.c, 843
--
Cheers, Nikolai
0
Comments
-
Hi Nikolai,
This problem isn't related to the use of idle timeouts, but rather to the use of the SSL plug-in in multiple communicator instances. A bug in the plug-in causes it to release OpenSSL resources too early, namely when the first communicator is destroyed. I have fixed this problem for the next release.
In most cases it is not necessary to use multiple communicators. However, if you need this capability then I can provide a source patch.
Thanks for reporting this.
- Mark0 -
Hi Mark,
I wrote "idle timeout" because I observed the reported behavior after >1 min of idle time.
And everything is ok if I stop the client immediately.In most cases it is not necessary to use multiple communicators.
Yes, sure. Consider my case, maybe you'll give me an advice on better design.
My Ice-based application consists of three logical parts:
- the first part works as a server which accepts requests from numerous clients
to do some actions. The server only accepts or rejects the requests because the actions are time-consuming -- from several minutes to several days.
- the second part reports the results of these actions (maybe, in several minutes, or maybe, in several days) to the clients.
- the third part communicates with another server to advertise own existence and properties.
For each of these parts I create own communicator with own properties. The communicating parties are geographically dispersed (different countries) and the security issues are important.If you need this capability then I can provide a source patch.
Yes, thank you,
Nikolai0 -
Originally posted by nsns
I wrote "idle timeout" because I observed the reported behavior after >1 min of idle time.
And everything is ok if I stop the client immediately.The communicating parties are geographically dispersed (different countries) and the security issues are important.
I've attached the patch. You can apply it by changing to the src/IceSSL subdirectory and executing
% patch < patch.txt
% make
Take care,
- Mark0 -
Hi Mark,
thanks for your patch. Now the connection is reestablished well.
Unfortunately for me, I got another problem. My application (Ice::Service) which uses multiple communicators with IceSSL behaves not correctly when interrupted with Ctlr-C
(the CtrlCHandler is the default one). Most of the time everything is ok, but sometimes the program either (depending on machine) hangs up or terminates correctly but with the error message:
IceUtil::Thread::run(): uncaught exception: RecMutex.cpp:246: IceUtil::ThreadSyscallException:
thread syscall exception: Invalid argument
The only idea I have is from the pthread_mutex_lock man page:ASYNC-SIGNAL SAFETY
The mutex functions are not async-signal safe. What this means is that
they should not be called from a signal handler. In particular, calling
pthread_mutex_lock or pthread_mutex_unlock from a signal handler may
deadlock the calling thread.
This time I was not able to reproduce the problem with a small program and of course I cannot eliminate the possibility that the real problem is inside my code. Thus I cannot
expect a big help from you but I'd appreciate any hint/advice/comment.
Cheers, Nikolai0 -
Originally posted by nsns
thanks for your patch. Now the connection is reestablished well.Unfortunately for me, I got another problem. My application (Ice::Service) which uses multiple communicators with IceSSL behaves not correctly when interrupted with Ctlr-C
(the CtrlCHandler is the default one).
- Mark0 -
Regarding "async-safe" function calls: the callback registered with the CtrlCHandler can call anything. It's not called by a signal handler. A regular thread, the "CtrlCHandler" thread, waits (using sigwait()) for Ctrl-C and Ctrl-C like signals and then call the registered callback.IceUtil::Thread::run(): uncaught exception: RecMutex.cpp:246: IceUtil::ThreadSyscallException:thread syscall exception: Invalid argument
Looks like an attempt to delete an already deleted RecMutex. Could you add an assert(0) at src/IceUtil/RecMutex.cpp:246 to get a stack trace?
Cheers,
Bernard0 -
Could you add an assert(0) at src/IceUtil/RecMutex.cpp:246 to get a stack trace?of course I cannot eliminate the possibility that the real problem is inside my code.
The problem was in the destruction of an object shared between several threads.
I replaced all pointers to this object with IceUtil::Handle<> and now everything works well.
Thanks again,
Nikolai0