A DESCRIPTION OF THE REGRESSION :
During the redisplay of GPS data, the program mysteriously segfaults.
According to the dump, all MY threads are blocked. There is one, or 2 java threads that seem to be running.



REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
In general, i just start up the reenactment of a GPS data log. The failure tends to be closely related on how often the awt frame is updated with new map info. After a while, the segfault just happens.

the dump just does not give me a hint at what was going on when it faulted. It probably does not give sun to what the faults is either ( no java stack trace ).

I have tried to enter this issue into the bug data base, but it appears that the gate-keepers insist that a test case should be figured out.  It would be easier for me to just "gdb java" an await for a segfault, and then backtrack. But this might require a license, which still has a bad burn to it.

Since this contest does not require a test case ( although this form seems to insist on it ), maybe there is a way to get some cooperative effort in resolving this linux/segfault.  Maybe even have the gate-keepers allow segfaults to be passed up-stairs without a test-case.

RELEASE LAST WORKED:
5.0

RELEASE TEST FAILS:
mustang-b70

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I dont expect a segfault.
ACTUAL -

See attached file 648938.rtf

APPLICATION NAME: jGPS	APPLICATION VERSION: 1.

OBSERVED APPLICATION IMPACT:
random segfaults, besides annoying, tend to undermine the ability of an interpreter to demonstrate stability under adverse situations.

Although the segfaults appear to be the same, they dont happen at an exact time, or spot. This, i suppose, is due to the running of threads.

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
Posted Date : 2006-02-27 17:12:42.0

N/A

This test program failed during verify before GC (see comments).  Also the
test program failed 4 out of 5 times with b70 and passed 9 out of 9 times
with b76.
Posted Date : 2006-03-24 04:15:22.0

I've run this test with the b70 VM in a b76 jdk 4 times without
seeing a failure.  This looks like it was a non-VM problem tha
has been fixed by b76.

Waiting for verification from customer that they do not see the
crash with b76.
Posted Date : 2006-03-28 14:25:37.0

Received this update from the customer (though Jon Lee).

"I have been trying the various binary snapshots that are still available on sun's website. b76 did not fail. b73 did not fail."

I'm closing this as not reproducible.
Posted Date : 2006-04-03 22:25:03.0

I suppose I'm a bit confused with the terminology. The evaluation did show that this was reproducible. At least with some versions of the snapshots. It appears that the bug is *no longer reproducible*, and you dont know what the original failure was.  Sort of a misleading labeling. 

Bugs can be closed as "not reproducible" if they are not reproducible
in the latest build.  "not reproducible" is just the short hand used for
that case.  It's also used for the case where the failure was never
reproducible in any build.    The  precise circumstances usually is
found in the evaluation.