I run NetBeans IDE 3.3.1 RC3 (Build 200201280331) on
Java VM: Java HotSpot(TM) Client VM (1.4.0-rc-b91 mixed mode)
using my RH7.1 linux 2.4.10 SMP (2CPU).
--------------------------------------------------------------

Sometimes happens that JVM crashes without any reason.
And it happens more then it is healthy (so that's why I decide filling a bug) and happend with previous NB 3.3.1 builds and I think that happened also with
jdk1.4.0 b90 (/89)

It left usualy output on screen ending with this:

#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002D3
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-rc-b91 mixed mode)

plus core dump (more then 200MB-not attached)) and some hd log (attached)

VTest failed with -server flag after 26 hours 54 minutes with hopper b06.
stack trace shows it's a crash in GC.
> ---- called from signal handler with signal 10 (SIGBUS) ------
> [8] MarkSweep::follow_root(0xfe614fa8, 0xfe614fa8, 0xff2ba008, 0xff241a54,
> 0x310ec0, 0x0), at 0xfe0e0e30
> [9] Universe::oops_do(0xfe601fa8, 0x0, 0xee270000, 0x0, 0x1, 0xffbeeb00), at
> 0xfe22523c
> [10] GenCollectedHeap::process_strong_roots(0x8c3a8, 0x1, 0x0, 0x1, 0x2,
> 0xfe601fa8), at 0xfe2246e4
> [11] MarkSweep::mark_sweep_phase1(0x1, 0xfa38183c, 0x0, 0x4e61d8,
0xfe49e330,
> 0xfe4c344c), at 0xfe265ca8
> [12] MarkSweep::invoke_at_safepoint(0x5c00, 0x5f48, 0x4c00, 0x5400, 0x54c8,
> 0x4f88), at 0xfe49e438
> [13] OneContigSpaceCardGeneration::collect(0x8c5e8, 0x0, 0x0, 0x0, 0x0,
0x0),
> at 0xfe26a898
> [14] GenCollectedHeap::do_collection(0x0, 0x1, 0x0, 0xfe62a268, 0xfe5aa000,
> 0x1), at 0xfe22ebac
> [15] TwoGenerationCollectorPolicy::satisfy_failed_allocation(0x8c3a8, 0x4,
> 0x0, 0x0, 0xe6b815e0, 0xfa381ad0), at 0xfe234930
> [16] VM_GenCollectForAllocation::doit(0xe6b815c0, 0x5000, 0x381bbc,
> 0xfe605638, 0xfe5aa000, 0x0), at 0xfe234b0c
> [17] VM_Operation::evaluate(0xe6b815c0, 0x0, 0x381690, 0xfe628e08,
0xfe6202f0,
> 0x0), at 0xfe2284c0
> [18] VMThread::evaluate_operation(0xd5790, 0xe6b815c0, 0x0, 0x28de8,
> 0xfe2c2138, 0x0), at 0xfe2289e4
> [19] VMThread::loop(0xfe61bc50, 0xfe605870, 0xfe60586c, 0x0, 0x0, 0x0), at
> 0xfe2c21a4
> [20] VMThread::run(0xd5790, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe2c11dc
> [21] _start(0xd5790, 0xff37f690, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe243684

To reproduce the bug:
Execute from command line
1. telnet to ultraowl
2. export JAVA_HOME=<your jdk>
    export JAVA_ARGS="-server"
3. cp -r /net/mooncake/export/bigapps/bigapps_commandline/vtest /tmp/vtest
4. cd /tmp/vtest
5. start the server run.server
6. run the client in an endless loop
while true; do
run.vtest.client
done

Alternatively, you can execute test script if you are familiar with bigapps scripts,
1. telnet to ultraowl
2. export JAVA_HOME=<jdk>
3. /bs/runvtest.ksh -server

###@###.### 2002-03-22

I also got the now-familiar GC looking crash in swingmark for 64 bit in
Apr 9th main/baseline with runThese.

###@###.### 2002-04-09