-
Bug
-
Resolution: Cannot Reproduce
-
P3
-
None
-
6
-
generic
-
generic
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.
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.