Home Bug Reports

idle timeout and IceSSL

nsnsnsns Member ✭✭
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

Comments

  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    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.

    - Mark
  • nsnsnsns Member ✭✭
    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,
    Nikolai
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    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.
    Right, the bug prevents OpenSSL from reestablishing the connection after the idle timeout.
    The communicating parties are geographically dispersed (different countries) and the security issues are important.
    If you need a different SSL configuration for each of these roles, then you would indeed need to use separate communicators.

    I've attached the patch. You can apply it by changing to the src/IceSSL subdirectory and executing

    % patch < patch.txt
    % make

    Take care,
    - Mark
  • nsnsnsns Member ✭✭
    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, Nikolai
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Originally posted by nsns
    thanks for your patch. Now the connection is reestablished well.
    Great!
    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).
    Do these problems still occur if IceSSL is not being used?

    - Mark
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    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,
    Bernard
  • nsnsnsns Member ✭✭
    Could you add an assert(0) at src/IceUtil/RecMutex.cpp:246 to get a stack trace?
    Yes, I did, thank you. Now I located the problem.
    of course I cannot eliminate the possibility that the real problem is inside my code.
    And this is true.
    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,
    Nikolai
Sign In or Register to comment.