I'm running into what appears to be a memory smash in the java VM. This
problem first appeared in the HotJava Views product but I have been able to narrow the problem down to a simple program that contains no View's code. The problem manifests itself by causing the runtime to crash:

aha: ./v2
CLASSPATH is set to: .:/net/aha.eng/work/test/foo.jar:/net/aha.eng/work/test/foo.jar:/net/aha.eng/work/test/foo.jar:/usr/local/java/jdk1.1.6/solaris/librt.jar:/usr/local/java/jdk1.1.6/solaris/lib/i18n.jar:/usr/local/java/jdk1.1.6/solaris/classes:/usr/local/java/jdk1.1.6/solaris/lib/classes.zip
SIGSEGV 11* segmentation violation
    si_signo [11]: SIGSEGV 11* segmentation violation
    si_errno [0]: Error 0
    si_code [1]: SEGV_MAPERR [addr: 0x4]

        stackbase=EFFFE880, stackpointer=EFFFE628

Full thread dump:
    "Finalizer thread" (TID:0xee700208, sys_thread_t:0xee2c1db8, state:R) prio=1
    "Async Garbage Collector" (TID:0xee700250, sys_thread_t:0xee2f1db8, state:R) prio=1
    "Idle thread" (TID:0xee700298, sys_thread_t:0xee3c1db8, state:R) prio=0
    "Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12
    "main" (TID:0xee7000b0, sys_thread_t:0x73b40, state:R) prio=5Segmentation Fault

The script that causes the crash has been attached to this bug. The bug is
tickled by the contents of the CLASSPATH. Specifically in this case the
inclusion of foo.jar three times:

[from the attached script]
JAVA_HOME=/usr/local/java/jdk1.1.6/solaris

JAR1=/net/aha.eng/work/test/foo.jar
JAR2=/net/aha.eng/work/test/foo.jar
JAR3=/net/aha.eng/work/test/foo.jar

CLASSPATH=.:$JAR1:$JAR2:$JAR3:$JAVA_HOME/librt.jar:$JAVA_HOME/lib/i18n.jar:$JAVA_HOME/classes:$JAVA_HOME/lib/classes.zip

If I were to remove JAR3 from the script the crash does not occur. It should
be noted that foo.jar only contains a directory:

aha: jar -tf /net/aha.eng/work/test/foo.jar
META-INF/MANIFEST.MF
foo/

The contents of the jar file doesn't seem to matter. In the case of Views
crashing we had a CLASSPATH with more than six different jar files specified
and it crashed in the same way.

There is one really strange thing about this bug. We have only been able
to reproduce this if your default shell is ksh and you are running in CDE.
Starting in csh and then running ksh doesn't do it. If you bring up CDE
with ksh as your default shell (and you can reproduce the problem) and then
rsh to your own machine the problem goes away. It's very strange. We've
done checks and we can't find anything different between the environments.