| d4b7449574ca69c713a3f2230cb77c68ee642700 |
|
06-Sep-2016 |
Tobias Thierer <tobiast@google.com> |
Fix 58 libcore tests that caught "expected" Exceptions but didn't fail()
There were no changes to code under test.
4 tests were fixed to not tolerate an Exception:
- libcore.java.util.CollectionsTest#test_CheckedMap_computeIfAbsent
In the case where a Map key is present, computeIfAbsent() should
not invoke the Function, so there is no return value that could
be expected to undergo a type check. The test was changed to
verify that the Function is not invoked.
- libcore.java.util.concurrent.CopyOnWriteArrayListTest#test_sort and
libcore.java.util.concurrent.CopyOnWriteArrayListTest#test_subList_sort
were sorting an already-sorted non-null list that contains no null
values. That logic was redundant and wouldn't have thrown.
- org.apache.harmony.security.tests.java.security.KeyStoreSpiTest#test_engineEntryInstanceOf
(the KeyStoreSpi documentation does not mention whether NPE is thrown;
the implementation comes from upstream and does not throw it).
54 tests were fixed by adding the missing
fail();
No attempt was made to make this failure message specific to the
exception that was expected.
Tests that weren't changed:
- SSLEngineTest.test_wrap_ByteBuffer_ByteBuffer_04() requires
investigation to determine the correct resolution.
A comment was added to the test linking to the corresponding bug.
- ThreadTest#testParkUntilWithUnderflowValue() and
OldNodeChangeEventTest.waitForEvent() were not touched since
it was not clear whether that it was relevent to the test whether
or not the exception was thrown.
- two cases in Files2Test#test_setPosixFilePermissions_NPE() are
left to a future CL
Test:
(croot; make vogar core-tests) \
&& git diff aosp/master --name-only | xargs vogar `cparg core-tests`
Change-Id: I1cd3220a06e331ff049b146b393f78879f07211a
|
| 5e5169a394fd431609c3419bb4052e71dc73fed3 |
|
17-Aug-2016 |
Tobias Thierer <tobiast@google.com> |
Speed up needlessly slow libcore CTS tests
On a Nexus 6P,
run cts -p android.core.tests.libcore.package.libcore
currently runs for about 20 minutes. This consists of
two runs (arm32 and arm64 runtimes) that involved 587sec
each spent running the set of test methods.
This CL speeds up the test methods that ran the longest
(11-21sec per method) as measured by comparing wallclock
timestamps in a CTS run. The speedup is about 10% (59sec
faster per run, to now 528sec per run).
The speedup is achieved by Thread.sleep()ing for shorter
in tests that slept for what appeared like excessive
amounts of time, and by decreasing data sizes / loop counts
for probabilistic tests for race conditions. There was no
evidence apparent that these had found any bugs in years,
so needing to run them more often to find a potential bug
appears like a fair trade-off for a 10% speedup.
Test: run cts -p android.core.tests.libcore.package.libcore
(ran this three times)
Bug: 30948560
Change-Id: I9b28ce60268746b3a5edfc5b94dcc2ec29c8feca
|
| 161ab7af0434978ad3a9512293a032861a18e16e |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
(cherry picked from commit cf3d432790a78b7d81da656f9a666f3d1ce4962c)
Change-Id: I3cefd317e23c602c6c74dd866f0831161ef10962
(cherry picked from commit 8210c23a598b363e89d6cd32dedeeae673bf9212)
|
| 8210c23a598b363e89d6cd32dedeeae673bf9212 |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
(cherry picked from commit cf3d432790a78b7d81da656f9a666f3d1ce4962c)
Change-Id: I3cefd317e23c602c6c74dd866f0831161ef10962
|
| cf3d432790a78b7d81da656f9a666f3d1ce4962c |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
Change-Id: I0027d86ea1a6964bee43fde958b68fe4d21cb0ff
|
| 3edd28a92fc86a1260347d0995e65a815d73bbbe |
|
16-Apr-2012 |
Mattias Petersson <mattias.petersson@sonymobile.com> |
Fix problem with Runtime.runFinalization()
This is a fix for a problem with runFinalization(). The
problem was that all FinalizerReferences to objects that had
not yet been garbage collected were lost when calling this
function. When a FinalizerReference was lost, it is was not
possible to call the finalize() method when the object
was garbage collected.
The result was that finalizers was sometimes never
called, which typically lead to memory leaks.
Also stop synchronizing on the class itself; use a private
lock instead.
Bug: 6907299
Bug: 5462944 # Synchronization on FinalizerReference.class
Change-Id: Ief515edbb5a1823c06d7371415d131165baef7f2
|
| 1a9cff8f68deffd618c5cba1f22f0fb0e396e067 |
|
17-Nov-2011 |
Jesse Wilson <jessewilson@google.com> |
Always trigger finalization the same way in our tests.
This came up when I was recently writing a ZipFile finalization test
and I needed to copy-paste the finalizer recipe.
Change-Id: Ia67061b3dba1a7011c93c9a81e2a963876b238a1
|
| 29e0638aca737dd1093dac55216982b5af7d59a7 |
|
12-Aug-2011 |
Jesse Wilson <jessewilson@google.com> |
Scrub some CTS test failures.
Change-Id: Icc35a44bac6481b549a96d0533770d11aff507da
|
| 9429d06c5427a6cac499ba90f138afac006135a2 |
|
21-Jun-2011 |
Jesse Wilson <jessewilson@google.com> |
Fix System.runFinalization() to avoid running indefinitely.
This also avoids problems where System.runFinalization() calls
Thread.interrupt() and interrupts a finalizer that is doing
some I/O.
Change-Id: I8de88d7382f684798737ecd19b90d306d9590f1c
http://b/4193517
|
| 64c6c367497c7fcf88e7527022234043e4460758 |
|
21-Jun-2011 |
Jesse Wilson <jessewilson@google.com> |
Implement the finalizer watchdog.
Change-Id: Ia4aaf5f0ef5a2f5f7e6ec3e8b4c4e300c9e1b2ee
http://b/4144865
|
| 6a22fa91a64739523c1344023f6dfde57e53110e |
|
31-Mar-2011 |
Jesse Wilson <jessewilson@google.com> |
Fix race conditions in finalizers.
We had several small races:
- runFinalization() could return before all objects had been
finalized
- stopFinalizer() could return before the thread was stopped
We still have one scenario where runFinalization returns
prematurely, this is due to a timing issue with the native
heap worker thread.
Change-Id: I304e4f2d744ed714a5c2069f2749df2ec1f40cc8
http://b/4192343
|