IssueTracker

This issue does not reproduce with dev preview 4.

Closing this issue as per comment #2 from reporter.

I can confirm this problem on OpenSUSE Linux 13.2 (KDE 4.14.3). Logcat is empty when trying to debug either on an emulator or a real device. While trying to refresh / restart and configure the logcat view I'm getting dozens of ArrayIndexOutOfBounds exception messages in the events log. After a minute or so the whole IDE becomes more and more unresponsive and the UI elements do not get redrawn anymore (see second screenshot), unless I hover with the mouse over them individually. I already sent three of those exception messages to Google using the built-in report feature.

Could you attach your idea.log file? (Help | Show Log in Explorer)

Also, did you happen to clear logcat from the UI?

Thanks for your quick response. I attached the idea.log file to this comment.

To answer your question: yes, I also cleared logcat from the UI, tried to change filter configurations and also clicked several times the "restart logging" button.
The logcat view remains empty all the time. Sometimes it appears as if it was filled with contents. The horizontal and vertical scrollbars show up, but the view itself remains blank.

There is a bug in the Android platform which causes logs to not show up if you do a clear from the UI. The IDE needs to work around that bug, and that is tracked in Issue 36949180.

I'll keep this issue around to investigate the out of bounds exceptions.

Sorry, my mistake: the logcat view is also empty when I do not clear the log (or push any of the other logcat buttons). The view is always empty.

The same issue on my Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

The same bug on Arch Linux and on Ubuntu 14.04. To be more funny on ddms i have a logcat and everything is fine, but in windows in Android studio (ctrl+6) i have a empty window, nothing is show.

I confirm this problem on opensuse 13.1 64 bit. Sometimes the first 1 or 2 lines appear, then the logcat windows is cleared and seems to remain empty. But: it is possible to copy and paste the (invisible, maybe white text on white background?) text to another editor. As described by dev.nobu the whole Android Studio becomes more and more unresponsive.
Environment: Opensuse 13.1 X86_64, openjdk 1.7.0_55.
I cannot see the problem on my older notebook setup with opensuse 12.3 x86_64 with openjdk 1.7.0_15, but I cannot test on this machine using the emulator due to memory restrictions.

Meanwhile I can confirm this problem also with Oracle java 1.8 on opensuse 13.1.

I just got an update to Android Studio 1.2 Build #AI-141.1890965 April 29, 2015. The logcat problem as described above is NOT fixed.

I also facing this issue. The logcat does not display any thing. Any solution for this problem?

Guys , this issue is driving me crazy. I'm on Mac with Yosemite 10.10.3. How are we supposed to develop without Logact ?

It seems like killing and restarting the adb server outside of Android Studio after starting it get it to work some times.

Archlinux, awesome 3.5.6
$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

Android Studio AI-141.2024585

Sorry, killing and starting the adb server doesn't change anything. And I wouldn't expect it because it is possible to print the (invisible) contents of the logcat window... so I guess the adb server works correct but the Android Studio windows has some trouble to display the contents.
I can even "print" the contents to a file - this "out.ps" seems to be empty when opened in okular, invalid when opened with gimp but displays the correct content when imported with inkscape ;-)

For Xubuntu 15.04, Android Studio 1.2.2 I stopped trying to get logcat to work inside Android Studio as the solutions I've found don't work.

Now I just open a terminal, cd to the platform-tools directory and type:

$ adb get-state
$ adb logcat|grep my_app_name

Seems to take a bit for logcat to catch up to my current debugging process but it does work.

A more comfortable workaround is starting the "Android Device Monitor" from within Android Studio (green Android icon at the right end of the tool bar). That opens an Eclipse RCP application that consists only of the "DDMS" perspective provided by the ADT plugin for Eclipse. The only downside is that you cannot debug and use the device monitor at the same time.

As far as I can see logcat inside AS works in AS 1.3 RC4, Build #AI-141.2112779.
JRE 1.8.0_51-b16
SDK Platform-tools 23rc4
SDK Tools 24.3.3

Running Archlinux and Awesome VM.

I just got an update to Android Studio 1.3. The logcat problem as described above is NOT fixed. The first error message in events is now:

