Archived

This forum has been archived. Please start a new discussion on GitHub.

Fail in test

Im trying to port our application to linux, and I still got some problem with the mutex.

Im using mandrake 10.0, the kernel is 2.6.3. I compiled Ice 2.1.2 and his dependencies with gcc 3.4.2.

With : LD_ASSUME_KERNEL = 2.4.1

I checked if all the tests were working right and it fail at
./test/Ice/location
in testing identity indirect proxy.

Whats stranger is that the problem is intermittent. Sometime it pass.

After some kill of the test, it started to hang in ./test/Ice/operations :
testing checked cast...

Heres the output:
testing checked cast... Traceback (most recent call last):
File "./test/Ice/operations/run.py", line 26, in ?
TestUtil.clientServerTest(name)
File "./config/TestUtil.py", line 284, in clientServerTest
clientServerTestWithOptions(name, "", "")
File "./config/TestUtil.py", line 280, in clientServerTestWithOptions
clientServerTestWithOptionsAndNames(name, additionalServerOptions, additionalClientOptions, "server", "client")
File "./config/TestUtil.py", line 269, in clientServerTestWithOptionsAndNames
printOutputFromPipe(clientPipe)
File "./config/TestUtil.py", line 178, in printOutputFromPipe
c = pipe.read(1)
KeyboardInterrupt
test in ./test/Ice/operations failed with exit status 256

I had to reboot the OS to fix that.

When it pass it fail on :

*** running tests in ./test/Freeze/dbmap
starting client... ok
[ ./test/Freeze/dbmap/client: Berkeley DB: DbEnv "./test/Freeze/dbmap/db": unable to initialize mutex: Function not implemented ]
[ ./test/Freeze/dbmap/client: Berkeley DB: DbEnv "./test/Freeze/dbmap/db": process-private: unable to initialize environment lock: Function not implemented ]
SharedDbEnv.cpp:323: Freeze::DatabaseException:
DbEnv::open: Function not implemented
test in ./test/Freeze/dbmap failed with exit status 256

Without: LD_ASSUME_KERNEL = 2.4.1

I got this once.

It looked to be hang after "remote address = 127.0.0.1:12345"

*** running tests in ./test/Freeze/evictor
starting server... ok
starting client... ok
testing Freeze Evictor... ./test/Freeze/evictor/client: warning: connection exception:
Outgoing.cpp:175: Ice::TimeoutException:
timeout while sending or receiving data
local address = 127.0.0.1:32931
remote address = 127.0.0.1:12345
Traceback (most recent call last):
File "./test/Freeze/evictor/run.py", line 31, in ?
TestUtil.clientServerTestWithOptions(name, testOptions, testOptions)
File "./config/TestUtil.py", line 280, in clientServerTestWithOptions
clientServerTestWithOptionsAndNames(name, additionalServerOptions, additionalClientOptions, "server", "client")
File "./config/TestUtil.py", line 269, in clientServerTestWithOptionsAndNames
printOutputFromPipe(clientPipe)
File "./config/TestUtil.py", line 178, in printOutputFromPipe
c = pipe.read(1)
KeyboardInterrupt
test in ./test/Freeze/evictor failed with exit status 256

If it pass it fail here:

testing tests in ./test/IceStorm/single
starting icestorm service... failed!
test in ./test/IceStorm/single failed with exit status 256

Maybe I should not bother trying to make all this work since we only use Ice, IceUtil and a bit of IceXML.

Im asking myself, should I use LD_ASSUME_KERNEL = 2.4.1 or not since without it pass more test.

Hope you can help me. Thanks you.

Comments

  • You shouldn't use LD_ASSUME_KERNEL=2.4.1. This is for old operating systems with a broken Linux Posix Threads implementation. Newer kernels shouldn't need this.

    What are your versions of glibc and Berkeley DB? Also, did you compile Berkeley DB with LD_ASSUME_KERNEL=2.4.1? If so, try compiling Berkeley DB without this setting, so that both Ice and Berkeley DB use the same thread library.
  • I use glibc 2.3.3 and Berkeley db 4.2.52 as supplied on your web site. I think LD_ASSUME_KERNEL only affect the dynamic linking as we can see the different behavior at run-time.

    see : http://people.redhat.com/drepper/assumekernel.html
  • bernard
    bernard Jupiter, FL
    Hi Francis,

    I am surprised LD_ASSUME_KERNEL does anything on your 2.6 kernel. I thought it was just for 2.4.x kernels, such as RH9 and FC1.

    We don't provide a DB 4.2.52 binary distribution on our web site, and the source-distribution is identical to the one from Sleepycat.
    If you configured DB with LD_ASSUME_KERNEL=2.4.1, maybe the resulting configuration and build are broken; you may want to specify --enable-posixmutexes to configure, to make sure it uses POSIX mutexes.

    Cheers,
    Bernard