dart.exe eating all memory

When i try to run flutter app in following ide(Android Studio or Visual Studio Code) the dart.exe process is created in the Task Manager(I use windows 10 Pro) and eats up all the RAM(32GB).
I think this is related to the Dart Analysis server, since when I kill the dart process that eats up all the memory in Android Studio displays the message ‘Analysis server has terminated’. This process fills RAM at a speed of ~150 MB per second. Note that usually exists several processes dart.exe, but only one of them for some reason eats all the RAM. Please, fix it.

Author: Fantashit

8 thoughts on “dart.exe eating all memory

  1. I was troubled with this issue since last week, even after upgraded the latest flutter version.
    It happens when use flutter run command, but doesn’t happen when use flutter build command.
    My “flutter –version” command output is as following:

    Flutter 1.18.0 • channel dev • https://github.com/flutter/flutter.git
    Framework • revision de1e572916 (8 hours ago) • 2020-04-06 16:15:07 -0700
    Engine • revision df257e59c2
    Tools • Dart 2.8.0 (build 2.8.0-dev.20.0 1210d27678)

    Plz fix it…

    Update 1: use VS Code to run is OK, but use Android Studio would happen.
    Is this more likely a problem of the Android Studio Dart/Flutter plugin?

    Update 2: Sadly, today, I use VS Code to run, this issue also happens…

  2. Same problem here.

    [√] Flutter (Channel dev, v1.18.0-dev.5.0, on Microsoft Windows [Version 10.0.18363.720], locale de-DE)
        • Flutter version 1.18.0-dev.5.0 at C:\src\flutter_windows_v1.9.1+hotfix.5-stable\flutter
        • Framework revision 7f56b53de4 (2 days ago), 2020-04-12 12:00:01 -0400
        • Engine revision beb8a7ec48
        • Dart version 2.8.0 (build 2.8.0-dev.20.0 89b0f67261)
    [√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
        • Android SDK at C:\Users\pschu\AppData\Local\Android\Sdk
        • Platform android-29, build-tools 29.0.2
        • ANDROID_HOME = C:\Users\pschu\AppData\Local\Android\Sdk
        • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
        • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b04)
        • All Android licenses accepted.
    [√] Android Studio (version 3.6)
        • Android Studio at C:\Program Files\Android\Android Studio
        • Flutter plugin version 45.1.1
        • Dart plugin version 192.7761
        • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b04)


  3. Faced same problem today using Android Studio.


    This memory consuming process is created right after I do “run”.

    I did #40243 (comment) but it seems to be not a Dart Analysis Server, because in my case I see that Analysis Server is ok and tooks ~200mb.

    I tried switching to

    • dev (flutter version 1.18.0-13.0.pre, tools and dart 2.9.0<build 2.9.0-5.0.dev 4da5b40>)
    • master (flutter version 1.18.0-14.0.pre.4, tools and dart 2.9.0<build 2.9.0-5.0.dev 4da5b40>)
    • stable (flutter version 1.17.0, tools and dart 2.8.1)
      reinstalled flutter SDK but nothing helped.
  4. I had this problem and I solved it with a rather weird workaround.
    If you run the App normally the same bug will occur however if you run “profile” button which is located in the right of run button(in android studio) your dart.exe will work fine.
    After doing this,run the app normally and you’ll see your dart.exe will run fine without becoming too big.
    MIne consumes almost 380 Mb of Ram

  5. WOW my computer is crashing a LOT after flutter 1.17 update. I just figured out that the “dart”process under Task Manager was consuming 10gb of ram!!! (my laptop has only 16)

    UPDATE: I did a Flutter Clean and now seems to be fixed.

  6. OMG, dart.exe consumed more than 10gb of my RAM.
    I ran the command flutter clean and it seems to be fixed.

  7. How can i fix this problem.

    @alen252 try flutter clean

    flutter clean is not a permanent solution. With version 1.17.0, build takes much longer and flutter clean mostly solve for current build and not necessarily subsequent builds.

Comments are closed.