-29359205
java.lang.ArrayIndexOutOfBoundsException: -29359205
        at sun.font.FileFontStrike.getCachedGlyphPtr(FileFontStrike.java:472)
        at sun.font.FileFontStrike.getSlot0GlyphImagePtrs(FileFontStrike.java:438)
        at sun.font.CompositeStrike.getGlyphImagePtrs(CompositeStrike.java:115)
        at sun.font.GlyphList.mapChars(GlyphList.java:272)
        at sun.font.GlyphList.setFromString(GlyphList.java:244)
        at sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:71)
        at sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2928)
        at com.intellij.openapi.editor.impl.EditorImpl.drawChars(EditorImpl.java:3527)
        at com.intellij.openapi.editor.impl.EditorImpl.access$4800(EditorImpl.java:128)
        at com.intellij.openapi.editor.impl.EditorImpl$CachedFontContent.flushContent(EditorImpl.java:3062)
        at com.intellij.openapi.editor.impl.EditorImpl$CachedFontContent.access$5100(EditorImpl.java:3027)
        at com.intellij.openapi.editor.impl.EditorImpl.flushCachedChars(EditorImpl.java:3114)
        at com.intellij.openapi.editor.impl.EditorImpl.paintText(EditorImpl.java:2975)
        at com.intellij.openapi.editor.impl.EditorImpl.paint(EditorImpl.java:2057)
        at com.intellij.openapi.editor.impl.EditorComponentImpl.paintComponent(EditorComponentImpl.java:162)
        at javax.swing.JComponent.paint(JComponent.java:1056)
        at com.intellij.openapi.editor.impl.EditorComponentImpl.paint(EditorComponentImpl.java:74)
        at javax.swing.JComponent.paintChildren(JComponent.java:889)
        at javax.swing.JComponent.paint(JComponent.java:1065)
        at javax.swing.JViewport.paint(JViewport.java:728)
        at com.intellij.ui.components.JBViewport.paint(JBViewport.java:122)
        at javax.swing.JComponent.paintChildren(JComponent.java:889)
        at javax.swing.JComponent.paint(JComponent.java:1065)
        at javax.swing.JComponent.paintToOffscreen(JComponent.java:5219)
        at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
        at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)
        at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
        at javax.swing.JComponent._paintImmediately(JComponent.java:5167)
        at javax.swing.JComponent.paintImmediately(JComponent.java:4978)
        at javax.swing.RepaintManager$4.run(RepaintManager.java:824)
        at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
        at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)
        at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
        at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
        at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:734)
        at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:569)
        at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:382)
        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)

Hope it helps to fix this error finally.

Having this issue as well on 1.3...

Thanks all, feel free to keep the updates coming. Just wanted to let you know someone is looking at this, although I'm still at the stage where I'm trying to reproduce the issue.

I just had the same problem after updating to 1.3, but was able to fix it. What I did was: Click on "File" -> "Invalidate Caches / Restart..." and then on "Invalidate & Restart". After the restart, logcat started working fine again.

For me invalidating caches does not fix the problem. Also the brandnew version 1.3.1 continues with this bug. (I tried also to invalidate the caches for this version as described without success)

This may be related with the problems desciribed here http://awesome.naquadah.org/wiki/Problems_with_Java.
As over the summer I have been using a stationary computer with a "regular" Nvidia GTX960 graphics, still running Arch Linux with Awesome WM, and have had no problem what so ever. Going back to a Thinkpad with Intel HD4000 graphics there is no visible logcat, but rather just "graphical mess" due to how things are drawn on the screen.

The software/OS on the above mentioned machines are otherwise identical, which makes me think that it is how Java handles drawing using different graphics that makes the difference. Not sure if this helps, but it might be an interesting finding.

Android Studio AI-141.2168647
Build #AI-141.2168647, built on August 14, 2015
JRE: 1.8.0_51-b16 amd64
JVM: Java HotSpot(TM) 64-Bit Server VM by Oracle Corporation

Hey all, was digging into this and I found the following bug from JetBrains (the codebase we sit on top of): https://youtrack.jetbrains.com/issue/IDEA-121793

