27604018f783bf6354a13870b3e7785edca69b5f |
|
28-Sep-2016 |
Paul Duffin <paulduffin@google.com> |
Detect and fix resource leakages in tests Tests that test those classes that use CloseGuard to detect reosurce leakages are switched to use TestCaseWithRules and ResourceLeakageDetector.getRule() to detect any resource leakages and the leaks fixed. A number of tests could not be fixed due to bugs in the core classes so a new DisableResourceLeakageDetection annotation was added as part of this change. A method annotated with that does not perform resource leakage detection. The affected tests were annotated with a description and a reference to an associated bug. This uses try-with-resources to aid in closing resources. While that does provide some benefits it is all too easy to change the behavior of the test unless care is taken. To avoid that it is important not to merge it with an existing try block such as those which follow the following pattern: try {... fail()} catch(..) {} Merging them could result in the test catching and ignoring exceptions thrown during the creation of the resource which is almost certainly not what the test was intending. Test: Tested with vogar and CTS Bug: 31542223 Change-Id: Id32bb40fe04eb9719d7e6cd367abb53118b21832
|
5ccb2b3621f633708eb3ae1fd0f27f88bdb32a9d |
|
29-Jan-2015 |
Narayan Kamath <narayan@google.com> |
Fix deflater in / out counts for inputs > 4G. The underlying inflate & deflate can process any amount of data correctly, since the protocol is chunk based (the size of each chunk is limited to 32 bits, usually) and there is no limit to the number of chunks. On LP32, the stream counters are limited to 32 bit counts and the manual recommends that the caller maintain their own counters to support larger counts. <quote> Note however that the strm.total_in and strm_total_out counters may be limited to 4 GB. These counters are provided as a convenience and are not used internally by inflate() or deflate(). The application can easily set up its own counters updated after each call of inflate() or deflate() to count beyond 4 GB. </quote> Change-Id: I066e1141935154773360c1b9f94c56bd604f8474
|
b9f4eb77cf7c5937fcd33d839c749900112874bd |
|
07-Jan-2011 |
Jesse Wilson <jessewilson@google.com> |
Don't short-circuit Inflater.inflate() on zero-length requests. Change-Id: I2d207ee16dd432ba4211990da21a345f81375039 http://code.google.com/p/android/issues/detail?id=11755
|
aee3e4d2e0a2830fc2ef8e96a13796d012becab2 |
|
07-Dec-2010 |
Elliott Hughes <enh@google.com> |
Throw better exceptions if an Inflater or Deflater is used after calling end. Bug: 3217912 Change-Id: I480c92d2f97b530f17b9b8daf2549d2f06384219
|
2d9c5fa8ce0182cd8c14736241b709fd50cab6f8 |
|
23-Nov-2010 |
Elliott Hughes <enh@google.com> |
Slight cleanup of java.util.zip code, plus a bug fix. The key fix is switching to zstream's next_in and next_out fields (the pointers into the input and output buffers) rather than relying on the integer "accounting" fields. If turns out in the Z_NEED_DICT case that the accounting goes slightly awry. (We shouldn't have been using the accounting anyway, because we were silently coercing longs to ints.) The new code is simpler, clearer, and doesn't need a special case for Z_NEED_DICT at all. I've also removed yet another hand-written UTF-8 encoder, made Inflater throw ArrayIndexOutOfBoundsExceptions with useful detail messages (factored out into Arrays so we can make this change more widely), and rewritten the Inflater and Deflater documentation. The unit test reproduces the problem (and tests as many other cases as it can too). Critical for testing this bug is that we needed to limit the size of the input buffer so that zlib has to ask us for more input. Bug: 3220923 Change-Id: I39e5456620eaa7f75d12d885db279f009ee3e8ef
|