00846d8293d2efd1d339ca6b99fd5a2d08d8c058 |
|
23-Jan-2018 |
Hans Boehm <hboehm@google.com> |
Have CloseGuard report by default "Enabling" CloseGuards now controls capture of the initial stack trace, tracking, and routing of messages to the reporter. We now log a warning for leaked objects, even if CloseGuard is disabled. Since creation of a CloseGuard always allocates a finalizable object, we were paying most of the cost of checking anyway, but throwing away the benefit. The messages generated by default are not currently easily actionable, but do indicate a problem. And they can be made more actionable by passing a more informative "closer" string or by enabling CloseGuard stack capture. Always-on reporting is highly desirable since warnIfOpen() calls are commonly combined with close() calls in the same finalizer. Typically, this is 100% safe in the presence of dead reference elimination by the compiler only if there is an explicit close() call. Otherwise CloseGuard finalization may, with very unlikely scheduling, be invoked while another method on the object is still running. In the unlikely case this happens, we really want a record of it in the log. Make Tracker semantics consistent, instead of conditionally invoking it on open and unconditionally on close. Fix all-caps non-constants. Fix CloseGuardTest to reflect the new expectations. This was split off from go/aog/554024. Bug: 70906684 Test: Build and boot AOSP. cts-tradefed run singleCommand cts -m CtsLibcoreTestCases -t libcore.dalvik.system.CloseGuardTest cts-tradefed run singleCommand cts -m CtsLibcoreTestCases -t libcore.dalvik.system.CloseGuardSupportTest Change-Id: I8a1cfeac963cb5f51fdd27fdf1eb9c0beb309aa4
|
e31b37859051d3902e06e4ba384995df7188917f |
|
02-Dec-2017 |
Hans Boehm <hboehm@google.com> |
Add reachabilityFence, ReachabilitySensitive Add the @ReachabilitySensitive annotation itself, and use it in libcore itself, where needed. Import OpenJDK9+181's reachabilityFence, so that it can be used in preference to the annotation where it makes sense. Java 9's stopgap reachabilityFence implementation doesn't work for us, so replace it with a different stopgap. The libcore changes correct many situations in which finalizers could previously run prematurely according to the JLS. Or they would correct them if we had a real implementation for @ReachabilitySensitive. The ZipFile constructor could close the file before notifying the CloseGuard that it was open. Aside from the ZipFile change, there should be no functional change, yet. Note that the ExemptionMechanism.java fix is the same as upstream. Conspicuously missing: - Any code, e.g. in ART or D8, that actually looks for the annotation. - Uses in frameworks code, where it's probably most critical. Bug: 63934467 Bug: 70906684 Bug: 28342794 Test: Build & boot AOSP Change-Id: I652f0625b39b2ba9ac901d4f63e6aa6cf3b74af5
|
fe0ee8ef8870338ad67ebfb6b62785e0cbdb325b |
|
12-Aug-2016 |
Paul Duffin <paulduffin@google.com> |
Improve resource leakage detection testing This change makes various improvements to the support for testing resource leakage detection. Adds CloseGuard.Tracker to allow tests to track the lifecycle of CloseGuard allocation sites directly. Adds CloseGuardSupport to use CloseGuard.Tracker to provide: * A BiConsumer that can be used to help check that objects which own resources protected by CloseGuard correctly detect resource leakage. * A TestRule that allows tests to check that system code does not leak resources, especially under error conditions. Adds a new ResourceLeakageDetector that uses reflection to access CloseGuardSupport. This can safely be used in code that needs to compile and run on OpenJDK. Adds TestCaseWithRules to allow the TestRule above to be used with JUnit 3 style tests without converting the whole test to JUnit 4 style. Changed libcore.java.lang.ProcessBuilderTest to use TestCase as ProcessBuilder does not have any CloseGuard protected resources. That allows AbstractResourceLeakageDetectorTestCase to be deleted. Changed RandomAccessFileTest to use TestCaseWithRules and ResourceLeakageDetector. Fixed issues that it highlighted, fixed testRandomAccessFileHasCleanupFinalizer test and removed it from expectations/knownfailures.txt. Adds core-test-rules/-hostdex targets to encapsulate TestRule and related classes that can be shared with other projects. Removes the following now unused classes: * CloseGuardMonitor * AbstractResourceLeakageDetectorTest * The old ResourceLeakageDetector and associated test. Bug: 31542223 Test: Ran tests on both Vogar and CTS Change-Id: I8f802b52fdbeac0a30f339a9ceca5d2eaaafd180
|
5edc236b2fa90a655ce1bdd13382d75813dc59d7 |
|
29-Feb-2016 |
Narayan Kamath <narayan@google.com> |
Revert "Fix DatagramChannelTest#test_setOption." This reverts commit 5ece1b52d3269bc9fb6902ce0daac58fd50805ec. This included other random cruft that's unrelated to this change. Change-Id: Ia563a18b2c2d809c2de0615cee9e35b7f89bc7ae
|
5ece1b52d3269bc9fb6902ce0daac58fd50805ec |
|
26-Feb-2016 |
Narayan Kamath <narayan@google.com> |
Fix DatagramChannelTest#test_setOption. The kernel rounds up SO_SNDBUF arguments to convenient values. Also, use SO_SNDBUF instead of SO_LINGER because LINGER will not be supported (which will end up in a different exception being thrown). bug: 27316686 Change-Id: Ibc07cdad62d0e199eccdf9323a4ba22053bc2592
|
a5dd2c63ad7c4ee7d3e042da28f00e6055b781b3 |
|
11-Mar-2015 |
Brian Carlstrom <bdc@google.com> |
Move null check rationale to sample code for clarity Change-Id: Ieceff37477ec3189bda4bcead98aa7e27fcce345
|
ec662a709ad6d45e19d23f2ae357fad96a766c69 |
|
10-Mar-2015 |
Brian Carlstrom <bdc@google.com> |
Revert "Remove unnecessary null checks in CloseGuard documentation sample code" This reverts commit 9a36fbb0df656b18a47048b7d49c09d129f8fcbb. Change-Id: I31f38d46daf7cd28f0d9babd200ee093928c0766
|
9a36fbb0df656b18a47048b7d49c09d129f8fcbb |
|
09-Mar-2015 |
Mike Lockwood <lockwood@google.com> |
Remove unnecessary null checks in CloseGuard documentation sample code guard is final, so it could never be set to null. Change-Id: I514fcb72bd59b50d8a1a7e64a6b1ec82799f9f70
|
8155888a2c4e7cc28596deec28433e1984cfaf11 |
|
25-Jul-2012 |
Brian Carlstrom <bdc@google.com> |
Fix HttpURLConnection CloseGuard warning due to lack of close on GZIPInputStream java.lang.Throwable: Explicit termination method 'end' not called at dalvik.system.CloseGuard.open(CloseGuard.java:184) at java.util.zip.Inflater.<init>(Inflater.java:82) at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:96) at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:81) at libcore.net.http.HttpEngine.initContentStream(HttpEngine.java:523) at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:831) at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274) at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486) at ... Bug: 6602529 Change-Id: I9b49cbca561f8780d08844e566820087fdffc4d7
|
a7ef55258ac71153487357b861c7639d627df82f |
|
22-Feb-2011 |
Elliott Hughes <enh@google.com> |
Simplify internal libcore logging. Expose LOGE and friends for use from Java. This is handy because it lets me use printf debugging even when I've broken String or CharsetEncoder or something equally critical. It also lets us remove internal use of java.util.logging, which is slow and ugly. I've also changed Thread.suspend/resume/stop to actually throw UnsupportedOperationException rather than just logging one and otherwise doing nothing. Bug: 3477960 Change-Id: I0c3f804b1a978bf9911cb4a9bfd90b2466f8798f
|
1292ca6a89af2492f9c1f52f7d4a555c75462482 |
|
19-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
minor CloseGuard javadoc corrections Change-Id: I6892d1f03821032d40b2ea678b9406f464878755
|
4bfc26e99c8044a1d690003d4bb3d75348124f57 |
|
14-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
CloseGuard: make members volatile, update comment Change-Id: Id348a2d523fb92631a07684050b03311a6ea2eef
|
f7ee236589ca1fe73615c4dc8a536ffe29a236ff |
|
08-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
Fix javadoc typo Change-Id: I5e24358c62e00f199c71b9825b1b533b34510f74
|
b81e1d9da6a4b039ffa55618fcccb013d3116261 |
|
08-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
Add CloseGuard.Reporter interface to allow customization of warnings This will be paired with a new implementation in StrictMode to allow more sophisticated reporting. Change-Id: I17668b5db333c4c9b7280ac0de5dc8d9ba1aab59
|
b3f32d4d15177a0d2c064a8116d5cf5d07a217a9 |
|
04-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
Adding CloseGuard.setEnabled for StrictMode integration Bug: 3041575 Change-Id: Ifa8f548c217210014c2aaff044fb4871629f47a7
|
2353846b64570fa5932028143a0af507d41a85c5 |
|
25-Oct-2010 |
Jesse Wilson <jessewilson@google.com> |
Close process-spawned streams when the process is destroyed. This is consistent with the RI's behavior. I can't come up with a reasonable approach to closing these streams if they are never requested; that's presumably a finalizer problem anyway because only the finalizer knows that the streams won't be needed. This change also adds test infrastructure around CloseGuard. My approach hooks into the logger rather than reflection because I can't be sure where the CloseGuard instance would be in the object hierarchy. This approach also degrades reasonably when run on the reference implementation (where it passes). Change-Id: I08e882494d69d4245e40fb1035edbc6d3df23fbc http://b/3111120
|
12f2d8e2760b78c673b7a187b9062b3938a03147 |
|
12-Oct-2010 |
Brian Carlstrom <bdc@google.com> |
Revised CloseGuard usage pattern - CloseGuard.get() instants are now "unopened" - In constructor cases, guard.open("...") is now at the end - In metod cases, guard.open("...") is now after resource acquisition - guard null pointer checks in finalizers in case constructor threw exception Bug: 2645458 Change-Id: Ieb874a8c33b347768a9fa7437b3dd16f3d56d886
|
f7aab022dcbfcd8f27b409ab92b4bca4a84d0b8a |
|
30-Sep-2010 |
Brian Carlstrom <bdc@google.com> |
CloseGuard: finalizers for closeable objects should log complaints Introducing CloseGuard which warns when resources are implictly cleaned up by finalizers when an explicit termination method, to use the Effective Java "Issue 7: Avoid finalizers" terminology, should have been used by the caller. libcore classes that can use CloseGuard now do so. Bug: 3041575 Change-Id: I4a4e3554addaf3075c823feb0a0ff0ad1c1f6196
|