ClassCastException: class CaretSpecificDataContext cannot be cast to class DataManagerImpl$MyDataContext

[VhJoren]

Type of JetBrains IDE (IntelliJ, PyCharm, etc.) and version

Pycharm 2020.1

Operating System

Ubuntu 18

TeXiFy IDEA version

0.7-alpha.79 (compiled myself to be able to install in pycharm 2020.1 instead of 2020.2eap

Description

My CPU usage is around 85% from the moment I start working on a document and it remains that high. I think this is related to the bug. I am not working on an enumaration when this occurs. Is the plugin incompatible with pycharm 2020.1, causing the problem?

Stacktrace

java.lang.ClassCastException: class com.intellij.openapi.editor.actionSystem.CaretSpecificDataContext cannot be cast to class com.intellij.ide.impl.DataManagerImpl$MyDataContext (com.intellij.openapi.editor.actionSystem.CaretSpecificDataContext and com.intellij.ide.impl.DataManagerImpl$MyDataContext are in unnamed module of loader com.intellij.util.lang.UrlClassLoader @402f32ff)
    at nl.hannahsten.texifyidea.editor.InsertEnumerationItem.postProcessEnter(InsertEnumerationItem.kt:34)
    at com.intellij.codeInsight.editorActions.EnterHandler.executeWriteActionInner(EnterHandler.java:156)
    at com.intellij.codeInsight.editorActions.EnterHandler.lambda$executeWriteAction$0(EnterHandler.java:65)
    at com.intellij.psi.impl.source.PostprocessReformattingAspect.lambda$disablePostprocessFormattingInside$1(PostprocessReformattingAspect.java:102)
    at com.intellij.psi.impl.source.PostprocessReformattingAspect.disablePostprocessFormattingInside(PostprocessReformattingAspect.java:110)
    at com.intellij.psi.impl.source.PostprocessReformattingAspect.disablePostprocessFormattingInside(PostprocessReformattingAspect.java:101)
    at com.intellij.codeInsight.editorActions.EnterHandler.executeWriteAction(EnterHandler.java:64)
    at com.intellij.openapi.editor.actionSystem.EditorWriteActionHandler$1.run(EditorWriteActionHandler.java:51)
    at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:976)
    at com.intellij.openapi.editor.actionSystem.EditorWriteActionHandler.doExecute(EditorWriteActionHandler.java:64)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.execute(EditorActionHandler.java:201)
    at com.intellij.codeInsight.template.impl.editorActions.EnterHandler.executeWriteAction(EnterHandler.java:49)
    at com.intellij.openapi.editor.actionSystem.EditorWriteActionHandler$1.run(EditorWriteActionHandler.java:51)
    at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:976)
    at com.intellij.openapi.editor.actionSystem.EditorWriteActionHandler.doExecute(EditorWriteActionHandler.java:64)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.lambda$null$2(EditorActionHandler.java:191)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.doIfEnabled(EditorActionHandler.java:88)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.lambda$execute$3(EditorActionHandler.java:190)
    at com.intellij.openapi.editor.impl.CaretModelImpl.lambda$runForEachCaret$3(CaretModelImpl.java:298)
    at com.intellij.openapi.editor.impl.CaretModelImpl.doWithCaretMerging(CaretModelImpl.java:407)
    at com.intellij.openapi.editor.impl.CaretModelImpl.runForEachCaret(CaretModelImpl.java:307)
    at com.intellij.openapi.editor.impl.CaretModelImpl.runForEachCaret(CaretModelImpl.java:282)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.execute(EditorActionHandler.java:188)
    at com.intellij.xdebugger.impl.actions.handlers.XDebuggerSmartStepIntoHandler$SmartStepEditorActionHandler.doExecute(XDebuggerSmartStepIntoHandler.java:404)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.lambda$execute$4(EditorActionHandler.java:198)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.doIfEnabled(EditorActionHandler.java:88)
    at com.intellij.openapi.editor.actionSystem.EditorActionHandler.execute(EditorActionHandler.java:197)
    at com.intellij.openapi.editor.actionSystem.EditorAction.lambda$actionPerformed$0(EditorAction.java:98)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:220)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:178)
    at com.intellij.openapi.editor.actionSystem.EditorAction.actionPerformed(EditorAction.java:107)
    at com.intellij.openapi.editor.actionSystem.EditorAction.actionPerformed(EditorAction.java:82)
    at com.intellij.openapi.actionSystem.ex.ActionUtil.performActionDumbAware(ActionUtil.java:280)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher$1.performAction(IdeKeyEventDispatcher.java:609)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.lambda$processAction$3(IdeKeyEventDispatcher.java:670)
    at com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:94)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.processAction(IdeKeyEventDispatcher.java:669)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.processAction(IdeKeyEventDispatcher.java:619)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.processActionOrWaitSecondStroke(IdeKeyEventDispatcher.java:516)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.inInitState(IdeKeyEventDispatcher.java:470)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.dispatchKeyEvent(IdeKeyEventDispatcher.java:219)
    at com.intellij.ide.IdeEventQueue.dispatchKeyEvent(IdeEventQueue.java:896)
    at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:841)
    at com.intellij.ide.IdeEventQueue.lambda$null$8(IdeEventQueue.java:449)
    at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:741)
    at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$9(IdeEventQueue.java:448)
    at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:831)
    at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:502)
    at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

