Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PyCharm crashes due to an Out of Memory Error when plugin is enabled #270

Closed
mathieu-lemay opened this issue Sep 25, 2023 · 12 comments
Closed

Comments

@mathieu-lemay
Copy link

mathieu-lemay commented Sep 25, 2023

Describe the bug
Whenever I open a project in PyCharm with the plugin enabled, it will freeze after about 30 seconds, then it will crash some time later.

To Reproduce
Steps to reproduce the behavior:

  1. Open a project in PyCharm
  2. Wait about 30 seconds

Note: I can't reproduce this on all of my projects, only some of them. For the projects that do cause this behavior though, it does it reliably.

Edit: I can reproduce with structlog. I needed to play a bit with the IDE to trigger the issue though, for example going in the interpreter settings.

Expected behavior
No freeze

Screenshots
N/A

Environments (please complete the following information):

  • IDE: PyCharm Professional 2023.2.1
  • OS: Arch Linux
  • Ruff Version: 0.0.291
  • Plugin version: 0.0.21

Additional context
See crash log
java_error_in_pycharm_53357.log.gz

@koxudaxi
Copy link
Owner

@mathieu-lemay
Thank you for creating the issue.
I tried to reproduce what you have indicated but could not reproduce it in my environment.
If the problem occurs with 0.0.21 and not with 0.0.20, I can identify the PR in question and will try to fix the code that seems to have the problem.

@mathieu-lemay
Copy link
Author

@koxudaxi Well I started PyCharm with the plugin version 0.0.21, and sure enough, it froze. I then downgraded the plugin to 0.0.20 to check and the issue disappeared.

Now the weird thing, I re-updated to 0.0.21 and no matter what project I open, I can not reproduce the issue anymore. I did tick the Use ruff-lsp option while I was on 0.0.20 so I though maybe it was that, but now even if I disable that option, I can't reproduce. Not sure what to make of that. I am still pretty certain I started having the issue after upgrading to 0.0.21 though.

I have another computer with the same issue, I'll try tomorrow if I can make the issue stop with the ruff-lsp option.

@koxudaxi
Copy link
Owner

@mathieu-lemay
Thank you for additional information.
In 0.0.21, the version of ruff is now retrieved to check if the format command is supported.
I am currently calling ruff --verison to get the version, but I think this is the cause of the hang. (e.g. being called infinitely in certain situations)
If the version is not cached, ruff --version is called when ruff is called.
I wanted to use the version of ruff installed in the project's virtual env, because it is easy to get the version of ruff.
However, the global ruff is not directly managed by the PyCharm project, so it is necessary to call ruff --version.
However, I don't think global ruff is changed frequently, so it may be enough to call ruff --version at project startup or at the time of global executable change.

@PasVegan
Copy link

Hi,
I have the exact same issue, like every 30-60 seconds I get that error. I have Ruff 0.0.21, Pycharm professional 2023.2.1 and my OS is arch linux.

here is the log:

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
	at java.base/java.lang.Thread.start0(Native Method)
	at java.base/java.lang.Thread.start(Thread.java:802)
	at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:945)
	at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
	at java.base/java.lang.ProcessHandleImpl.completion(ProcessHandleImpl.java:144)
	at java.base/java.lang.ProcessImpl.initStreams(ProcessImpl.java:363)
	at java.base/java.lang.ProcessImpl.lambda$new$0(ProcessImpl.java:326)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:325)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
	at com.intellij.execution.configurations.GeneralCommandLine.startProcess(GeneralCommandLine.java:432)
	at com.intellij.execution.configurations.GeneralCommandLine.createProcess(GeneralCommandLine.java:346)
	at com.intellij.execution.process.OSProcessHandler.startProcess(OSProcessHandler.java:84)
	at com.intellij.execution.process.OSProcessHandler.<init>(OSProcessHandler.java:44)
	at com.intellij.execution.process.CapturingProcessHandler.<init>(CapturingProcessHandler.java:20)
	at com.koxudaxi.ruff.RuffKt.runCommand(Ruff.kt:199)
	at com.koxudaxi.ruff.RuffKt.runCommand(Ruff.kt:178)
	at com.koxudaxi.ruff.RuffKt.runRuff(Ruff.kt:289)
	at com.koxudaxi.ruff.RuffKt.runRuff(Ruff.kt:246)
	at com.koxudaxi.ruff.RuffCacheService$getVersion$$inlined$executeOnPooledThread$default$1.call(Ruff.kt:438)
	at com.intellij.openapi.application.impl.ApplicationImpl$3.call(ApplicationImpl.java:303)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
	at java.base/java.lang.Thread.run(Thread.java:833)

