summaryrefslogtreecommitdiffstats
path: root/expectations/knownfailures.txt
Commit message (Collapse)AuthorAgeFilesLines
* expectations: add SSL_renegotiate tests to known failuresSergio Giro2015-06-231-0/+9
| | | | | | | | | | SSL_renegotiate was deprecated and is currently a no-op. We need to rewrite tests for the client response to renegotiation. Bug: 21876068 Bug: 21875889 Change-Id: I8c228cc4d6a388ca740316aa970fd54755b22bb1 (cherry picked from commit 7f3c9cd05a61da205137195e115135a66eb8f6a6)
* Add test_PacketSocketAddress to the list of known failures.Narayan Kamath2015-06-011-0/+8
| | | | | | | | | | | Needs CAP_NET_RAW which means it can only ever run successfully as root. bug: 19764047 (cherry picked from commit 676fbcf150d23bb81da6dccd40bcd085a2eeee8a) Change-Id: I6c24cb9a781340d4c92fb53aa2670ddb99031c73
* resolved conflicts for merge of 72b26859 to lmp-mr1-ub-devNeil Fuller2015-05-261-0/+8
|\ | | | | | | Change-Id: Id188dacbfd8e83fd884f838e392444890a231e5e
| * Suppress a couple of tests that need quite a lot of memoryNeil Fuller2015-05-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | These tests fail on some Android Watch devices. Suppressing them until we have a mechanism to detect low memory devices that would allow them to be suppressed more selectively. Bug: 20055487 (cherry-picked from commit fcee6ab5383ee0ad68fcc74ced7581a24d2521de) Change-Id: I53792de9081774b36d03f2de718e73a1c6ff32d5
| * Revert "Suppress zip & spdy tests that are OOMing with a 48MB max heap."Narayan Kamath2014-11-241-15/+0
| | | | | | | | | | | | This reverts commit 15e853493f013a5397288088c20354e2bd436a5a. bug: 18256012
| * am fd7ab0e2: Merge "Suppress zip & spdy tests that are OOMing with a 48MB ↵Narayan Kamath2014-11-241-0/+15
| |\ | | | | | | | | | | | | | | | | | | max heap." into lmp-sprout-dev * commit 'fd7ab0e2f9626ca5233eea7373e99e3fbd4e83f1': Suppress zip & spdy tests that are OOMing with a 48MB max heap.
| | * Suppress zip & spdy tests that are OOMing with a 48MB max heap.Narayan Kamath2014-11-211-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some of these tests allocate only about 2mb of ram, so we need to analyze the state of the heap to figure out where this memory is going. bug: 18256012 Change-Id: I11ed892d9798bb24d7e5cedc7e93e9c8e7afe80d
| * | Suppress okhttp's ResponseCacheAdapterTest.Takayuki Hoshi2014-11-071-0/+1
| |/ | | | | | | | | | | | | This avoids a known SPDY issue that sometimes makes the related CTS tests fail. Bug: 18066923 Change-Id: I9540dc3ad6b6a3d7ab37eb77d46dba39b7bbbb7b
* | Update test expectations after rename.Narayan Kamath2015-04-031-3/+3
| | | | | | | | | | | | Zip64 tests were moved to Zip64FileTest. Change-Id: I653e63268e174d4f70e8eecd2d5535fbf6556588
* | Implement zip64 support for ZipFile/ZipInputStream/ZipOutputStream.Narayan Kamath2015-02-271-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several open questions that I hope to resolve in future changes : - Our heuristics for detecting whether a zip outputstream should switch over to zip64 or not are imprecise. - Also, given that we now officially support zip64, we have to assume new entries whose size is unknown need the zip64 header / footer. This will make output files slightly larger and less compatible with older tools. If we don't do this, we'll have to go back and rewrite & compact parts of the stream we'd already flushed, which isn't always possible. The other option is to assume zip32 for streams of unknown length and throw if more than 4G of data is written to them. Change-Id: Ibb4a97b5f83fd3ab850d7c407ecfda663968a6b9
* | Fix the infinite loop issue of the conversion from string to doubleJingwei Zhang2015-01-231-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provide the additional check for “z”. The “if” statement checks whether the double precision value z, is at the end of a binade (a term used to describe the set of numbers in a binary IEEE 754 floating-point format that all have the same exponent, i.e., a binade is the interval [2n, 2n+1) for some value of n.) If so, it needs to adjust for the change of ulp (unit of least precision is the spacing between two consecutive floating-point numbers, i.e., the value the least significant digit represents if it is 1). The adjustment is done by the “simpleShiftLeftHighPrecision” routine. This is all necessary, except when z is close to denormal (i.e. DOUBLE_TO_LONGBITS(z)==DOUBLE_NORMAL_MASK) where no adjustment is needed since the ulp should remain the same once z becomes denormal. This means we can remove the old hack that counted how many times we'd incremented or decremented, so this patch removes the DECREMENT_DOUBLE and INCREMENT_DOUBLE macros. This patch also contains the float equivalent of everything mentioned above, plus some new tests. Finally, this patch removes the USE_LL conditional compilation because it was always true. Bug: 18087920 Change-Id: I4a9112f012dfd9eeb8db89f0652528b6c02e8f1e Signed-off-by: Jingwei Zhang <jingwei.zhang@intel.com> Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
* | Merge "Add a unit test to demonstrate ICU CharsetProvider problems"Narayan Kamath2015-01-201-0/+7
|\ \
| * | Add a unit test to demonstrate ICU CharsetProvider problemsNarayan Kamath2015-01-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Also add a single FakeCharsetProvider for unit tests that does nothing by default, so that we can stub it in for tests that do care about it and none of our other tests are affected. Change-Id: I03abb8f1aff53c160935b4cdbeaef764d30f240a
* | | Changes needed to support OkHttp upgradeNeil Fuller2015-01-201-39/+4
|/ / | | | | | | Change-Id: Ifd6ed8ab22e7fd5d8cb8c9eb28976291d125c0e4
* | Update expectations of cbrt test.Nicolas Geoffray2014-12-031-0/+9
| | | | | | | | Change-Id: Ic89252d1379ba25f46b8dc06833ab9bbe769c846
* | Update expectations for host.Nicolas Geoffray2014-11-271-0/+23
| | | | | | | | Change-Id: Idd63b469726a1b6529d3aed931f02024ba04b903
* | am bc1ea657: Suppress failing OkHttp CTS testsNeil Fuller2014-10-151-0/+13
|\ \ | |/ | | | | | | * commit 'bc1ea6573c76663718d441f7b0b849a91f3eefbd': Suppress failing OkHttp CTS tests
| * Suppress failing OkHttp CTS testsNeil Fuller2014-10-131-0/+13
| | | | | | | | | | | | | | | | Added an additional regression test for SSLSocketTest. Bug: 17962997 Bug: 17750026 Change-Id: Ic1171a916a8dbfe4f0ae486d650583de2547175b
| * Rewrite tests and add tests that demonstrate a bugNeil Fuller2014-09-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug: DecimalFormat.format() behavior is slightly lossy around 15 decimal digits even without any digit constraints. This change isolates the test failures that result from this bug to 2 test cases: test_formatDouble_bug17656132 test_formatDouble_roundingProblemCases Example of the bug: Double: 999999999999999.9 is represented as an IEEE 754 value which is exactly decimal 999999999999999.875 When format(999999999999999.9) is called on a DecimalFormat with large MaxIntegerDigit and MaxFractionDigit.... Correct answer: "999999999999999.9" Actual answer: "1000000000000000" By contrast Double.toString() prints 9.999999999999999E14 for Android and the RI (correctly). The DecimalFormat is printing to 16 decimal digits: The inclusion of the 16th digit implies slightly more precision than IEEE 754 provides (~15.9 decimal digits for most of the representable range). However, the use of 16 decimal digits for outputting IEEE 754 appears consistent with Double.toString() and elsewhere. Before printing, DecimalFormat appears to be rounding to 15 decimal digits internally (or something similar). Parsing "1000000000000000" produces a different double representation than the original double (one that is closer to 1000000000000000 than 999999999999999.9). This is the bug - we just lost information. We should be able to round-trip a double if there is no rounding since every double is representable with decimal and we have sufficient digits available to represent it (close enough) in decimal. Additional tests have been added to demonstrate the bug and also demonstrate the (correct) formatting behavior when the formatter is rounding. test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits after the dp. test_formatDouble_roundingTo15Digits: rounding at 15 total digits overall test_formatDouble_bug17656132: Demonstrates the bug concisely. The test changes: test_formatDouble_wideRange(): implicitly assumed that the any loss of accuracy when a decimal string was turned into a double would be undone when format() was called, and it would always arrive back at the original string. The test has been re-written here to use BigDecimal rather than Double.parseDouble(), and to compare two doubles rather than original string with the output from format(). The test was previously failing with the RI for 1E23: the closest representable double to 1E23 is exactly 99999999999999991611392. The value produces "99999999999999990000000" when formatted with the RI and not "100000000000000000000000". On Android it was passing for 1E23 because of bug 17656132 rounding back to the original decimal value. This test was previously failing on Android with 1E-309 because below 1E-308 IEEE 754 starts losing precision and the closest representable value is not close to the original string. The test now isn't affected if the double being tested is not close to the original decimal; it passes providing the can be round tripped. test_formatDouble_roundingProblemCases: Re-written like the _wideRange test but continues to demonstrate the bug due to the test values (intentionally) chosen. Bug: 17656132 (cherry picked from commit 4e92b6265acb1d12109e311819dd64b27ec85df5) Change-Id: I0b3245d8984999b2731508bb90de785492bb211b
* | am 972b7282: Merge "Rewrite tests and add tests that demonstrate a bug"Neil Fuller2014-09-261-0/+8
|\ \ | | | | | | | | | | | | * commit '972b728220e3d85eb549aa3451e872f5a06e25c1': Rewrite tests and add tests that demonstrate a bug
| * | Rewrite tests and add tests that demonstrate a bugNeil Fuller2014-09-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug: DecimalFormat.format() behavior is slightly lossy around 15 decimal digits even without any digit constraints. This change isolates the test failures that result from this bug to 2 test cases: test_formatDouble_bug17656132 test_formatDouble_roundingProblemCases Example of the bug: Double: 999999999999999.9 is represented as an IEEE 754 value which is exactly decimal 999999999999999.875 When format(999999999999999.9) is called on a DecimalFormat with large MaxIntegerDigit and MaxFractionDigit.... Correct answer: "999999999999999.9" Actual answer: "1000000000000000" By contrast Double.toString() prints 9.999999999999999E14 for Android and the RI (correctly). The DecimalFormat is printing to 16 decimal digits: The inclusion of the 16th digit implies slightly more precision than IEEE 754 provides (~15.9 decimal digits for most of the representable range). However, the use of 16 decimal digits for outputting IEEE 754 appears consistent with Double.toString() and elsewhere. Before printing, DecimalFormat appears to be rounding to 15 decimal digits internally (or something similar). Parsing "1000000000000000" produces a different double representation than the original double (one that is closer to 1000000000000000 than 999999999999999.9). This is the bug - we just lost information. We should be able to round-trip a double if there is no rounding since every double is representable with decimal and we have sufficient digits available to represent it (close enough) in decimal. Additional tests have been added to demonstrate the bug and also demonstrate the (correct) formatting behavior when the formatter is rounding. test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits after the dp. test_formatDouble_roundingTo15Digits: rounding at 15 total digits overall test_formatDouble_bug17656132: Demonstrates the bug concisely. The test changes: test_formatDouble_wideRange(): implicitly assumed that the any loss of accuracy when a decimal string was turned into a double would be undone when format() was called, and it would always arrive back at the original string. The test has been re-written here to use BigDecimal rather than Double.parseDouble(), and to compare two doubles rather than original string with the output from format(). The test was previously failing with the RI for 1E23: the closest representable double to 1E23 is exactly 99999999999999991611392. The value produces "99999999999999990000000" when formatted with the RI and not "100000000000000000000000". On Android it was passing for 1E23 because of bug 17656132 rounding back to the original decimal value. This test was previously failing on Android with 1E-309 because below 1E-308 IEEE 754 starts losing precision and the closest representable value is not close to the original string. The test now isn't affected if the double being tested is not close to the original decimal; it passes providing the can be round tripped. test_formatDouble_roundingProblemCases: Re-written like the _wideRange test but continues to demonstrate the bug due to the test values (intentionally) chosen. Bug: 17656132 Change-Id: I7d81e38bd1f9dbfd1e1b2caa60a6bb16b871b925
| * | Mark ↵Elliott Hughes2014-09-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure. The good news is that for the first time we understand why this is failing. Too big to fix for L though, and not a regression. Bug: 17374604 (cherry-picked from commit f887ab7ef74d3ca821aca63ccee2c86cc6a42489) Change-Id: I589fe2eae0643e07e8db8cbcc7df52563aa24604
* | | am 8d848927: am 82404753: Merge "Suppress ConnectionTest: It uses SPDY, ↵Neil Fuller2014-09-111-0/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | which can cause IllegalStateException" into lmp-dev * commit '8d848927c29aa2c71809435aeea78a3555842566': Suppress ConnectionTest: It uses SPDY, which can cause IllegalStateException
| * | Suppress ConnectionTest: It uses SPDY, which can cause IllegalStateExceptionNeil Fuller2014-09-111-0/+1
| | | | | | | | | | | | | | | | | | Bug: 17313155 Bug: 14462336 Change-Id: I4b2f09e197f6ccb7fc6bd0a901095919d011d3e8
* | | Remove an erroneous double-merge in the knownfailures.txt fileNeil Fuller2014-09-091-17/+0
| | | | | | | | | | | | | | | | | | | | | The original change in AOSP/master and the patch of the same change in lmp-dev created a monster. Change-Id: Ib6644022384e03b0dc9a268bb3926505adfccfd6
* | | am bcc98757: am d4bbc220: Merge "Suppress broken apache-harmony beans CTS ↵Neil Fuller2014-09-091-0/+17
|\ \ \ | |/ / | | | | | | | | | | | | | | | tests" into lmp-dev * commit 'bcc9875756c27187ff332f855102657411346cd7': Suppress broken apache-harmony beans CTS tests
| * | Suppress broken apache-harmony beans CTS testsNeil Fuller2014-09-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the apache-harmony serialization tests is package-sensitive. The other tests suppressed probably broke due to a fix in the Android fork of harmony (commit 19a270e90b1e992c1f6639f355ae13564c2f3a6a). The code may be incorrect but if so it has been broken subtly since Dec 2010. Bug 17433734 has been created to investigate. Bug: 17394106 (cherry picked from commit e9121d6ce39668597349e818135214adc92285e5) Change-Id: Ia53e9390c153f8fc7110c360ac635b4ef8fd783c
| * | Suppress one more apache-harmony sql testNeil Fuller2014-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test is broken and is being suppressed: com.android.org.apache.harmony.sql.tests.java.sql.DataTruncationTest Bug: 17342415 (cherry picked from commit 51ff72e84d7f862fc4193dbc747de07cd30e5226) Change-Id: I811a6c032d7c73e77c67d94d47639a6d806b7238
* | | am 2ead7d19: Merge "Suppress one more apache-harmony sql test"Neil Fuller2014-09-091-0/+1
|\ \ \ | | |/ | |/| | | | | | | * commit '2ead7d19c4fe15fbe4dff32866204de6d4c9835c': Suppress one more apache-harmony sql test
| * | Suppress one more apache-harmony sql testNeil Fuller2014-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The test is broken and is being suppressed: com.android.org.apache.harmony.sql.tests.java.sql.DataTruncationTest Bug: 17342415 Change-Id: I5dd2f506400fff7c290e27adf4d3bd34f0624044
* | | am b7ddd5ec: Merge "Suppress broken apache-harmony beans CTS tests"Neil Fuller2014-09-091-0/+17
|\ \ \ | |/ / | | | | | | | | | * commit 'b7ddd5ec95ffc8fb698bbcf5cf07aadf528c2cac': Suppress broken apache-harmony beans CTS tests
| * | Suppress broken apache-harmony beans CTS testsNeil Fuller2014-09-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the apache-harmony serialization tests is package-sensitive. The other tests suppressed probably broke due to a fix in the Android fork of harmony (commit 19a270e90b1e992c1f6639f355ae13564c2f3a6a). The code may be incorrect but if so it has been broken subtly since Dec 2010. Bug 17433734 has been created to investigate. Bug: 17394106 Change-Id: I654d82b607e5487e0e6614ec4bcc5be98a9394e9
* | | am c5952ec0: am 2b26994c: Merge "Mark ↵Elliott Hughes2014-09-081-0/+7
|\ \ \ | | |/ | |/| | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure." into lmp-dev * commit 'c5952ec0d8c4c5a4e3fa01081871c2b549782986': Mark libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure.
| * | Mark ↵Elliott Hughes2014-09-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure. The good news is that for the first time we understand why this is failing. Too big to fix for L though, and not a regression. Bug: 17374604 Change-Id: If9c221ec9e3a401c4ce9a3de4ff8b7c0e747e814
| * | Suppress broken apache-harmony logging CTS testsNeil Fuller2014-09-031-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add test suppression entries for differences known to be caused by Android changes and failures that involve java code fixes. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. java package fixes will be applied via a separate commit. Bug: 13882147 (cherry picked from commit 3b24d91a6c079234f36ca5cbf862eb975cd5fb4a) Change-Id: I45fc103f20ab430b8924174a690c49bee4083f0f
| * | Suppressing broken java.sql apache harmony tests.Neil Fuller2014-09-031-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are long-standing failures that we don't intend to fix in the foreseeable future. Developers have been encouraged to use android classes for database access. Bug: 17342415 Bug: 17321262 Bug: 17320961 Bug: 17093235 (cherry picked from commit 4459407dbfc74376668c7ff3c94c741ce3447d45) Change-Id: If34ab5218e692ea237de12dafa5cda9b65da0b3c
* | | am fc5a9bde: Merge "Fix apache-harmony logging tests"Neil Fuller2014-09-041-8/+0
|\ \ \ | | |/ | |/| | | | | | | * commit 'fc5a9bde9565f9d6d5aaf1155743a669c37f7f08': Fix apache-harmony logging tests
| * | Fix apache-harmony logging testsNeil Fuller2014-09-041-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed SocketHandler to re-introduce a "socket != 0" check unintentionally removed by commit 232c91dce1760b180155256d1896d0d80375ff6d. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. Updated FileHandler to deal with null system properties. This is an equivalent change to http://svn.apache.org/viewvc?view=revision&revision=935099 Updated XMLFormatter to handle basic XML escaping. This is an equivalent change to http://svn.apache.org/viewvc?view=revision&revision=929953 Unsuppress tests that are fixed by this. Bug: 13882147 Change-Id: I36321b488da6d4e08fbb0d28d0e366f9b06e6371
* | | am 4f10651f: Merge "Suppress broken apache-harmony logging CTS tests"Neil Fuller2014-09-021-0/+49
|\ \ \ | |/ / | | | | | | | | | * commit '4f10651fff7200d688e5dda1508448f8b34e4d9f': Suppress broken apache-harmony logging CTS tests
| * | Suppress broken apache-harmony logging CTS testsNeil Fuller2014-09-021-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add test suppression entries for differences known to be caused by Android changes and failures that involve java code fixes. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. java package fixes will be applied via a separate commit. Bug: 13882147 Change-Id: Ie5f3d1e5bb80a6aa8e3341a3bceacc65a58b2ca3
* | | am 8d1a9652: Merge "Suppressing broken java.sql apache harmony tests."Neil Fuller2014-09-011-0/+31
|\ \ \ | |/ / | | / | |/ |/| * commit '8d1a96527f86493c56022f64bf38752ff0dc1fa5': Suppressing broken java.sql apache harmony tests.
| * Suppressing broken java.sql apache harmony tests.Neil Fuller2014-09-011-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These are long-standing failures that we don't intend to fix in the foreseeable future. Developers have been encouraged to use android classes for database access. Bug: 17342415 Bug: 17321262 Bug: 17320961 Bug: 17093235 Change-Id: I30ed5576471253f58a63162347966dc11056cb31
* | am c4ec8f34: Merge "Remove knownfailures for "host""Neil Fuller2014-08-011-33/+0
|\ \ | |/ | | | | | | * commit 'c4ec8f34d8464bcadb1bd249915dce18265f5ec9': Remove knownfailures for "host"
| * Merge "Remove knownfailures for "host""Neil Fuller2014-07-311-33/+0
| |\
| | * Remove knownfailures for "host"Neil Fuller2014-08-011-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | These all appear to work on host now given the correct classpath. Bug: 3041920 Bug: 2931959 Bug: 3032875 Change-Id: Id1687652803df925d529ee4f3250b54d023c3f8f
* | | am f814c4f5: Merge "Fix the OOME in ScannerParseLargeFileBenchmarkTest"Neil Fuller2014-07-311-0/+5
|\ \ \ | |/ / | | | | | | | | | * commit 'f814c4f5445887275d9d58d21843e6d80fbdae27': Fix the OOME in ScannerParseLargeFileBenchmarkTest
| * | Fix the OOME in ScannerParseLargeFileBenchmarkTestNeil Fuller2014-07-301-0/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scanner had no mechanism for recovering buffer space it didn't need. Now, if the buffer is more than 50% full of ignorable characters the remaining characters are shuffled to the beginning to recover space. For most expected usecases this means that the buffer will stay 1k and contain up to 512 characters of useful data. A growable, circular character buffer could have been introduced to avoid the copy but is not worth the effort. Previously the buffer would double in size until the data or memory was exhausted, and each read would also double in size to fill the empty half of the buffer. This was fine providing the input could fit in memory. On top of that the 1k, 2k, 4k, etc. buffer was repeatedly turned into a String and passed to the (native) matcher, and then the matcher was told to ignore more than half of it. As a consequence of keeping the buffer a fixed size (and only filling 50% of it at a time), this change may cause a performance regression: for most usecases where delimiters are closer together than 512 bytes, reads after the first will now usually be 512 bytes and not the 1k, 2k, 4k, etc. it was previously. Having fixed the test so it doesn't OOM, the test now takes 6 minutes to pass on host and so is unsuitable for inclusion in CTS tests and so is being suppressed. This change also includes so tidy up changes to the test and the Scanner class. The implementation could no doubt be improved but the API makes it inherently slow. It would be surprising if anybody uses the Scanner class on Android with so many better alternatives. Bug: 14865710 Change-Id: I40a7fc0c2bfaf6db4e42108efe417303e76bde24
* | am bfbc1b51: am 0be12357: Merge "Removing tests that test the SqlLite API ↵Neil Fuller2014-06-191-64/+0
|\ \ | | | | | | | | | | | | | | | | | | directly." * commit 'bfbc1b512b2c31907dd9a90dace17a4346912d03': Removing tests that test the SqlLite API directly.
| * \ am 0be12357: Merge "Removing tests that test the SqlLite API directly."Neil Fuller2014-06-191-64/+0
| |\ \ | | |/ | | | | | | | | | * commit '0be123572d8d243ca6018ce8b61b0476e629e37d': Removing tests that test the SqlLite API directly.
| | * Removing tests that test the SqlLite API directly.Neil Fuller2014-06-171-64/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many of the tests were testing that the SqlLite Java API works. Android does not ship with the SQLLite code as a public API so these have been removed. Some of the tests were testing JDBC APIs associated with Connection, Driver and DriverManager behavior so these have been retained and moved to libcore/java/sql/DriverTest.java / ConnectionTest.java Change-Id: I97ec05591019505f527ee134177c5637bbd08538
generated by cgit v1.1 at 2024-06-10 06:50:57 +0000