Home Help Center

pure virtual method called causes SIGABRT at throughput demo

Hi all,

The IceE compilation has successfully done on an i686 board with a customized g++ compiler. However when I start to run ./server in /demo/IceE/throughput app in my board, it returns

>pure virtual method called.
> pid 43: killed by signal 6.

If I change to let the board acts as client by connecting to a linux PC host server, running ./client at the board causes immediate

> pid 49: killed by signal 11

IceE is compiled with STATICLIBS=Yes. I tried the others demo, all happens to abort in the same way after calling ./server.

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Could you run the executable in the debugger and get the stack trace of the abort (assuming gdb is installed on your board)?

    Thanks,

    Cheers,
    Benoit.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Btw, I would first try to run the demo/IceE/minimal demo on your board. It's also possible that the lack of getifaddrs() support is causing some problems. One way to figure it out would be to add the following property to the configuration file (demo/IceE/minimal/config):

    Ice.Default.Host=127.0.0.1

    The IceInternal::getLocalHosts() method won't be called if you define this property and the client & server will use the loopback interface.

    Cheers,
    Benoit.
  • syseekersyseeker Member
    Hello Benoit,

    The testbed is run with the embedded board as server, and Linux PC as client. We wrote a client-server throughput app, modified slightly from the /throughput demo.

    Now, at Server.cpp, I found that segmentation fault happens at

    Ice::ObjectAdapterPtr adapter = communicator->createObjectAdapterWithEndpoints("Throughput",
    "tcp -h 192.168.0.222 -p 10003");

    Tracing deep into the code, the actual seg fault occurs at ObjectAdapter.cpp

    // Filter out any endpoints that are not meant to be published.
    //
    _publishedEndpoints.erase(remove_if(_publishedEndpoints.begin(),
    _publishedEndpoints.end(),
    not1(Ice::constMemFun(&Endpoint::publish))),
    _publishedEndpoints.end());


    Well, I just commented this line and ./server runs. I assume commented out this code is not harmful to a 1-1 client-server testbed. But I am curious, this code runs well in Linux PC. :)
  • syseekersyseeker Member
    throughput client throws IllegalMessageSize()

    Now everything is ready and the client-server shall talk!
    I start ./server and well, the app runs, manage to reach communicator->waitForShutdown(); .... and starts listen to request

    But...

    When I start ./client, Connection.cpp 1191: illegalMessageSizeException is thrown at the below stage in Client.cpp:

    ThroughputPrx throughput = ThroughputPrx::checkedCast(base);

    I checked with Ethereal, and found out that the Server has replied with "Validate Connection [Unreassembled Packet]". The Message Size: 234881024 (0x00 00 00 0e).

    I traced with normal Linux PC to Linux PC with exactly the same client-server app, they are running perfectly, with Message Size: 14 (0x0e 00 00 00).

    Now, I bet this is not endianness problem, because I have configured defined(__i686) in config.h for big endian. :confused:
  • syseekersyseeker Member
    :D Thanks to hints in http://www.zeroc.com/vbulletin/showthread.php?t=384&highlight=endian

    Now, I am sure this board is Little endian :rolleyes: .

    and the apps are running well! BTW, the commenting in #4 is still required.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    I'm glad to see you're making some progress with porting Ice-E on your board :).

    It looks like your compiled code is trying to call the Endpoint publish() method instead of the overriden version. This works with all our supported Ice or Ice-E compilers so I suspect this is a bug with the compiler. To workaround the issue, you could change the faulty line of code with the following loop:
    vector<EndpointPtr>::const_iterator q = _publishedEndpoints.begin();
    while(q != _publishedEndpoints.end())
    {
        if((*q)->publish())
        {
            ++q;
        }
        else
        {
             q = _publishedEndpoints.erase(q);
         }
    }
    

    Cheers,
    Benoit.
  • syseekersyseeker Member
    Hello Benoit,

    Thanks!

    vector<EndpointPtr>::iterator q = _publishedEndpoints.begin(); shall work, instead of const_iterator :)
Sign In or Register to comment.