Fixed
Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
Indexing also runs indefinitely here with Android studio 3.3 and a project that contains a NDK library (native engine + game). Previous versions, for instance 3.2.1, worked fine. Still occurs after clearing the caches and deleting the .idea folder. On a desktop with 32 GB of RAM it's not running out of memory but it indexes forever, pegging an entire CPU and disk access to 100%, and it never stops. The same thing occurs with gradle 4.6 or 4.10. If I enable the experimental scan active configuration only setting, everything is basically broken - no syntax highlighting, cpp files don't show. Waiting to see if there's a workaround before reverting to 3.2.1 and being much more cautious about updating in the future ..
ma...@gmail.com <ma...@gmail.com> #3
When I let it run for hours, the scanning eventually did complete, then the indexing took more hours, I let it run as well, and eventually it switched to 'building symbols' which also started taking a long time without progress, but that, eventually, crashed Android Studio with an out of memory error, telling me to increase the heap size. I did, and upon restarting Android Studio, it started over at scanning .. so I gave up for now. This is with a mid-size NDK project.
br...@gmail.com <br...@gmail.com> #4
Even after a dirty downgrade to AS 3.2 from 3.3 my project was stuck on scanning files to index and building symbols. I ended up having to fully remove all Android Studio files/folders. After relaunching AS 3.2 and setting heap size to 8GB the scanning, indexing and building symbols took just a couple minutes.
br...@gmail.com <br...@gmail.com> #5
These were the folders I deleted:
rm -rfv ~/Library/Application\ Support/AndroidStudio*
rm -rfv ~/Library/Preferences/AndroidStudio*
rm -rfv ~/Library/Caches/AndroidStudio*
rm -rfv ~/Library/Logs/AndroidStudio*
rm -rfv ~/.AndroidStudio*
rm -rfv ~/Library/Application\ Support/AndroidStudio*
rm -rfv ~/Library/Preferences/AndroidStudio*
rm -rfv ~/Library/Caches/AndroidStudio*
rm -rfv ~/Library/Logs/AndroidStudio*
rm -rfv ~/.AndroidStudio*
jo...@google.com <jo...@google.com> #6
Any chance someone has a repro project they can share?
@brigham, are you saying deleting those folders help with your issue?
@brigham, are you saying deleting those folders help with your issue?
jo...@google.com <jo...@google.com> #7
@tianyu, just a heads up, this may be related to the configuration cache issue you've been looking at.
ex...@gmail.com <ex...@gmail.com> #8
I am facing the exact same issues here. I have two projects where I build native code outside of Android Studio (Cygwin shell + ndk-build.cmd) and that goes fine in AS 3.3. But one project where I use externalNativeBuild in the gradle file has the same issues as described here. The native library part is not that big (couple of .cpp and ..h files). It is like it is scanning the entire NDK. Switching back to AS 3.2 solves it.
Update: if I use Process Monitor I can see it scan my entire disk: studio64.exe accesses even my Pictures folder!
Update: if I use Process Monitor I can see it scan my entire disk: studio64.exe accesses even my Pictures folder!
tg...@google.com <tg...@google.com> #9
Thanks Jomo and everyone. We recently identified a bug that could be related to this.
Hi Davy, can you share the directory structure of your project. Where is the NDK located with respect to the project? Also where are your cpp files with respect to the rest of the project files?
Hi Davy, can you share the directory structure of your project. Where is the NDK located with respect to the project? Also where are your cpp files with respect to the rest of the project files?
ma...@gmail.com <ma...@gmail.com> #10
On my end, the files built into the native library are outside the project tree seen by Android Studio (they're accessed in the CMakeList file with eg. ../../../../folder/file.cpp). It sounds like this may trigger the issue
uc...@google.com <uc...@google.com>
jo...@google.com <jo...@google.com> #11
@Emmanuel, do you have only sources outside of the project tree or also CMakeLists.txt?
ma...@gmail.com <ma...@gmail.com> #12
Only the sources; CMakeLists.txt is under "app" in the tree that is seen by Android Studio
ma...@gmail.com <ma...@gmail.com> #13
Thanks for looking into this btw, much appreciated!
an...@supercell.com <an...@supercell.com> #14
Common factor here seems to be that cpp files are located out of android studio/gradle directory structure.
In our case, we use separate android module/library to build cpp files. That module is not a subdirectory of the root project, but located ../../xxx/yyy location. cpp files that this module builds, are also located in multiple levels down from module root level. eg ../../xx/yy.
I think there is a bug somewhere where it resolves the paths. I'm quite sure that it would work if I create enough empty dummy directories before android studio directory, so that it would not leak out from there, or a separate empty disk image for project :)
This "scanning files bug" has been there also in 3.3 preview. I reported that herehttps://issuetracker.google.com/issues/112927150 on August 2018.
In our case, we use separate android module/library to build cpp files. That module is not a subdirectory of the root project, but located ../../xxx/yyy location. cpp files that this module builds, are also located in multiple levels down from module root level. eg ../../xx/yy.
I think there is a bug somewhere where it resolves the paths. I'm quite sure that it would work if I create enough empty dummy directories before android studio directory, so that it would not leak out from there, or a separate empty disk image for project :)
This "scanning files bug" has been there also in 3.3 preview. I reported that here
ex...@gmail.com <ex...@gmail.com> #15
@tg
The NDK is in a subfolder of F:\Android
CPP files are in subfolders of the project's src/main/jni folder (F:\Development\AS\USBTester\USBTester\src\main\jni)
I have a zip file with a project I can send to you if you contact me privately.
The NDK is in a subfolder of F:\Android
CPP files are in subfolders of the project's src/main/jni folder (F:\Development\AS\USBTester\USBTester\src\main\jni)
I have a zip file with a project I can send to you if you contact me privately.
jo...@google.com <jo...@google.com> #16
Thanks Davy, I'm emailing you privately
ar...@google.com <ar...@google.com>
np...@gmail.com <np...@gmail.com> #17
Same situation and same problem with 3.3: we've got cpp files outside of (C:\programs\projectName\src) our Android Studio project structure (C:\programs\projectName\build\android). Android Studio indexes the entire drive and runs out of memory while "loading symbols" and crashes.
In the app.iml file, it looks like Android Studio has added C:\ as a sources root. Manually changing that to C:\programs\projectName and restarting Android Studio causes the first round of indexing to complete quickly and behave normally for a few seconds, after which it overwrites the file almost immediately with the same C:\ sources root again, after which it enters the same indexing loop forever.
In the app.iml file, it looks like Android Studio has added C:\ as a sources root. Manually changing that to C:\programs\projectName and restarting Android Studio causes the first round of indexing to complete quickly and behave normally for a few seconds, after which it overwrites the file almost immediately with the same C:\ sources root again, after which it enters the same indexing loop forever.
tg...@google.com <tg...@google.com> #18
Hi Nicholas, do you use cmake or ndk-build for your native code? Can you provide more information on the structure of your project? Specifically how are the cpp files referenced? Thank you!
np...@gmail.com <np...@gmail.com> #19
We use ndk-build. This is on a Windows 8.1 machine. Here are the (lightly sanitized) gradle and mk files: https://www.dropbox.com/s/wl826flzufuzldq/androidBuild.zip?dl=0 Importing those from scratch caused the same problem several times in a row.
There are a couple absolute paths in there. I worried that might have been causing the "C:\" sources root, but even making them relative paths (and importing from scratch again) didn't fix it.
There are a couple absolute paths in there. I worried that might have been causing the "C:\" sources root, but even making them relative paths (and importing from scratch again) didn't fix it.
[Deleted User] <[Deleted User]> #20
Same here, but on macOS High Sierra, Android Gradle Plugin 3.3.0, Gradle: 4.10.1, NDK 18.1.5063045, using ndk-build.
Scanning files to index was taking hours, so I left it overnight. In the morning I find the Android Studio process had read 185.35 GB from the disk and is now asking for more RAM. It either tries to read my whole disk (which is about 400 GB), or reads the same data over and over again. I'm not going to give this thing more RAM to do more of what it does now.
I never imagined that it can get any worse than Android Studio 3.2, but 3.3 is plain unusable.
Scanning files to index was taking hours, so I left it overnight. In the morning I find the Android Studio process had read 185.35 GB from the disk and is now asking for more RAM. It either tries to read my whole disk (which is about 400 GB), or reads the same data over and over again. I'm not going to give this thing more RAM to do more of what it does now.
I never imagined that it can get any worse than Android Studio 3.2, but 3.3 is plain unusable.
an...@supercell.com <an...@supercell.com> #21
I tried to create 5 levels of empty directories before the actual project directory, but it did not help. Still stuck on scanning files.
But, I discovered that creating a disk image (MacOS with Diskutility), copied project there and opened. Now the scanning phase completed. Tested with two projects that got stuck when working under home direcotry. Both worked this way.
But, I discovered that creating a disk image (MacOS with Diskutility), copied project there and opened. Now the scanning phase completed. Tested with two projects that got stuck when working under home direcotry. Both worked this way.
jo...@google.com <jo...@google.com> #22
Thank you for the repro case Nicholas it was extremely helpful. I have a change in flight for 3.3.1 that should fix it.
I don't have a workaround for you but this happens in the case that ndk-build is used and a target builds sources from NDK's android_app_glue along with sources in project folder. In this case, Android Studio incorrectly finds the common ancestor folder, C:\. There may be other ways to hit the bug but that's what's happening in your case.
I don't have a workaround for you but this happens in the case that ndk-build is used and a target builds sources from NDK's android_app_glue along with sources in project folder. In this case, Android Studio incorrectly finds the common ancestor folder, C:\. There may be other ways to hit the bug but that's what's happening in your case.
an...@supercell.com <an...@supercell.com> #23
Getting this stack trace also. Seems to be related.
java.lang.Throwable: The file '/' is not under content entry root '/Applications/Android Studio.app/Contents/bin'
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:126)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertFolderUnderMe(ContentEntryImpl.java:378)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:290)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:285)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:209)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:216)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:202)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:195)
at com.android.tools.ndk.GradleWorkspace.lambda$updateContentRoots$7(GradleWorkspace.java:399)
at com.intellij.openapi.roots.ModuleRootModificationUtil.updateModel(ModuleRootModificationUtil.java:143)
at com.android.tools.ndk.GradleWorkspace.updateContentRoots(GradleWorkspace.java:374)
at com.android.tools.ndk.GradleWorkspace.lambda$null$0(GradleWorkspace.java:302)
at com.intellij.openapi.roots.impl.ProjectRootManagerImpl.mergeRootsChangesDuring(ProjectRootManagerImpl.java:295)
at com.android.tools.ndk.GradleWorkspace.lambda$null$2(GradleWorkspace.java:301)
at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:1038)
at com.android.tools.ndk.GradleWorkspace.lambda$updateGradleWorkspace$3(GradleWorkspace.java:297)
at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:447)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:431)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:415)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
at java.awt.EventQueue.access$500(EventQueue.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:715)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:817)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:758)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:394)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
java.lang.Throwable: The file '/' is not under content entry root '/Applications/Android Studio.app/Contents/bin'
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:126)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertFolderUnderMe(ContentEntryImpl.java:378)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:290)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:285)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:209)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:216)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:202)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:195)
at com.android.tools.ndk.GradleWorkspace.lambda$updateContentRoots$7(GradleWorkspace.java:399)
at com.intellij.openapi.roots.ModuleRootModificationUtil.updateModel(ModuleRootModificationUtil.java:143)
at com.android.tools.ndk.GradleWorkspace.updateContentRoots(GradleWorkspace.java:374)
at com.android.tools.ndk.GradleWorkspace.lambda$null$0(GradleWorkspace.java:302)
at com.intellij.openapi.roots.impl.ProjectRootManagerImpl.mergeRootsChangesDuring(ProjectRootManagerImpl.java:295)
at com.android.tools.ndk.GradleWorkspace.lambda$null$2(GradleWorkspace.java:301)
at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:1038)
at com.android.tools.ndk.GradleWorkspace.lambda$updateGradleWorkspace$3(GradleWorkspace.java:297)
at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:447)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:431)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:415)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
at java.awt.EventQueue.access$500(EventQueue.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:715)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:817)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:758)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:394)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
74...@gmail.com <74...@gmail.com> #24
Seems related to this issue https://issuetracker.google.com/123131649
Somehow the home directory is being added as a source root:
<component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_1_7">
<output url="file://$MODULE_DIR$/build/intermediates/javac/debug/compileDebugJavaWithJavac/classes" />
<output-test url="file://$MODULE_DIR$/build/intermediates/javac/debugUnitTest/compileDebugUnitTestJavaWithJavac/classes" />
<exclude-output />
<content url="file://$USER_HOME$">
<sourceFolder url="file://$USER_HOME$" isTestSource="false" /> <------ Bad
....
Which forces the entire contents of the user's home directory to be scanned and indexed. We are using C++ libraries outside of the project's root - namely prebuilt Conan packages located in ~/.conan. Is there any workaround?
Somehow the home directory is being added as a source root:
<component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_1_7">
<output url="file://$MODULE_DIR$/build/intermediates/javac/debug/compileDebugJavaWithJavac/classes" />
<output-test url="file://$MODULE_DIR$/build/intermediates/javac/debugUnitTest/compileDebugUnitTestJavaWithJavac/classes" />
<exclude-output />
<content url="file://$USER_HOME$">
<sourceFolder url="file://$USER_HOME$" isTestSource="false" /> <------ Bad
....
Which forces the entire contents of the user's home directory to be scanned and indexed. We are using C++ libraries outside of the project's root - namely prebuilt Conan packages located in ~/.conan. Is there any workaround?
qu...@gmail.com <qu...@gmail.com> #25
A workaround that I have found is that when I see that is indexing "C:\" in the "Project Source Files" pane. I go to the app.iml file and remove the content tag that has the "C:\" and save the file. That does that it stops the indexation of "C:\" and continue with the correct source directories.
But that makes that when the indexation "ends", it gets "stuck" (actually looks like is loading something, but never ends), in order to solve that I go to the Gradle pane and refresh the gradle project. When it is finally done, the indexing also ends and Android Studio allows me to build the project.
But that makes that when the indexation "ends", it gets "stuck" (actually looks like is loading something, but never ends), in order to solve that I go to the Gradle pane and refresh the gradle project. When it is finally done, the indexing also ends and Android Studio allows me to build the project.
tg...@google.com <tg...@google.com>
jo...@google.com <jo...@google.com>
ma...@gmail.com <ma...@gmail.com> #26
This particular issue is confirmed as fixed in 3.3.1. The scanning and indexing is still an order of magnitude slower than 3.2.1 (as is Android Studio overall), but at least now it completes in minutes vs. hours and doesn't crash or run out of memory anymore as per this ticket.
ar...@google.com <ar...@google.com> #27
Thanks for verifying!
Can you provide more context around the scanning and indexing slowness you observed with 3.3.1 compared to 3.2.1?
Is it the same ashttps://issuetracker.google.com/issues/121340427 or something else?
Thanks!
Can you provide more context around the scanning and indexing slowness you observed with 3.3.1 compared to 3.2.1?
Is it the same as
Thanks!
ro...@gmail.com <ro...@gmail.com> #28
Although the bug is fixed, I still experiment the same problem in Android Studio 3.2.2 and 3.4.
When opening a project with a large amount of .h files (webrtc library), It takes around 10 mins in the indexing phase (long time but ok). The problem comes in the Building Symbols stage, it eats all the RAM avaiable and ends with a Low memory warning that makes the IDE unusable.
You can see in the attached screenshot where I configured the IDE to use 8Gb of RAM. If you increase the value it doesn't solve anything, it just does not stop consiming RAM until it hits the limit, no matter how high it is.
3.2 works ""ok"" (at least it doesn't freeze, but no code completion, syntax highlighting... )
Is there any workaround that could mitigate the issue?
When opening a project with a large amount of .h files (webrtc library), It takes around 10 mins in the indexing phase (long time but ok). The problem comes in the Building Symbols stage, it eats all the RAM avaiable and ends with a Low memory warning that makes the IDE unusable.
You can see in the attached screenshot where I configured the IDE to use 8Gb of RAM. If you increase the value it doesn't solve anything, it just does not stop consiming RAM until it hits the limit, no matter how high it is.
3.2 works ""ok"" (at least it doesn't freeze, but no code completion, syntax highlighting... )
Is there any workaround that could mitigate the issue?
ar...@google.com <ar...@google.com> #29
Hi, can you give us some idea about the scale of the number of .h files in your library?
And if it's open source, where we can try to repro it ourselves, that would be even better.
And if it's open source, where we can try to repro it ourselves, that would be even better.
[Deleted User] <[Deleted User]> #30
This bug is still showing in 3.4......
ro...@gmail.com <ro...@gmail.com> #31
To comment #29
Thanks for answering!
Our project has around 60.000 .h/.hpp files.
Unfortunately our project is not open source, however, our biggest dependency is webrtc which is.
I would say that if you create a project that depends on webrtc, you will see the same problem.
Thanks for answering!
Our project has around 60.000 .h/.hpp files.
Unfortunately our project is not open source, however, our biggest dependency is webrtc which is.
I would say that if you create a project that depends on webrtc, you will see the same problem.
tg...@google.com <tg...@google.com> #32
Hi, I tried downloading the WebRTC source code following instructions from https://webrtc.org/native-code/android/ . There seems to be no CMakeLists.txt in the project and there are ~2300 headers in it. Do you create custom CMakeLists in order to include WebRTC as a dependency for your project?
Also, do you by any chance use Android Studio to open the generated gradle file in stephttps://webrtc.org/native-code/android/#using-android-studio ?
Also, do you by any chance use Android Studio to open the generated gradle file in step
ho...@gmail.com <ho...@gmail.com> #33
Hello, I am experiencing the same problem on 3.4. My project has around 2,000 .h, .c, and .cpp files. They are located across many different paths on my hard drive. Is there any progress on this issue? Thank you.
ar...@gmail.com <ar...@gmail.com> #34
vi...@gmail.com <vi...@gmail.com> #35
This bug is not fixed on Android Studio 4.1.
Same behaviour. Same setup. OS X, c++
Found SO question that describes this as well on 4.1.
https://stackoverflow.com/questions/64401439/
Same behaviour. Same setup. OS X, c++
Found SO question that describes this as well on 4.1.
an...@supercell.com <an...@supercell.com> #36
Yes, I have exactly the same issue happening also again with 4.1. With 4.2 it works again.
mi...@gmail.com <mi...@gmail.com> #37
Exact same issue. It is paralyzing for all ndk c++ game developers. AS 4.1. Thanks
jo...@google.com <jo...@google.com> #38
This is fixed in 4.2 and later
ph...@googlemail.com <ph...@googlemail.com> #39
Comment has been deleted.
Description
There was also svn error, that said that my home folder was not in svn. Not sure if it tries to index my whole home folder now..
Everything works fast if I use experimental use active configuration only setting, but then I cant see my cpp files :(
Build: 3.3, AI-182.5107.16.33.5199772, 201812250239,
AI-182.5107.16.33.5199772, JRE 1.8.0_152-release-1248-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.1 unknown, screens 2560x1440; Retina
Android Gradle Plugin: 3.3.0
Gradle: 4.10.2
NDK: from local.properties: 18.1.5063045; latest from SDK: 18.1.5063045;
LLDB: LLDB 3.1 (revision: 3.1.4508709)
CMake: from local.properties: (not specified); latest from SDK: 3.6.0-rc2; from PATH: (not found);
Source: user_sentiment_feedback
IMPORTANT: Please read