Specific to this platform, test fails with exit code 139, probably due to a SEGV. This test creates a very large Vector object in memory.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 487253
Probably not related to 487253, except that they're both caused by a large Vector object. This one smells like graceless out-of-memory behavior.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Looping in Rishit and Tommy in case it in fact is graceless OOM behavior.
I suspect OOM b/c I developed the test on WIN32 and 250000 elements in the initializer was about all I could get to work without hitting OOM situations on that platform.
linux64 with -Ojit also reproduces the crash. crashes about 2/10 times with a segmentation fault 139. Should return 129 (oom) exit code instead of seg faulting.
Passes in redux 2707 on x86-32 linux (VMWare), both in test harness and standalone, both -Dinterp and -Djitordie.
Passes in redux 2710 on x86-64 linux (VMWare), both in test harness and standalone, both -Dinterp and -Djitordie. Tested repeatedly. Concluding that the error has gone away. Note, had to compile this test from .as to .abc on a different platform, Java on x86-64 (at least my current install) ran out of memory even with 2MB RAM assigned to the VMWare instance. Will remove the exceptions from testconfig.txt and push that.
redux changeset: 2711:5d572c563b87
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 9 years ago
Resolution: --- → FIXED
verified that it is working. Ran abc 1000 time on linux64 without issue, also tested on winmobile device
Status: RESOLVED → VERIFIED
removing QRB request, bug verified
You need to log in before you can comment on or make changes to this bug.