summaryrefslogtreecommitdiff
path: root/luni/src/test/java/libcore/dalvik
Commit message (Collapse)AuthorAgeFilesLines
* Try #3 for deflaking class loader tests.Nicolas Geoffray2021-04-061-10/+9
| | | | | | Bug: 184222922 Test: CtsLibcoreTestCases Change-Id: Ieb4866dd5b0130f83853f8429bb24dabcd52f860
* Deflake class loader tests.Nicolas Geoffray2021-04-011-0/+1
| | | | | | | | Run finalizers to ensure class loaders get reclaimed. Test: libcore.dalvik.system.BaseDexClassLoaderTest Bug: 184222922 Change-Id: I0e33423b39c22aa45d531098e4865129c5f75053
* Also trigger background verification of secondary dex files.Nicolas Geoffray2021-03-291-0/+2
| | | | | | Test: 692-vdex-secondary-loader Bug: 160294863 Change-Id: Id14b78a87653489d1bdcf413163fcbe9e7d43707
* Reland "Fix shared libraries not being reported"Calin Juravle2020-02-181-31/+140
| | | | | | | | | | | | | | | | | | | | Original commit: This CL topic fixes shared libraries not being reporter via Reporter. This particular CL changes the BaseDexClassLoader.Reporter interface to report ClassLoader context strings rather than ClassLoader instances. These ClassLoader context strings are computed directly by the runtime (see the changes within art in the same topic). Test: atest libcore.dalvik.system.BaseDexClassLoaderTest Bug: 148494302 Reason for revert: Re-land Reverted Changes: I295a6e99e:Revert "Fix shared libraries not being reported vi... Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte... Change-Id: I63db10d85c3316dd9f08c0d75ab34dd3f1b62d28
* Revert "Fix shared libraries not being reported via Reporter"Nicolas Geoffray2020-02-151-75/+32
| | | | | | | | | | | | | | Revert submission 1198456-slclc Reason for revert: Fails on luci: https://ci.chromium.org/p/art/builders/ci/host-x86_64-cdex-fast/3123 Bug: 148494302 Reverted Changes: I46d8d9105: Fix shared libraries not being reported via Report... I00357cfe0: [DexLoadReporter] Report classloader contexts dire... Change-Id: I295a6e99e58d5b953cb9b91bf55c2ea654de8612
* Fix shared libraries not being reported via ReporterDan Zimmerman2020-02-131-32/+75
| | | | | | | | | | | | This CL topic fixes shared libraries not being reporter via Reporter. This particular CL changes the BaseDexClassLoader.Reporter interface to report ClassLoader context strings rather than ClassLoader instances. These ClassLoader context strings are computed directly by the runtime (see the changes within art in the same topic). Test: atest libcore.dalvik.system.BaseDexClassLoaderTest Bug: 148494302 Change-Id: I46d8d9105bbdefdd058711b74a841500671cc050
* [libcore][DexPathList] Ensure dexElements doesn't contain null entries in ↵Dan Zimmerman2019-12-301-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | addDexPath Previously it was possible for dexElements to be mid-transaction when a class load occurs (on a separate thread). In practice this displayed itself as CNFE and various SEGFAULTs in places of the VM that don't protect against NULL dexElements. In order to combat this issue, lets compute the final dexElements Array in a local variable and then atomically set the dexElements instance variable once the computation is complete. I applied the same patch to suppressed exceptions for good measure. A TODO for a follow up commit would be to introduce barriers to ensure coherency across threads. Test: atest ./luni/src/test/java/libcore/dalvik/system/ Bug: https://issuetracker.google.com/issues/146447053 Bug: 146533113 Change-Id: I295f20425b406d900b75e5a1bb97725fe9964128
* Fix MethodHandles.explicitCastArguments for transformsOrion Hodson2019-12-091-0/+17
| | | | | | | | | | | | | | | | | | | Fixes incorrectly handled paths in ExplicitCastArguments transform. Update MethodHandles.explicitCaseArguments() to use an ExplicitCastArguments transform if the call requires asType() conversion. We could have introduced another transform, but that's more code and before inserting the transform the code checks the explicit cast is equivalent to asType(). The transformer path had issues because StackFrame{Reader,Writer} classes do not perform asType() conversions as they read and write stack frame locations. Bug: 113855305 Test: art/test/testrunner.py --host --64 Test: art/tools/run-libcore-tests.sh --host Change-Id: I712bcf5a55f1f7c091af5daddeb3f8a5b7b5b4d3
* findLibrary() could return non-null string when it fails to find a libJiyong Park2019-09-111-4/+14
| | | | | | | | | | | | | With Ia2525e736f91460a50f2def3d6a04bf3cf8c221d, findLibrary() can return non-null string even when it fails to find a lib. The change was to give a chance to the dynamic linker for searching the lib with the soname. This change fixes the test_oneDex_addNative_findsLibrary test to reflect the changed semantic of findLibrary(). Bug: 109720125 Test: run the test using forrest Change-Id: I950a65e6fd4e892509d011fb48869ed4e27b10d2
* Load in-memory dex into a single DexFile/Element objectDavid Brazdil2019-03-211-0/+16
| | | | | | | | | | | | | | | | | | | | | | InMemoryDexClassLoader only accepts ByteBuffers containing dex files, not apks. Loading dex files in a multidex fashion is therefore impossible as each ByteBuffer is loaded into its own Element/DexFile object. This has not been an issue so far because dex files loaded with InMemoryDexClassLoader are never optimized or backed by an oat file, and the first time a class can be resolved is after the whole class loader class path has been initialized. Refactor this now because introduction of a vdex backing the dex files changes this. It is also convenient to generate just one vdex per class loader than one vdex per ByteBuffer. The original makeInMemoryDexElements() method is left unused after the refactor but it is known to be in use by 3p apps. Leave it there are add a test to make sure it continues to work. Bug: 72131483 Test: art/tools/run-libcore-tests.sh Change-Id: I618b286951861b3ff9a4622599244b6f5c8b4bc3
* InMemDexCL: Add test with non-zero buffer positionDavid Brazdil2019-01-241-5/+74
| | | | | | | | | | | InMemoryDexClassLoader can load dex files from both direct and indirect ByteBuffers but it only respects the buffer's current position for the latter and assumes the position is zero for the former. Add test cases for the bug fix in ART. Bug: 123337866 Test: art/tools/run-libcore-tests.sh Change-Id: Iebe74ae2d4baddfa0b732c5ab33c4eb880e41d66
* Add InMemoryDexClassLoader test with null parentDavid Brazdil2018-12-061-0/+15
| | | | | | | | | | | | Setting up InMemoryDexClassLoader with 'null' as parent results in the class loader not being able to load any boot classpath classes. This is due to the fact that InMemoryDexClassLoader inherits class lookup from BaseDexClassLoader which delegates it to ART, but ART rejects InMemoryDexClassLoader as not supported. Bug: 120603906 Test: InMemoryDexClassLoaderTest Change-Id: I3139b1bb343b5fc722bcf06f89a6f6a21a3c7c54
* Simplify InMemoryDexClassLoaderTest libSearchPath testDavid Brazdil2018-11-261-14/+53
| | | | | | | | | | | Do not attempt to copy a native library. Instead create an empty temp file and check that ClassLoader::findLibrary returns the correct path. This is consistent with PathClassLoaderTest. Bug: 35458580 Test: CtsLibcoreTestCases Test: art/tools/run-libcore-tests.sh Change-Id: I41ac37a05781fdb5487b6e253ce720cd324ef1b1
* Support libSearchPath for InMemoryDexClassLoaderDavid Brazdil2018-11-211-4/+15
| | | | | | | | | | | | | | InMemoryDexClassLoader currently does not have a constructor which would allow users to set the library search path and therefore the class loader cannot be used to load code which depends on a native library outside of the system library search path. This patch adds such a constructor. It also annotates params of InMemoryDexClassLoader constructors with @Nullable and @NonNull. Test: InMemoryDexClassLoaderTest Bug: 35458580 Change-Id: I8762f37a1c2cd01ba6c6dca84117c15838ae1971
* Add shared libraries to BaseDexClassLoader.Nicolas Geoffray2018-11-152-21/+198
| | | | | | bug: 112405321 Test: BaseDexClassLoaderTest, 688-shared-library Change-Id: I7daffc7a0cc6f06aaebefb61e70c62f8066a9787
* Call Reporter even if there are unknown classloaders.Alan Stokes2018-11-091-21/+79
| | | | | | | | | | | | The classloader class but not the classpath for unknown classloaders is reported. (Had to loosen the type to allow this.) Refactored the tests to make it easier to add new ones. Bug: 111336847 Test: atest CtsLibcoreTestCases:BaseDexClassLoaderTest Change-Id: I47b247d1a8501697d0e560533215a575a9ce3237
* Add a flag on whether to delegate resource loading.Nicolas Geoffray2018-09-251-2/+59
| | | | | | | | Some apps may want to not use the resoures from the parent. See cl/211431192 for context. Test: DelegateLastClassLoaderTest Change-Id: I5ccc210fc4dab98b826e4b47f4295c0a350c52f4
* Open FIS/FOS through common IoBridge code.Jeff Sharkey2018-08-021-2/+35
| | | | | | | | | | | | | | | | | | | | | To support legacy apps that are using "_data" columns via public APIs, we're looking at a design that requires hooking of all open(2) calls performed in Java. Upstream FileInputStream and FileOutputStream use their own native code to open files, so this change modifies them to instead use IoBridge to open their FileDescriptors, which enables the hooking described above. Since IoBridge indirectly applies BlockGuard policy, we no longer need to trigger it explicitly in FIS/FOS. Update tests to reflect BlockGuard violations, with notes about why each is triggered. Also add tests for RandomAccessFile. Bug: 111268862, 111960973 Test: cts-tradefed run singleCommand cts-dev -a arm64-v8a -m CtsLibcoreTestCases -t libcore.dalvik.system.BlockGuardTest Change-Id: I018a50950d37385470574ff312bdd12d4f0c3525
* In place split install native supportPatrick Baumann2018-05-041-1/+29
| | | | | | | | | | | | This change allows native paths to be added to the BaseDexClassLoader and DexPathList at runtime. This enables running apps to begin consuming newly installed native libraries via System.loadLibrary. Bug: 72047376 Test: manual - used sample app to verify availability of native libs Test: run-libcore-tests libcore.dalvik.system.DexClassLoaderTest Change-Id: I5614529a9924abf99defd7e7cfd98daf7a8939aa (cherry picked from commit e81130c49879bc653cf47c1b2db692e056207965)
* Do BlockGuard check on Runtime.gc().Pete Gillin2018-03-062-1/+20
| | | | | | | | | | | This adds an onExplicitGc method to BlockGuard.Policy and calls it in Runtime.gc(). Bug: 3400644 Test: cts-tradefed run cts-dev -m CtsLibcoreTestCases Test: cts-tradefed run cts-dev -m CtsOsTestCases Change-Id: Ifa171a34cbd1cbde289a94da46b9c404f7bd506f Merged-In: I82a37e38a4c8dbdf82cd988eccc2ed5d578e7ec0
* Move libcore tests to non-libcore packages.Tobias Thierer2017-11-088-0/+2029
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The integration of OpenJDK 9 javac into the Android build system requires non-libcore code to live in non-libcore packages, as long as that code isn't considered part of the same module as libcore at javac time. This CL moves libcore test related classes out of such packages; since libcore tests could already only test public (as opposed to package private APIs), no change other than the package name and imports is necessary. Because many libcore tests already live below a top-level package "libcore" (eg., the tests for java.util are in libcore.java.util), this CL likewise prepends "libcore." to the package names of affected classes. For classes relating to libcore.* packages, this results in a package name of the form "libcore.libcore.*". Alternative considered but not pursued: To compile the test classes without moving the out of a libcore package, javac would need to consider them to be in the same module as libcore. This would likely be possible via javac --patch-module, but this has not been explored in detail because: - Most luni tests are already in a toplevel package libcore.*, so this CL makes the test structure more consistent. - Use of --patch-module would likely cause problems when running tests under a runtime that implements the OpenJDK 9 module system; for example, --patch-module cannot add exported packages to the module, so any new packages added in tests (such as the libcore.* packages of most existing luni tests) would not be visible at test runtime. - Having tests in different packages from code under tests makes it more obvious (including to IDEs in which the code might be edited as a single project) that these tests cannot access package-private identifiers in the code under test. Test: Treehugger Test: "make cts" with EXPERIMENTAL_USE_OPENJDK9=true passes with additional changes present locally that have not yet been exported as CLs. Test: CtsLibcoreTestCases Bug: 68224249 Bug: 68932217 (tracks potential follow-up work) Change-Id: Ib6b8e6f3bc87093bc219d2108e601163c6e334cd
* Revert "FileDispatcherImpl: Untag sockets before preClose."Victor Chang2017-10-241-155/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9666717e56a67817561d77b703f65dea286f55f6. Previously, xt_qtaguid never freed tags when the socket was closed, so if we didn't untag sockets in userspace it would leak memory. See for example b/5274621. That was fixed by the change in b/36374484, so this code is no longer necessary. Behavior change - Automatically untagging sockets on close() is incorrect, because close() does not close the socket, only the filedescriptor, which might be only one of the references to the socket. Thus, socket(); dup(); close results in the socket being untagged, even if the dupd socket is still open. - Additionally, untagging sockets automatically has undesirable side-effects. For example, it makes it very difficult for a process to create and tag a socket, and pass that socket to an app, without losing the tag. Workaround to keep old behavior If an app needs to keep old behavior, the app should call TrafficStats.untagSocket to remove the tag before sending it to another process. Test: CtsLibcoreTestCases Bug: 67425668 Change-Id: I0b0101b5ebc241741d6da707e67cae3f1d5805e8
* Make BaseDexClassLoaderTest independent of its parent class loaderCalin Juravle2017-08-031-4/+3
| | | | | | | | | | | | | | Update the test to use a well known class loader chain which does not rely on its running context. Use the system class loader instead of the actual test class loader as the parent in the test. Bug: 38138251 Test: cts-tradefed run cts -m CtsLibcoreTestCases -t libcore.dalvik.system.BaseDexClassLoaderTest Change-Id: I28aa98914e31e692ba93c259610670948d0e8432
* Extend dex load reporting to report the full ClassLoader chainCalin Juravle2017-08-031-3/+18
| | | | | | | | | | | | | | | | | | Report the full class loader chain to BaseDexClassLoader.reporter during construction. The information will be passed down to the compiler when compiling secondary dex modules. Note that this only reports if the all class loader in the chain are BaseDexClassLoader. This means that we will stop recording secondary dex modules which are loaded in unsupported class loaders. Bug: 38138251 Test: vogar luni/src/test/java/libcore/dalvik/system/BaseDexClassLoaderTest.java (cherry picked from commit 5ac512c07cfa80160e240c359349c1390a20a981) Change-Id: I7d4457b19684d0a87b1edd3b5689cfbb58559d03
* DexPathList: set initialized only after initialization.Narayan Kamath2017-03-031-4/+64
| | | | | | | | | | Mark a DexPathList.Element as initialized only after we perform the actual initialization. Without this, we risk leaving things in an inconsistent state if something goes wrong. Test: vogar --mode=host PathClassLoaderTest Bug: 35633614 Change-Id: I056c80e5eb33f37cee531c60fcd3f1ddbe78aa7f
* Add dex load reporting hooks in BaseDexClassLoaderCalin Juravle2016-12-191-0/+73
| | | | | | | | | | | | | | | | | | | | | Add hooks to allow reporting of what dex files are loaded by a BaseDexClassLoader. Intended to be use to report of non-primary dex files loads to the package manager via BaseDexClassLoader.Reporter. This will enable: 1) monitoring and compilation of secondary dex file 2) better way to track foreign dex file usage (used to determined the compilation filter of apks). Test: vogar .../BaseDexClassLoaderTest.java Bug: 32871170 (cherry picked from commit a4e5f2f31a91f1438afe24639cd71457462a86fe) Change-Id: I613950a68f971309d0f9d73bc1bb0554ce5ef5a9
* FileDispatcherImpl: Untag sockets before preClose.Narayan Kamath2016-05-271-0/+155
| | | | | | | | | | | We shouldn't close them after preClose because the descriptor will then describe a different file (/dev/null). bug: 28994821 (cherry picked from commit 48689e680a503e82cbe1d5cc122f4bb628aa2fa2) Change-Id: I3c3519cb3a54fdebf6d51520747735af01664696
* PathClassLoaderTest: add test about loading resources with tampered certificatesSergio Giro2016-04-271-0/+38
| | | | | | | | | | | | Document that classloading with malformed certificates succeed, although the call to getCertificates returns null. hyts_signed_wrong_cert.jar was obtained by taking hyts_signed.jar and changing META-INF/TEST.DSA by deleting the first byte. Bug: 27826114 Change-Id: Ia088d4ef0247a28bebf7ea66977a29afb2ca40ee
* Add test for application use of PathClassLoader.Richard Uhler2015-05-281-0/+23
| | | | | | | Bug: 19937016 (cherry picked from commit 58bef8e53e41a4b7cfe9cf647dca7c6d46528f32) Change-Id: I347b4eee1f1e3702d34ea10feca6bc1b3f2f1ee8
* Rely on the test runner to ensure a pristine VM.Jesse Wilson2010-09-241-3/+0
| | | | | Change-Id: I6f5bfad6f861eb7b398ed7d86747d66cea4f2343 http://b/issue?id=2660429
* Search the application library path first.Jesse Wilson2010-08-261-0/+65
In Froyo and earlier, we search the system library path first. This makes it impossible for applications to provide newer versions of native libraries when old versions are shipped on the device. Change-Id: I0a154e32f62a28cf841b9e8d2dbd2d9cce6f3128 http://b/issue?id=2933456
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-14 14:07:20 +0000