Home Help Center

Hang in activate() on Linux

walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
I'm running an Ice C++ program that is hanging when I try to activate my object adapter. I'm running on an embedded Linux based on Red Hat EL3 and our Ice is version 2.1.

The code is like this:

Ice::Identity id( Ice::stringToIdentity( "blah" ) );
m_objectAdapter->add( app, id );
m_objectAdapter->activate( ); // THE APP IS HUNG AND NEVER RETURNS FROM THIS CALL
wait();

This application *does* work on one of my Linux boxes but not on this one particular thin client. I know that the socket is created and listening on the bound port (10000) because I see it using netstat. I'm curious what else the activate() method does that might cause it to hang?

I've tried setting Ice.Override.Timeout=1000 and Ice.Override.ConnectTimeout=1000, but it still hangs "forever".

Thanks for any help!

Regards,
Jeff

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Jeff,

    Are you using a locator? That's the only other thing which could potentially block in activate() (the registration of the object adapter endpoints with the locator registry).

    The best way to figure out where it's blocking would be to attach the debugger to the process and get the stack trace of the thread calling activate().

    Cheers,
    Benoit.
  • walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
    Benoit,

    Thank you for your quick reply! Using a debugger is extremely difficult on this system because it's a thin client and has *no* development software on it already (plus we're using Intel compilers).

    I'll spend some time today trying to get the Intel debugger installed on a thumb drive to see if I can get some kind of stack trace.

    Jeff
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Ok. Another option, if installing the debugger is really too difficult, would be to add more tracing in Ice to try to figure out where it hangs. It should be easy since you have the source code :). You could start by adding some tracing to the object adapter activate() method for example (src/Ice/ObjectAdapterI.cpp). Also, if possible I would recommend upgrading to a recent Ice version.

    Btw, is your application using a locator? If not, I'm not quite sure what could block... but you could try running your application in thread-per-connection mode to see if it makes a difference (in case the problem somehow comes from the thread pool...). You can use the --Ice.ThreadPerConnection command line option to use the thread-per-connection concurrency model.

    Cheers,
    Benoit.
  • walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
    Benoit,

    Thanks again! Sorry, I forgot that part last time. We are not using locators. I'll first try to instrument the Ice library and see what's going on. I've also spoken with Roland about possibly upgrading to 3.1.1 or trying out the 3.2 beta. We might be going to 3.1.1 anyway for various other reasons, so it might be worth trying it out anyway.

    Jeff :confused:
  • walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
    Well, the fun continues. I re-built my 2.1 with a bunch of cerr statements in Ice::ObjectAdapterI::activate()
    and now it works fine. :(

    Does that indicate some sort of timing problem? If so, do you recommend I try the thread-per-connection mode?

    Jeff
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    I don't see how it could be a timing problem. I'm afraid without knowning exactly where it hangs it's impossible to say what could be the problem :(. Most likely, something is behaving differently on your embedded Linux OS causing this hang.

    With thread-per-connection, the object adapter activation will use a different code path. So if it works with thread-per-connection, this would indicate that the hang most likely occurs in the thread pool. Do you get the hang in thread-per-connection mode?

    Also, did you use the same build options for your new Ice build (optimize vs. debug for instance) and does the problem shows up again once you rebuild Ice without the cerr statements?

    Cheers,
    Benoit.
  • walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
    Benoit,

    It was built with the same options and the same compiler. I will take out the print statements here in a minute (after our daily scrum) and then see if it still works or not. I'll also experiment a little bit with thread-per-connection.

    Thanks again for your help!
    Jeff
  • walls1500walls1500 Member Jeff WallsOrganization: Hewlett-PackardProject: Overture
    Benoit,

    *groan* After taking out the print statements, it now continues to work flawlessly. There must have been some difference in how Ice was compiled originally vs. how I compiled it recently. I'll check with my team and see if anyone can come up with anything.

    Thanks!
    Jeff
Sign In or Register to comment.