Fixed
Status Update
Comments
an...@gmail.com <an...@gmail.com> #2
what is in update.zip ? can you share that file to triage this issue
ra...@google.com <ra...@google.com>
[Deleted User] <[Deleted User]> #3
MHC19Q for Nexus 5X (bullhead) - https://dl.google.com/dl/android/aosp//bullhead-ota-mhc19q-8fe67a2b.zip
N4F26T for Nexus 5X (bullhead) -https://dl.google.com/dl/android/aosp/bullhead-ota-n4f26t-648ce802.zip
WW-12.2.5.23 for Asus ZenFone Go (ASUS_X014D) -http://dlcdnet.asus.com/pub/ASUS/ZenFone/ZB452KG/UL-ASUS_X014D-WW-12.2.5.23-user.zip
Look like, this happens only with a big images.
N4F26T for Nexus 5X (bullhead) -
WW-12.2.5.23 for Asus ZenFone Go (ASUS_X014D) -
Look like, this happens only with a big images.
gh...@google.com <gh...@google.com> #4
On Windows 10 (x64)
an...@gmail.com <an...@gmail.com> #5
related to (and probably worked around for now by) internal bug http://b/36046324
i do think we should also start shipping a 64-bit Windows platform tools package.
we should also consider changing android::base::ReadFdToString to call fstat and pre-size the vector. not worthwhile for reading things like /proc/uptime, but the default expansion behavior for a huge file like a full OTA update is going to result in substantial overhead. (which will explain the regression between .3 and .4, since the former will have allocated exactly the necessary number of bytes.)
lastly (and maybe not worth doing at all, depending on how soon we can get folks to use a 64-bit platform tools on Windows, since all the other platforms are already 64-bit-only), we could consider rewriting the adb sideload code to (a) mmap/munmap rather than actually read in to physical memory or (b) pread. i'm not sure what the performance impact of pread would be (especially on Windows where there is no pread equivalent).
i do think we should also start shipping a 64-bit Windows platform tools package.
we should also consider changing android::base::ReadFdToString to call fstat and pre-size the vector. not worthwhile for reading things like /proc/uptime, but the default expansion behavior for a huge file like a full OTA update is going to result in substantial overhead. (which will explain the regression between .3 and .4, since the former will have allocated exactly the necessary number of bytes.)
lastly (and maybe not worth doing at all, depending on how soon we can get folks to use a 64-bit platform tools on Windows, since all the other platforms are already 64-bit-only), we could consider rewriting the adb sideload code to (a) mmap/munmap rather than actually read in to physical memory or (b) pread. i'm not sure what the performance impact of pread would be (especially on Windows where there is no pread equivalent).
tn...@google.com <tn...@google.com> #6
Correction to #5: Windows does support pread() - it's in ReadFile()'s OVERLAPPED parameter.
an...@gmail.com <an...@gmail.com> #7
@7: we'd still need to write the pread wrapper, though. (similar if we went with mmap/munmap.)
https://android-review.googlesource.com/#/c/355481/ pre-sizes the vector, which should be enough to undo the regression from '.3 to '.4...
an...@gmail.com <an...@gmail.com> #8
wo...@gmail.com <wo...@gmail.com> #9
Hi I'm getting the same issue on Windows 10 when I try to sideload a TWRP backup.
- adb devices gives my device
- adb usb gives error: closed
- adb sideload 6.13.771.4_ckpv5.zip gives
loading: '6.13.771.4_ckpv5.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Please can somebody help with this issue I've been trying to sort this for 3 days. Thanks.
- adb devices gives my device
- adb usb gives error: closed
- adb sideload 6.13.771.4_ckpv5.zip gives
loading: '6.13.771.4_ckpv5.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Please can somebody help with this issue I've been trying to sort this for 3 days. Thanks.
wo...@gmail.com <wo...@gmail.com> #10
I also get this problem. Is there a workaround?
di...@gmail.com <di...@gmail.com> #11
I also get this error message when trying to update Android OS 7.1.1 from N6F26R to N6F26U security patch for Nexus 6. Please help. Thank you.
wo...@gmail.com <wo...@gmail.com> #12
It happens when i try to flash any rom to my OnePlus 3, how can i solve it?
[Deleted User] <[Deleted User]> #13
Trying to sideload via adb on Win10 gives me this as well. Nexus 6 trying to sideload from 7.0 to 7.1.1 (N6F26U, Mar 2017)
[Deleted User] <[Deleted User]> #14
My Nexus 9 is on a bootloop and is locked so this was my way out of the bootloop but I've got the same error std::bad_alloc...
If someone has found a way to suppress this error let us know !
If someone has found a way to suppress this error let us know !
an...@gmail.com <an...@gmail.com> #15
As this bug is in 25.0.4 only, simply revert to platform tools 25.0.3 to successfully sideload the image. This solved both my 'std::bad_alloc' error and bootloop error (hopefully).
an...@gmail.com <an...@gmail.com> #17
update: bootloop still looping, but will boot successfully every few boots, which is better than I had.
gh...@google.com <gh...@google.com> #18
Same issue
an...@gmail.com <an...@gmail.com> #19
Thank you! With the earlier version of the platform tools it works very well!
an...@gmail.com <an...@gmail.com> #20
Reverted to earlier platform-tools and it works like a charm. Thanks for the link.
br...@google.com <br...@google.com> #21
Same problem, OnePlus 3, Open Beta 13 (http://downloads.oneplus.net/oneplus-3/oneplus_3_oxygenos_openbeta_13/ ), reverting to the platform-tools in #17 and using Large Address Aware 2.0.4 (https://www.techpowerup.com/forums/threads/large-address-aware.112556/ ) let me sideload with vanilla Oxygen Recovery (without LAA flag, it just says cannot read rom.zip)
full log:
C:\Android\SDK\platform-tools>adb sideload ../rom.zip
loading: '../rom.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
full log:
C:\Android\SDK\platform-tools>adb sideload ../rom.zip
loading: '../rom.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
gh...@google.com <gh...@google.com> #22
the same result by using latest adb version delivered by SDK Tools(Preview Channel) 26rc1.
gh...@google.com <gh...@google.com> #23
ws...@gmail.com <ws...@gmail.com> #24
Having same issue with Android SDK Platform tools 25.0.4 on Windows 10 with all latest updates. Was trying to install the April OTA patch on my Pixel.
gh...@google.com <gh...@google.com> #25
same issue here with adb and pixel
ws...@gmail.com <ws...@gmail.com> #26
Nikita gave the solution.
Download the LLA, go to Mode -> Advanced. Then, go to Add -> Files in folder recursive ... Select the folder where you have platform-tools installed (or unzipped). Select all the files in LLA then go to With selected -> Force Large Address Aware.
Tested on Win10, ran adb sideload <image> from cmd.exe with Administrative privilege. Installed 7.1.1 OTA on Nexus 6 without any issues.
Download the LLA, go to Mode -> Advanced. Then, go to Add -> Files in folder recursive ... Select the folder where you have platform-tools installed (or unzipped). Select all the files in LLA then go to With selected -> Force Large Address Aware.
Tested on Win10, ran adb sideload <image> from cmd.exe with Administrative privilege. Installed 7.1.1 OTA on Nexus 6 without any issues.
gh...@google.com <gh...@google.com> #27
same error for me flashing android 7.1.2 with latest adb version.
ws...@gmail.com <ws...@gmail.com> #28
Same problem. Win10 x64 latest of win updates and adb. Not going to give you more info. Same as everyone else. This issue is on n9 and n6 with april updates. Solution from " #17 m...@ajmorley.com" about using " https://dl.google.com/android/repository/platform-tools_r25.0.3-windows.zip " works great.
ku...@gmail.com <ku...@gmail.com> #30
[Comment deleted]
gh...@google.com <gh...@google.com> #31
Same issue on r25.0.4.
On old versions .3 and .1 I get cannot read "file".
Am I doing something wrong? It was a long time since I tried to sideload something.
On old versions .3 and .1 I get cannot read "file".
Am I doing something wrong? It was a long time since I tried to sideload something.
gh...@google.com <gh...@google.com> #32
Marking fixed in AGP 7.0.
That is, the lint.do.not.reuse.uast.env
workaround should no longer be needed in AGP 7.0+. And, you should no longer see the following warnings/errors while running Lint:
ERROR: package fragment is not found for module:<lintWithKotlin>...
ERROR: Could not generate LightClass for...
java.lang.IllegalArgumentException: Argument for @NotNull parameter 'descriptor' of org/jetbrains/kotlin/codegen/context/CodegenContext.intoPackagePart must not be null
The issue is fixed due to the new "Lint partial analysis" mode (enabled by default) which creates a standalone UastEnvironment
instance for each module, thereby avoiding stale caches in the Kotlin compiler frontend.
Please comment on the bug if you see any similar errors in AGP 7.0+.
Description
AGP: 4.0.0 Kotlin: 1.3.72 JVM: from docker image: 8u252-jdk-slim
Failure happens in CI builds, which always are clean. Failures are random. Sometimes builds are a success, but more often it is not. Each time random classes failed. For example, in this case, failed this little data class:
I included full stacktrace as file