Excerpt:
======================
It can happen on a Linux system when a large number of fonts is installed in the system (in OpenSuSE it's known to happen after installing texlive package). To verify whether one's system is susceptible, one can check the contents of ~/.java/fonts/<javaVersion>/fcinfo-<...>.properties. This file caches the mapping of logical java fonts to physical fonts. If it contains lines x.x.N.x=x where N>127, then the issue can be observed (it won't necessarily be as it happens only for rendering of certain characters). Uninstalling unnecessary fonts might help to avoid the issue.

The issue has been reported to JDK developers.
======================

Can anyone on here confirm if they are affected by this issue?

Running OpenSUSE here and the list of installed fonts is indeed tremendous. The mentioned Java font configuration file also contains many entries with N>127. I can also confirm the same kind of exception message from the JetBrains bug ticket:

-28834917
java.lang.ArrayIndexOutOfBoundsException: -28834917
        at sun.font.FileFontStrike.getCachedGlyphPtr(FileFontStrike.java:472)
        at sun.font.FileFontStrike.getSlot0GlyphImagePtrs(FileFontStrike.java:438)
        at sun.font.CompositeStrike.getGlyphImagePtrs(CompositeStrike.java:115)
        at sun.font.GlyphList.mapChars(GlyphList.java:272)
        at sun.font.GlyphList.setFromString(GlyphList.java:244)
        at sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:71)
        at sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2928)
        at com.intellij.openapi.editor.impl.EditorImpl.drawChars(EditorImpl.java:3527)
        at com.intellij.openapi.editor.impl.EditorImpl.access$4800(EditorImpl.java:128)
        at com.intellij.openapi.editor.impl.EditorImpl$CachedFontContent.flushContent(EditorImpl.java:3062)
        at com.intellij.openapi.editor.impl.EditorImpl$CachedFontContent.access$5100(EditorImpl.java:3027)
        at com.intellij.openapi.editor.impl.EditorImpl.flushCachedChars(EditorImpl.java:3114)
        at com.intellij.openapi.editor.impl.EditorImpl.paintText(EditorImpl.java:2975)
        at com.intellij.openapi.editor.impl.EditorImpl.paint(EditorImpl.java:2057)
        at com.intellij.openapi.editor.impl.EditorComponentImpl.paintComponent(EditorComponentImpl.java:162)
        at javax.swing.JComponent.paint(JComponent.java:1054)
        at com.intellij.openapi.editor.impl.EditorComponentImpl.paint(EditorComponentImpl.java:74)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JViewport.paint(JViewport.java:728)
        at com.intellij.ui.components.JBViewport.paint(JBViewport.java:122)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2332)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2327)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2332)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2327)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
        at javax.swing.JComponent.paintToOffscreen(JComponent.java:5222)
        at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
        at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)
        at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
        at javax.swing.JComponent._paintImmediately(JComponent.java:5170)
        at javax.swing.JComponent.paintImmediately(JComponent.java:4981)
        at javax.swing.RepaintManager$4.run(RepaintManager.java:824)
        at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
        at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)
        at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
        at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:702)
        at java.awt.EventQueue$3.run(EventQueue.java:696)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
        at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:734)
        at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:569)
        at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:382)
        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)

I can confirm this, I had a stacktrace just like in #35. I removed the ttf-google-fonts-git package from my Arch Linux install, ie. minus about 1500st fonts. No more font error, logcat seem to work as it should.

[Comment deleted]

Thanks for the updates so far. Especially Victor, glad to hear your font error was fixed.

We'll keep this bug in "NeedsInfo" status for a bit, so feel free to keep the feedback coming.

I can confirm this, too. I also had a similar stacktrace (see entry #23) and after removing some chinese fonts from tex the problem seems to be fixed preliminary.

Nevertheless I wished to get a different fix for this problem because these fonts are part of automatic dependencies of the tex package and I had to break/damage these dependencies in yast. I need the tex package so I don't want to risk this functionality.

Martin, I feel your pain. I'm not sure how much power we have over fixing the bug but at least it seems we have a root cause now. If anyone can suggest workarounds in the meanwhile, please share them here.

It looks like it has been already fixed in OpenJDK just a couple of weeks ago: https://bugs.openjdk.java.net/browse/JDK-8132850

The bad news is that it will take a while until the patch rolls out. For OpenJDK 8 it's scheduled for version 8u72 (see https://bugs.openjdk.java.net/browse/JDK-8133643), which in turn is scheduled to be released next year in January (see https://bugs.openjdk.java.net/browse/JDK/fixforversion/17669).

What makes me wonder with this bug is, why does it only affect the log cat view? All other dialogs and views work just fine. Is it a specific choice of a problematic font, that could be changed?

Reducing priority since the scope is now known and there's a workaround. See comments #33 and following

Still Empty LogCat!
Tried everything on the internet!
Any Solutions?!
This is so Annoying!!

Closing off comments on this bug because the workarounds posted by the community are valuable, and shouldn't get lost in other comments, at least until further active work happens on this.