Home Help Center

Ice for C++: Problem running tests after building for Fedora Core 5

bartleybartley Member Chris BartleyOrganization: Carnegie Mellon University Robotics InstituteProject: The Telepresence Robot Kit (TeRK) ✭✭
Hi,

I'm trying to get Ice for C++ (v 3.0.1) working under Fedora Core 5 (actually, Ice for Java is my real goal, but I realize that I need to build Ice for C++ first). It appears to build ok, but I get the following error when trying to run the tests:
# make test

*** running tests in ./test/IceUtil/thread
starting client... ok
running mutex test... ../../../include/IceUtil/Mutex.h:318: IceUtil::ThreadSyscallException:
thread syscall exception: Resource deadlock avoided failed
test mutex failed
test in ./test/IceUtil/thread failed with exit status 256

Any suggestions? Here's my system info:

Kernel: 2.6.16-1.2080_FC5smp #1 SMP Tue Mar 28 03:55:15 EST 2006
bzip2: Version: 1.0.3, Release: 2.2.1
db4: Version: 4.3.29, Release: 3.fc5
expat: Version: 1.95.8, Release: 8.2
ncurses: Version: 5.5, Release: 19
openssl: Version: 0.9.8a, Release: 5.2
readline: Version: 5.0, Release: 3.2.1

thanks heaps,

chris

Comments

  • alexmalexm Member Eskinder Alex MesfinOrganization: Medtronic, Inc.Project: www.medtronic.com
    Acording to Fedora project, Fedora project is strictly NPTL (thread) so Your problem might be related to that.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    It looks like something changed in the Fedora Core 5 pthread implementation. I suspect pthread_mutex_trylock is failing with EDEADLK if the thread already acquired the mutex like for the FreeBSD implementation. The best way to figure this out would be trace where the test is failing. Are other tests working?

    Also, if you look at the code of the test which is failing (test/IceUtil/MutexTest.cpp), you'll see that there's already a #ifdef __FreeBSD__, if my suspicion is correct this #ifdef would need to be changed to include Linux.

    Cheers,
    Benoit.
  • bartleybartley Member Chris BartleyOrganization: Carnegie Mellon University Robotics InstituteProject: The Telepresence Robot Kit (TeRK) ✭✭
    Are other tests working?

    Yep, all the other tests work fine (that is, all the tests which aren't in the test/IceUtil/thread directory...there might be some in test/IceUtil/thread that work, but I don't know yet since it dies on the first one).

    I'll test your suggestion with the #ifdef in the morning.

    thanks for your help,

    chris
  • bartleybartley Member Chris BartleyOrganization: Carnegie Mellon University Robotics InstituteProject: The Telepresence Robot Kit (TeRK) ✭✭
    More info: The only tests in test/IceUtil/thread which don't work are MutexTest and MonitorMutexTest. All the others are fine. I get the same error for MonitorMutexTest as I did for MutexTest.
  • bartleybartley Member Chris BartleyOrganization: Carnegie Mellon University Robotics InstituteProject: The Telepresence Robot Kit (TeRK) ✭✭
    Also, if you look at the code of the test which is failing (test/IceUtil/MutexTest.cpp), you'll see that there's already a #ifdef __FreeBSD__, if my suspicion is correct this #ifdef would need to be changed to include Linux.
    Looks like your suspicion is indeed correct. Changing this line (122) in MutexTest.cpp:
    #ifdef __FreeBSD__
    
    to this:
    #if defined(__FreeBSD__) || defined(__linux)
    
    allows the test to complete successfully.

    What do I need to do to fix the Ice code? Or is the problem merely in the test? Sorry I'm a little clueless here.

    thanks heaps,

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

    I believe fixing the test should be enough. I'll discuss this with our pthread expert once he gets back from vacation!

    This shouldn't affect the Ice code and it's unlikely to affect your code. It would affect your code only if it relied on tryAcquire() to return false if the mutex is already locked by the current thread...

    In any case, thanks for pointing this out -- this will be fixed for the next release.

    Cheers,
    Benoit.
  • bartleybartley Member Chris BartleyOrganization: Carnegie Mellon University Robotics InstituteProject: The Telepresence Robot Kit (TeRK) ✭✭
    Great thanks, and thanks for all your help. I tried my code and it appears to be working fine so far [fingers crossed].

    thanks!

    chris
Sign In or Register to comment.