[PHPirates]

Do you have Evince installed? In one or two alpha releases, 78 or 79, there was a bug causing high cpu usage. Please update to 0.7-alpha.81 in any case. Does the alpha release actually work in 2020.1? If I remember correctly I raised the Since build because there were crashes from using functionality that did not yet exist in 2020.1 (though that was in IntelliJ).

Thanks for reporting the exception by the way, it is caused by a recent change I made for #1512, and could happen any time you press enter.

[VhJoren]

Do you have Evince installed? In one or two alpha releases, 78 or 79, there was a bug causing high cpu usage. Please update to 0.7-alpha.81 in any case.

Yes, I do use Evince, but that should not be related, as I do not use the 'sync-with-pdf' feature (or whathever it is called. I use my own scripts to compile latex.). I now updated to 0.7-alpha.81 and 2020.2eap, but my cpu usage is still high. Anything I can do about it? My fan is constantly spinning up and it is not good for the electricity bill ;)

Does the alpha release actually work in 2020.1? If I remember correctly I raised the Since build because there were crashes from using functionality that did not yet exist in 2020.1 (though that was in IntelliJ).

I built it from the latest commit on the master branch and it seemed to work in 2020.1, yes.

Thanks for reporting the exception by the way, it is caused by a recent change I made for #1512, and could happen any time you press enter.

Ah yes, I now see the pattern!

[PHPirates]

Can you try the following build, which has the EvinceInverseSearchListener disabled? If the issue is still there, then it was not the same issue as in alpha.79, and I have no idea what it could be. If the issue disappears, then I need to figure out how it is possible that I don't see high cpu usage myself but you do.

TeXiFy-IDEA-0.7-alpha.81-vhjoren.zip

I built it from the latest commit on the master branch

That explains it, because the code for 2020.2 is still in #1454 I could publish alpha releases for 2020.1 as well, and we can see whether there are users for those.

[VhJoren]

Can you try the following build, which has the EvinceInverseSearchListener disabled? If the issue is still there, then it was not the same issue as in alpha.79, and I have no idea what it could be. If the issue disappears, then I need to figure out how it is possible that I don't see high cpu usage myself but you do.

TeXiFy-IDEA-0.7-alpha.81-vhjoren.zip

The cpu usage remains high, also for this special build. The error disappeard, though :D

For a moment, I thought it might be related to the large file that I am working on: splitting it up in smaller parts seemed to make the cpu usage decrease. However, I now opened up a smaller project and the problem also occurs there.

cpu usage hovers at around 40% while scrolling through my documents and it goes up to 80-90% while typing.

[PHPirates]

Hm, that's not good. Since it's not the same issue (which simply locked 1 cpu for 100% in a busy loop), can you perhaps run a profiler on that TeXiFy version, and upload the snapshot here? See https://github.com/Hannah-Sten/TeXiFy-IDEA/wiki/Contributing-to-TeXiFy#debugging-performance-issues (I'm assuming you don't have continuous compilation selected in settings, in which case this would be sort of expected behaviour).

[VhJoren]

I am trying to, but github complains that it does not support the .nps file type.

In my case, all four threads go the the percentages I mentioned.

[VhJoren]

I think part of the issue might be in the code analysis. When I just type a space somewhere in my document, the 'inspections' progress bar from the code analysis starts reloading and it takes about 5 seconds before it is finished.

edit: I turned off all latex inspections, but to no avail...

[PHPirates]

I suppose you would need to zip the nps file. I just took a look as well, and it looks like the fileset cache is broken again, which would explain the cpu usage. I still need to confirm that though, and it would not explain CPU usage when not interacting with Pycharm. I just was distracted by other continuous high (20%) CPU usage, but it came from a bug in the markdown plugin.

[Edit] Fileset cache does not seem broken on master at least, not sure why I saw that in the profiler. Also I do have some slowness in typing in my main IntelliJ, but not when I run TeXiFy from master.

[VhJoren]

snapshot-texify.zip

This is what I get while running the special build you made. I realize this is a bit like finding a needle in a haystack.

I am getting the feeling that I am wasting your time: I disabled TeXiFy and the cpu usage while scrolling is still high! This problem seemd to have started after updating TeXiFy, but perhaps I changed other things concurrently.

[PHPirates]

Thanks for the snapshot! Indeed, I see no unusually large sampled times from TeXiFy. This haystack is not so big, compared to the one for supporting update without restart.... If you are still using Pycharm 2020.1 I wouldn't expect it to be the same bug from the markdown plugin (which is bundled), especially if you don't have JCEF previews open. Please let me know if you find the cause (even if it's not TeXiFy).

No problem, I'm glad you thought of disabling TeXiFy as well. You didn't waste any time, the markdown bug did though :)