Archived
This forum has been archived. Please start a new discussion on GitHub.
IceJ-1.2.0 failing tests?
I'm getting a hang when running 'python allTests.py' in IceJ-1.2.0 (Ice-1.2.0 passed
all its tests and is installed):
*** running tests in ./test/Ice/exceptions:
tests with regular server.
starting server... ok
starting client... ok
testing servant registration exceptions... ok
testing servant locator registration exceptions... ok
testing object factory registration exceptions... ok
testing stringToProxy... ok
testing checked cast... ok
Exception in thread "main" java.lang.RuntimeException
at AllTests.test(AllTests.java:22)
at AllTests.allTests(AllTests.java:809)
at Client.run(Client.java:20)
at Client.main(Client.java:34)
(hangs at this point...)
Now, this is on RH9, but I don't think I'm using an NPTL kernel:
weaver% uname -a
Linux weaver.tuc.noao.edu 2.4.20-28.9smp #1 SMP Thu Dec 18 13:28:43 EST 2003 i686 athlon i386 GNU/Linux
plus, I would have expected problems with Ice tests if I were. DB4 is 4.1.25 (newly
built and installed
Java is:
weaver% java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Has anyone seen this? Can someone point me at what I might have done wrong?
Thanks!
Steve
all its tests and is installed):
*** running tests in ./test/Ice/exceptions:
tests with regular server.
starting server... ok
starting client... ok
testing servant registration exceptions... ok
testing servant locator registration exceptions... ok
testing object factory registration exceptions... ok
testing stringToProxy... ok
testing checked cast... ok
Exception in thread "main" java.lang.RuntimeException
at AllTests.test(AllTests.java:22)
at AllTests.allTests(AllTests.java:809)
at Client.run(Client.java:20)
at Client.main(Client.java:34)
(hangs at this point...)
Now, this is on RH9, but I don't think I'm using an NPTL kernel:
weaver% uname -a
Linux weaver.tuc.noao.edu 2.4.20-28.9smp #1 SMP Thu Dec 18 13:28:43 EST 2003 i686 athlon i386 GNU/Linux
plus, I would have expected problems with Ice tests if I were. DB4 is 4.1.25 (newly
built and installed
Java is:
weaver% java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Has anyone seen this? Can someone point me at what I might have done wrong?
Thanks!
Steve
0
Comments
-
Try setting the following:
export LD_ASSUME_KERNEL=2.4.1
Then you can be sure that NPTL is not used.0 -
Ok, rebuilt and installed both DB4 and Ice-1.2.0 with: LD_ASSUME_KERNEL=2.4.1.
Same problem (hangs after generating RuntimeException when testing
Ice/exceptions).0 -
Note that the LD_ASSUME_KERNEL is a run-time option, not a compile-time option. So did you set this before you run the tests?0
-
Just to be sure I rebuilt everything again. LD_ASSUME_KERNEL is 2.4.1
LD_LIBRARY_PATH includes both Ice-1.2.0/lib and db4/lib, PATH includes
Ice-1.2.0/bin and db4/bin.
Same problem, same place...0 -
As I wrote above, this is a run-time option, not a compile time option. So did you set it while running the test suite. For example
export LD_ASSUME_KERNEL=2.4.1 python allTests.py
0 -
Sorry, I wasn't clear.
Yes.
However, the Ice-1.2.0 INSTALL_LINUX file cautions that one needs
to set LD_ASSUME_KERNEL when building DB4, hence the reason I went back
and made sure it was also set while building things as well.
Nevertheless, it was still set when running the tests, both for Ice and IceJ.0 -
tests with regular server.
starting server... ok
starting client... ok
testing servant registration exceptions... ok
testing servant locator registration exceptions... ok
testing object factory registration exceptions... ok
testing stringToProxy... ok
testing checked cast... ok
Exception in thread "main" java.lang.RuntimeException
at AllTests.test(AllTests.java:22)
at AllTests.allTests(AllTests.java:809)
at Client.run(Client.java:20)
at Client.main(Client.java:34)catch(Exception ex) { ex.printStackTrace(); // Line 809 test(false); }
If the stack trace doesn't shed any light on the issue, please followup and show us the output.
Thanks,
- Mark0 -
Sorry, that took a while (needed to find and install Ant...).
Here's the new output with the additional stack trace:
tests with regular server.
starting server... ok
starting client... ok
testing servant registration exceptions... ok
testing servant locator registration exceptions... ok
testing object factory registration exceptions... ok
testing stringToProxy... ok
testing checked cast... ok
Ice.UnmarshalOutOfBoundsException
at IceInternal.BasicStream.readSize(BasicStream.java:428)
at IceInternal.BasicStream.readString(BasicStream.java:930)
at IceInternal.BasicStream.throwException(BasicStream.java:1256)
at _ThrowerDelM.throwAasA(_ThrowerDelM.java:95)
at ThrowerPrxHelper.throwAasA(ThrowerPrxHelper.java:148)
at ThrowerPrxHelper.throwAasA(ThrowerPrxHelper.java:134)
at AllTests.allTests(AllTests.java:800)
at Client.run(Client.java:20)
at Client.main(Client.java:34)
Exception in thread "main" java.lang.RuntimeException
at AllTests.test(AllTests.java:22)
at AllTests.allTests(AllTests.java:810)
at Client.run(Client.java:20)
at Client.main(Client.java:34)
0 -
Do you perhaps use different versions of Ice for C++ and Ice for Java? There has been a protocol change (can't remember which version exactly), which might cause this. Perhaps an old Ice for C++ installation is still in your PATH?0
-
No, I don't think so. I had had 1.1.1 installed, but it's gone now. I convert Ice into an
RPM for installation using the 'checkinstall' program, and I think the "rpm -Uvh..."
wiped out the 1.1.1 version. Here's what locate tells me is around:
weaver% locate libIce
/home/opt/Ice-1.2.0/lib/libIceUtil.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceUtil.so.12
/home/opt/Ice-1.2.0/lib/libIceUtil.so
/home/opt/Ice-1.2.0/lib/libIce.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIce.so.12
/home/opt/Ice-1.2.0/lib/libIce.so
/home/opt/Ice-1.2.0/lib/libIceXML.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceXML.so.12
/home/opt/Ice-1.2.0/lib/libIceXML.so
/home/opt/Ice-1.2.0/lib/libIceSSL.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceSSL.so.12
/home/opt/Ice-1.2.0/lib/libIceSSL.so
/home/opt/Ice-1.2.0/lib/libIceBox.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceBox.so.12
/home/opt/Ice-1.2.0/lib/libIceBox.so
/home/opt/Ice-1.2.0/lib/libIceStorm.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceStorm.so.12
/home/opt/Ice-1.2.0/lib/libIceStorm.so
/home/opt/Ice-1.2.0/lib/libIceStormService.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIceStormService.so.12
/home/opt/Ice-1.2.0/lib/libIceStormService.so
/home/opt/Ice-1.2.0/lib/libIcePack.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIcePack.so.12
/home/opt/Ice-1.2.0/lib/libIcePack.so
/home/opt/Ice-1.2.0/lib/libIcePatch.so.1.2.0
/home/opt/Ice-1.2.0/lib/libIcePatch.so.12
/home/opt/Ice-1.2.0/lib/libIcePatch.so
weaver%
..so I don't *think* it's using 1.1.1 anywhere. And my path doesn't have 1.1.1 on it,
either:
/opt/Ice-1.2.0/bin:/opt/db4/bin:.:/opt/java4/bin:/opt/java/jmf/JMF-2.1.1e/bin:/usr/local/bin:\
/usr/X11R6/bin:/opt/bin:/usr/bin:/bin:/usr/openwin/bin:/usr/TeX/bin:/usr/games:/sbin:/usr/sbin:
0 -
Sorry, I didn't look properly. This is a pure Ice for Java test, it will not use Ice for C++.
However, the error still suspiciously looks as if old and new exception marshaling is mixed. What is your CLASSPATH? If you look into the generated Java files for the exception test, what does the header say about the Ice version?0 -
Life is so confusing...
weaver% echo $CLASSPATH
/scr1/atst/ice/IceJ-1.2.0/lib/Ice.jar:/opt/java/jmf/JMF-2.1.1e/lib/jmf.jar:.::/opt/java4/jre/lib/rt.jar
Headers for test/Ice/exceptions/generated/*.java all say "Ice version 1.2.0"0 -
I'm afraid I have no clue what's going wrong here
We use mostly RH9 here, and never had this problem...0 -
Ok - I do appreciate the time you've spent helping!
I guess I'll wipe everything and rebuild from the downloads again.
Out of curiousity, what version of Java are you using with RH9?
Thanks again!0 -
We use both JDK 1.4.1 and 1.4.2.0
-
Steve,
Let us know if you're still having trouble after you've rebuilt, as there are more steps we can take to track down this problem.
- Mark0 -
Far out...
I've found the problem (but can't explain why it's a problem).
I had copied Ice.jar from lib to my java library: /opt/java4/jre/lib/ext.
Removing it from there allows the tests to run to completion.
Adding it there causes the RuntimeException.
Now, why can't I run the tests with the jar file moved?
Note that the exception occurs even if I remove lib/Ice.jar
from my CLASSPATH so that only the Ice.jar in
/opt/java4/jre/lib/ext is used.
Does this imply that I cannot run IceJ with the jar file
located as above - or is this a quirk with the python
test scripts? Is there an easy way to find out?
Thanks!0 -
To make sure it's not the Python scripts, try running the test server and client manually in two separate windows.0
-
Steve,
You can run the test manually to eliminate any question about Python's influence. Simply open two console windows, change to the test/Ice/exceptions directory and start the server in one window and the client in the other.
Server window:
$ java -classpath classes:$CLASSPATH Server
Client window:
$ java -classpath classes:$CLASSPATH Client
These commands assume that Ice.jar is already locatable in your CLASSPATH.
I did have a question about your environment. Were you initially using the Ice.jar file that you downloaded as part of the Ice for Java distribution? If so, have you tried using this JAR file locally (as opposed to in the JDK's extension directory)?
I'm just wondering if it might be a problem with the JAR file we're supplying. However, it sounds like you've built IceJ from sources, and get the same problem when you copy your newly-built JAR file to the extension directory. Is that correct?
- Mark0 -
It's not the scripts. If I run (in separate windows):
java -ea Server --Ice.ProgramName=Server
and
java -ea Client --Ice.ProgramName=Client
I get the same error as long as /opt/java4/jre/lib/ext/Ice.jar exists,
whether nor not IceJ-1.2.0/lib/Ice.jar is in my CLASSPATH.
I have to remove it for the client to run successfully. (Of course,
I then have to have IceJ-1.2.0/lib/Ice.jar in my CLASSPATH.
Odd.0 -
And you are sure the Ice.jar is correct? Can you do a diff between /opt/java4/jre/lib/ext/Ice.jar and IceJ-1.2.0/lib/Ice.jar? Are they the same?0
-
(Sorry, I'm out of sync with your messages - my last reply was based on your
previous reply).
Yes, the problem occurs with both the original Ice.jar in the download and
with the one I built from source.
I'm going to try it in some other local place (I expect it to work!)0 -
Yes, they are the same:
weaver% cp Ice.jar /opt/java4/jre/lib/ext/Ice.jar
weaver% r cmp
cmp Ice.jar /opt/java4/jre/lib/ext/Ice.jar
weaver% pd -classes
/home/swampler/Xfers/Ice/IceJ-1.2.0/test/Ice/exceptions/classes
You have new mail.
weaver% r ja
java -ea Client --Ice.ProgramName=Client
testing servant registration exceptions... ok
testing servant locator registration exceptions... ok
testing object factory registration exceptions... ok
testing stringToProxy... ok
testing checked cast... ok
catching exact types... Exception in thread "main" java.lang.RuntimeException
at AllTests.test(AllTests.java:22)
at AllTests.allTests(AllTests.java:809)
at Client.run(Client.java:20)
at Client.main(Client.java:34)
(and having the Ice.jar file in some other location [eg. /var/tmp/Ice.jar], but on
the CLASSPATH works just fine, as expected...)0 -
Just as a note, I should point out at the the Ice 1.1.1 Ice.jar was perfectly happy
to live in jre/lib/ext, so it's some difference between the two that seems to
be the problem.0