@mathieu-lemay
Copy link
Author

@koxudaxi I agree that checking only once at project startup should be sufficient. Even if someone opens a project while they have an older version of ruff without format support, then update the global ruff executable while the project is open, the worst that would happen is that the plugin wouldn't know about it until next project open. I could see a slight issue if a user downgrades ruff, but that is quite an edge case.

In the meantime, I think I figured out why I couldn't reproduce the issue anymore yesterday. Explicitly setting globalRuffExecutablePath seems to make the problem go away. I deleted the ruff.xml file from my project and sure enough, it crashed within a few minutes. Put the file back in the project, problem went away.

@PasVegan Maybe this could work for you too. Create a ruff.xml file in the .idea folder of your project with this:

<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
  <component name="RuffConfigService">
    <option name="globalRuffExecutablePath" value="/usr/bin/ruff" />
  </component>
</project>

@hannylicious
Copy link

I also had this issue recently (on v. 0.0.21)

When I enabled the plugin - I was working in project_A; when I opened project_B PyCharm came to a grinding halt and I couldn't figure out why.

I would force close it and reopen the previous project and it would work fine.

Then I disabled the plugin and opened project_B and had no issues. Then I re-enabled the plugin while working in project_B and have had zero issues.

I think it has something to do with opening a new project that has never used the plugin before with the plugin enabled or something along those lines.

However I checked the box to use my global installation of ruff as well. But after disable / open project_B / enable the plugin while working in that project?

I haven't seen any issues in any other projects.

My guess would be something with the original setting/initializing of the plugin somewhere?

@koxudaxi
Copy link
Owner

Thank you all for your comments.
They are accommodating.
I have temporarily stopped publishing the plugin because 0.0.21 has only an experimental feature added, which was too problematic.
I want to release a fixed version tomorrow or next tomorrow, but after that JetBrains will need to approve on the JetBrains side, so there maybe a low probability that it will be released this week.

@koxudaxi
Copy link
Owner

The following policies are used to create this PR.
#272

  • Run ruff --version asynchronously
  • Run ruff --version only in the following three patterns
    • When the package list is updated
    • When you save changes in the configuration screen
    • At project initialization (if version is undetected)

@koxudaxi
Copy link
Owner

Thank you for waiting for the fixed version.
I have released a fixed version.
However, it takes 1-2 business days for JetBrains to review it, so if you want to use the fixed version right now, please download the zip from the release page and install it manually.
If you have any feedback, please feel free to write any comments!

Fixed version: https://github.com/koxudaxi/ruff-pycharm-plugin/releases/tag/v0.0.22
How to install: https://koxudaxi.github.io/ruff-pycharm-plugin/install/#complied-binary

@mathieu-lemay
Copy link
Author

@koxudaxi I'm giving it a try, so far so good.

BTW, I just realized you also developed the Poetry plugin and the Pydantic plugin. Damn, keep up the good work!

@koxudaxi
Copy link
Owner

@mathieu-lemay
The version has been published in the market.
We can close the issue.
Thank you very much!!

@koxudaxi
Copy link
Owner

@mathieu-lemay
Thank you for sponsoring me!!
The support of people like you is very encouraging for my activities 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants