IssueTracker

That seems quite bad :/ weird.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.

Can you provide a sample or share  your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.

Let me see what I can do on the reproduction as I am anyways blocked on this. I will try to extract out the DB module in a new project and see if it reproduces the issue.

Attaching the sample project. When I run the project through the android studio or even command line, I see the described issue.
Try uncommenting room-compiler dependency from app's build.gradle, it does not have the issue because room compiler is not at work.

Did you get a chance to look at it?

FYI. I see that if I comment out applying google-services plugin (at the end of the app's build.gradle file), that fixes the issue too. Hence, you may need to apply a google-services plugin with a json file to reproduce the issue.

Not sure what is going on but certainly, somethings are not playing well together.

Above comment is NOT TRUE, it seems I did not do a code change after commenting out apply google-services plugin. That's why the build passed.

Thanks for the sample app. I haven't gotten to the bottom of the issue yet but I wanted to give you an update and it does seem indeed that Room is taking a very long time to parse and understand your queries via the ANTLR generated parser that Room uses. I'm not sure what is so special about your queries that is causing this, but I'll comment back with an update once I find out. Sadly for now I don't have a recommendation on a workaround.

Alright, I've drill down the problem to being the various "OR <col_name> LIKE '%' : text '%'" in your queries. Specifically they cause the SQLiteParser in Room to go down a path with poor performance as described in https://github.com/antlr/antlr4/issues/1398. A fix for this involves updating Room's ANTRL runtime library and generated parser code with the latest version. This update will likely be available in Room 2.1.0-alpha02.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 8e46b9ca1f55b040a18dd86833880b5106d103b2
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date:   Wed Oct 10 19:17:50 2018

    Update Room's ANTLR Parser to 4.7.1
   
    Updating to the latest ANTLR version fixes the performance issue
    described in https://github.com/antlr/antlr4/issues/1398 which affects
    Room's SQL Parser since it contains left-recursive rules. Specifically
    SQLite.g4 has multiple recursions to describe an expression as defined
    in https://www.sqlite.org/lang_expr.html, meaning if a user has certain
    queries that causes the parser to use the adaptivePredict algorithm
    then the build time increases significantly due to Room's query
    parsing.
   
    Also bumped Room's version to 2.1.0-alpha02
   
    Bug: 117401230
    Test: ./gradlew room:integration-tests:testapp:cC
    Change-Id: I4d0799a11ccee816ab209cbf74e7dcf2b2ce1a18

M       buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
M       buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/UserDao.java

https://android-review.googlesource.com/786077
https://goto.google.com/android-sha1/8e46b9ca1f55b040a18dd86833880b5106d103b2

No concrete date on 2.1.0-alpha02, I want to get a few more bugs in before making the next alpha release. So maybe by the end of the month.

Thanks.

On Tue, Oct 16, 2018, 4:52 AM <buganizer-system@google.com> wrote:

--

- Ankit

In Fedora you can fix this using "systemctl mask tmp.mount" and a reboot as described here: https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
Setting TMPDIR however does not work.

Wow, is this going to be fixed? I now can't update Android Studio with over 7GB of free space on / filesystem. I've tried cleaning up, but how much space does this actually need?!
Major pain that you can't now use a different /tmp directory, as stated in one former solution above.

Me too.
To be specific: much unhappiness with emulator updates with 4GB /tmp partition filling up.
With the ever-increasing, astronomic size of Android Dev bundles, there really should be a reliable way to re-point to a more abundant scratch area.

I have 16GB RAM and 8GB tmp and it still can't manage the updates. It also won't allow the custom tmp directory.

The workaround from comment 13 still works (create symlinks for PackageOperation0x)

Another work-around: If you are using tmpfs for /tmp (Arch Linux and others?), then it's not a 'real partition' and you can resize it on the fly (really - redefine it's max limit).
As root: mount -o remount,size=10G,noatime /tmp

Default is half your RAM - In my case, 4GB. But can try for more...
I suppose if you use too much in /tmp you might run out of RAM+SWAP.

Upping to 10GB worked for me on Arch. Interestingly, I watched a single emulator update top out at pretty much precisely 4.0GB of /tmp usage. This may have RELATIVELY RECENTLY started tripping up more users with 8GB of RAM like me - Pretty damn common???

I couldn't get the symlink work-around working. SymLink just gets clobbered and a real directory appears. More elaboration on how you go that to work exactly??? Is there special timing required?

P.S. - Just a SINGLE emulator update hits 4GB /tmp usage. Doing several such updates (or a full automatic update) could easily push higher. Maybe try doing the updates piece-meal if you have no other option...

Good luck. I've got past this hurdle. Onwards to the next...

What Peter #22 said.

The PackageOperation0x symlink workaround was working for me at first.  But now, Android Studio 2.3 is overwriting my symlinks with real folders of its own, which it promptly fills up and I'm back to the error.

This is really poor programming from the Android team.  They take so much from Linux and this is how they pay it back?

At #22,#23: You can do the symlink workaround, but you have to download without symlink, wait for Android Studio to fail, this will leave downloaded files in /tmp/PackageOperation0x; then move this dir to some other place and symlink it back to /tmp.

Android studio will first check if there are some files downloaded and if it finds some it will use the symlinked dir and not overwrite it.

Android team please fix the issue!

same here /tmp -> tmpfs 1.9GB how stupid is that ? Really ...Why linux sucks ? because stuff like this that seems the right idea initially and then we get that it screw everthing arround and broke EVERYTHING ... The man that did that need to get slaped in the face politely and with love !

[Comment deleted]

work around ... for systemd linux happy campers that can be root, systemctl mask tmp.mount then reboot then /tmp is par of your main file system... still slap around that guy (https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt)... serriously ...

I would rather edit android-studio/bin/studio.sh search for VM_OPTIONS="" and set it as VM_OPTIONS="-Djava.io.tmpdir=/home/myuser/tmp"

No need to slap that talented man in his face he did something great accelerating linux even more with his tmpfs.

[Comment deleted]

Great fix we...@gmail.com! Worked for me.

#26, as #12 pointed out before, the "-Djava.io.tmpdir" option _does_not_work_ anymore in AS 2.3.3, no matter how you specify it, in _JAVA_OPTIONS, as VM_OPTIONS in studio.sh, in a custom options file, doesn't matter.
It does _not_ work. AS downloads and/or unzips to /tmp and then bombs when /tmp is full. Period.

Studio Build: 2.3.3 (full build info not copy/pasteable, 'About' window keeps disappearing when switching focus to other windows, not gonna monkey typewriter it down this way)
Version of Gradle Plugin:
Version of Gradle:
Version of Java:
$ ~/.local/opt/android-studio/jre/bin/java -version
openjdk version "1.8.0_112-release"
OpenJDK Runtime Environment (build 1.8.0_112-release-b06)
OpenJDK 64-Bit Server VM (build 25.112-b06, mixed mode)
OS: Void Linux (x86_64, glibc)

Android Studio unpacked to ~/.local/opt/android-studio

Initial free space on /tmp:

$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G  144K  3.9G   1% /tmp

When I tried to apply the proposed NDK update (full info again not copy/pasteable), I get the aforementioned error: "No space left on device".
After I finished the failed update and exited Android Studio, /tmp was still 100% full and the system behaved erratically.

After I cleaned out /tmp (which made the system responsive again), I hard-coded the following setting in ~/.local/opt/android-studio/bin/studio.sh:

VM_OPTIONS="-Djava.io.tmpdir=/home/miki/tmp"

Initial free space in ~/tmp:
$ df -h ~/tmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       917G  759G  112G  88% /home

Next, I ran the studio.sh script with `strace` and also logged standard output and standard error:

$ strace -o strace.out -e process -f -s 16384 -v /home/miki/.local/opt/android-studio/bin/studio.sh
Looking in classpath from com.intellij.util.lang.UrlClassLoader@6d5380c2 for /com/sun/jna/linux-x86-64/libjnidispatch.so
Found library resource at jar:file:/home/miki/.local/opt/android-studio/lib/jna.jar!/com/sun/jna/linux-x86-64/libjnidispatch.so
Trying /home/miki/.AndroidStudio2.3/system/tmp/jna5532858125402248429.tmp
Found jnidispatch at /home/miki/.AndroidStudio2.3/system/tmp/jna5532858125402248429.tmp
[   4372]   WARN - dea.updater.SdkComponentSource - File /home/miki/.android/repositories.cfg could not be loaded.
[  85320]   WARN - ectedPackagesStep$CustomLogger - An error occurred while preparing SDK package NDK: No space left on device.
java.io.IOException: No space left on device
        at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
        at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
        at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
        at sun.nio.ch.IOUtil.write(IOUtil.java:65)
        at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
        at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
        at java.nio.channels.Channels.writeFully(Channels.java:101)
        at java.nio.channels.Channels.access$000(Channels.java:61)
        at java.nio.channels.Channels$1.write(Channels.java:174)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
        at com.android.repository.util.InstallerUtil.readZipEntry(InstallerUtil.java:161)
        at com.android.repository.util.InstallerUtil.unzip(InstallerUtil.java:131)
        at com.android.repository.impl.installer.BasicInstaller.doPrepare(BasicInstaller.java:81)
        at com.android.repository.impl.installer.AbstractPackageOperation.prepare(AbstractPackageOperation.java:243)
        at com.android.tools.idea.sdk.wizard.InstallTask.preparePackages(InstallTask.java:191)
        at com.android.tools.idea.sdk.wizard.InstallTask.run(InstallTask.java:98)
        at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:635)
        at com.intellij.openapi.progress.impl.CoreProgressManager$3.run(CoreProgressManager.java:170)
        at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:494)
        at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:443)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:54)
        at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:155)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:128)
        at com.intellij.openapi.application.impl.ApplicationImpl$2.run(ApplicationImpl.java:307)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

The `strace.out` file shows that the final execve() which starts Java and Android Studio does indeed includes the `-Djava.io.tmpdir=/home/miki/tmp` command line option.

Hopefully the backtrace will shed some light on what is going wrong here.

Looks like I won't be using Android Studio. I'll try back in a couple of years and maybe they'll get it working.

The progress in 3.1.4 is that no workaround seems to work anymore...

This is still not working for me as well. I attempted all of the workarounds mentioned above. Any other ideas? Will this be fixed? It makes my Chromebook kinda useless.

Note that as part of the work on the linked issue 72581483, we added the disk space analysis, which outputs the estimated disk usage before proceeding with SDK operations, and issues a warning recommending to clean up the required space in case there is not enough free disk space. This shipped with 3.3.

We'll look into further improvements we can make to handle insufficient tmp space for downloads.

As of 3.5, SDK manager won't be using system temp directory for downloading & unzipping, instead doing this directly at SDK root (in a dedicated temporary directory there). This should resolve the problem in the situations when system temp partition is relatively small and may run out of space for larger SDK downloads (such as system image). The change also makes sense because ultimately SDK manager really needs the space to be available only in the partition where SDK is located, since this is where packages get installed anyway, not the system temp. Therefore we reduce disk space requirements by half for the cases when temp partition and SDK partition are different (which is the case on most UNIX systems, for example).

This should be available in the next 3.5 Canary release. Let us know more feedback in this thread or file a new one in case relevant issues occur. Thank you for the reports so far, this helps us make Android Studio even better for developers!

Wow. Finally someone with some common sense. It seems to be as rare as rocking horse poo in the programming world these days. On the flip side, it has taken 3 years to get to the position where we can actually install Android Studio on Linux, so that kind of puts this into perspective.

^--- lol! Harsh but true. This issue should have been fixed a long time ago, and had such an obvious solution. I guess the Android Studio team had higher priorities, but thank you for fixing this problem.

> As of 3.5

sdkmanager --version reports 26.1.1, and it's still unzipping NDKs into /tmp

The only workaround I've found so far is to install it to a separate server and then scp the contents over.
In the case of a system image this would look like:

sdkmanager "system-images;android-33;google_apis;x86_64" # to install the image
scp -r $ANDROID_HOME/system-images/android-33 limtd-ram-machine:path/androidhome/system-images

I guess f me for having 8gb ram lmao