Archived
This forum has been archived. Please start a new discussion on GitHub.
CtrlCHandler hanging
in Bug Reports
I’m using Ice 2.1.0 on SusSE 9, AMD64. My application extends Ice::Application. When I specify wrong name in –Ice.Config= option it prints “syscall exception: No such file or directory” and hangs. I found that CtrlCHandler destructor is blocked in pthread_join(). After updating Application.app with adding
if(_ctrlCHandler.get() != 0) {
ignoreInterrupt();
_ctrlCHandler.reset();
}
after last catch(…) and commenting out those strings under
if(_communicator)
{
everyting works fine
if(_ctrlCHandler.get() != 0) {
ignoreInterrupt();
_ctrlCHandler.reset();
}
after last catch(…) and commenting out those strings under
if(_communicator)
{
everyting works fine
0
Comments
-
Hi,
I tried to reproduce this problem using Ice 2.1.2 on RedHat Linux, but no hang occurred when I specified an invalid filename for --Ice.Config.
Do you have a small example that we can use to reproduce this behavior?
Take care,
- Mark0 -
No, it's combination of linking with JVM and Oracle's OCI and from my current experience sometimes RedHat/32 != SuSE/64 in signal handling. Anyway, why don't you keep symmetry in working with _ctrlCHandler? You can create it without _communicator being initialized. Nevertheless you destroy it only having valid _communicator pointer.0
-
Hi Garry,
This is indeed a bug: the Application::main() function must clean up its CtrlCHander in all circumstances.
On Linux and Unix, the CtrlCHandler starts a thread (waiting on sigwait); it's good to stop and join this thread before static destruction.
Thanks for the bug report; it will be fixed in the next Ice release.
Bernard0