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

Comments

  • marc
    marc Florida
    Try setting the following:

    export LD_ASSUME_KERNEL=2.4.1

    Then you can be sure that NPTL is not used.
  • 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).
  • marc
    marc Florida
    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?
  • 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...
  • marc
    marc Florida
    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
    
  • 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.
  • mes
    mes California
    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)
    It's not uncommon for an exception to cause the test to hang, but we need to find out what caused the exception. Please modify test/Ice/exceptions/AllTests.java and add a line to print the exception's stack trace, as shown below:
            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,
    - Mark
  • 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)
  • marc
    marc Florida
    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?
  • 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:
  • marc
    marc Florida
    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?
  • 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"
  • marc
    marc Florida
    I'm afraid I have no clue what's going wrong here :(

    We use mostly RH9 here, and never had this problem...
  • 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!
  • marc
    marc Florida
    We use both JDK 1.4.1 and 1.4.2.
  • mes
    mes California
    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.

    - Mark
  • 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!
  • marc
    marc Florida
    To make sure it's not the Python scripts, try running the test server and client manually in two separate windows.
  • mes
    mes California
    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?

    - Mark
  • 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.
  • marc
    marc Florida
    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?
  • (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!)
  • 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...)
  • 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.