write_image hangs
neuron-whisperer opened this issue · comments
I'm running Python 3.9.6 on Windows 10 with Plotly 5.7.0 and Kaleido 0.2.1.
When I call:
figure.write_image(buffer)
...Plotly/Kaleido never returns and cannot be gracefully terminated; the script must be force-closed.
I first noticed this issue a year ago. The suggestions at that time were ineffective. Here we are a year later, at least two other users have posted the same issue, and there has been no resolution.
I have the same issue. Kernel unable to be interrupted once called and never executes. Same for fig.to_image(), and with any image format. this is using Plotly 5.4.0 and Kaleido 0.2.1 in a conda environment on windows 10. Unable to get a keyboard interrupt traceback as keyboard interrupt doesn't work.
Solutions such as disabling mathjax, and disabling internet connection when running have not worked.
Same here, last year with Python 3.8 and Plotly 4.14.3 it seemed to become stable somehow but never figured out why and how, now just upgraded to Python 3.9 and Plotly 5.7.0 as per my project requirements, and write_image randomly hangs with the exact same code in the exact same machine/configuration.
Same here, last year with Python 3.8 and Plotly 4.14.3 it seemed to become stable somehow but never figured out why and how, now just upgraded to Python 3.9 and Plotly 5.7.0 as per my project requirements, and write_image randomly hangs with the exact same code in the exact same machine/configuration.
Yes, the problem is that with same code and same environment, it hangs randomly, which doesn't make any sense.
In my case, I use gnu-parallel to do the exactly same jobs to produce .png files(with different input of course and same code), but some jobs produce image file while some don't and just hang indefinitely. So it has to be memory allocation or IO problem I assume.
The same issue happens in my environment. I've tried different Python versions (3.8 - 3.10). It seems that the problem happens on 64 bit version only.
a quick temporary fix is to use an old version before they fix it!
This version worked for me:
pip install kaleido==0.2.1.post1
In our case, we had to revert to pip install kaleido==0.1.0.post1 in win10/Python3.9
In our case, we had to revert to
pip install kaleido==0.1.0.post1in win10/Python3.9
Thanks for the hint, my write_image() call hangs as well in Windows 11/Python 3.10 before reverting to kaleido==0.1.0.post1
Not sure what @MahdiDavari was referring too but 0.2.1.post1 is not a legit package:
$ pip install kaleido==0.2.1.post1
WARNING: Ignoring invalid distribution -orch (..\anaconda3\envs\ds\lib\site-packages)
WARNING: Ignoring invalid distribution -orch (..\anaconda3\envs\ds\lib\site-packages)
ERROR: Could not find a version that satisfies the requirement kaleido==0.2.1.post1 (from versions: 0.0.1rc3, 0.0.1rc4, 0.0.1rc5, 0.0.1rc6, 0.0.1rc8, 0.0.1rc9, 0.0.1, 0.0.2, 0.0.3, 0.0.3.post1, 0.1.0a2, 0.1.0a3, 0.1.0, 0.1.0.post1, 0.2.0rc1, 0.2.0, 0.2.1)
ERROR: No matching distribution found for kaleido==0.2.1.post1
probably have to stick with kaleido==0.1.0.post1
Same on archlinux.
python 3.10.10
kaleido 0.2.1
plotly 5.14.1
It always success for first run, but if create image multiple times in a loop, it would randomly hangs.
CPU usage is high, but there is no error message.
I have the same blocking behaviour with this combination:
Windows: 10 22H2
Python: 3.11.3 (64bit)
plotly: 5.14.1
kaleido: 0.2.1
Same issue with Windows11, plotly 5.14.1, kaleido: 0.2.1
Same issue here:
Windows 10 21H2
Python 3.10.9
plotly 5.9.0
kaleido 0.2.1
Reverting to 0.1.0.post1 fixed the problem for me.
I have the same issue with the ToImage() function in plotly.Blazor. Works if the plot has no data, but as soon as data is added it hangs.
After having had this happen to me multiple times - It looks to me like this is happening in with some sort of subprocess communication happening with the kaleido subprocess, lines 300-308.
I'm using Python 3.10.11, GCC 11.2.0 on RHEL. kaleido: 0.2.1. This happened eventually to 2 subprocesses running in a loop.
The stack traces to me cancelling the process indicate where it is getting stuck in the same place in two completely independent processes...
in scopes scopes/base.py:
Line 308,
response = self._proc.stdout.readline()
I've not spent a lot of time working through this unfortunately, but for whatever reason the Kaleido C++/python communication is getting stuck on waiting for a response.
For anyone using plotly I just launch to process in a subprocess with a timeout and retry repeatedly until it works. Orca doesn't work for me in RHEL.
it's incredible this hasn't been fixed yet
+1
For what is worth, downgrading to kaleido==0.1.0.post1 fixed it for me using:
Windows 10 Entreprise 22H2
Python 3.11.1
plotly 5.17.0
In a course teaching programming to economists we have switched to plotly a while back. We were unaware of this issue back then because all course developers are on Linux or Mac.
For better or worse, for Masters' theses and papers we are stuck with static images. In a small block course we gave today, 5 out of 6 Windows users could not export their images. I really don't want to go back to matplotlib + seaborn, but explaining that to 50+ students in the upcoming term would also not be great.
The number may be small relative to total usage, but for us it is very large. Would there be any updates to the status report a year ago by any chance, @nicolaskruchten?
And btw, thanks a lot for a great tool (i.e., plotly) that I am enjoying everyday in notebooks!!!
In a course teaching programming to economists we have switched to plotly a while back. We were unaware of this issue back then because all course developers are on Linux or Mac.
For better or worse, for Masters' theses and papers we are stuck with static images. In a small block course we gave today, 5 out of 6 Windows users could not export their images. I really don't want to go back to matplotlib + seaborn, but explaining that to 50+ students in the upcoming term would also not be great.
The number may be small relative to total usage, but for us it is very large. Would there be any updates to the status report a year ago by any chance, @nicolaskruchten?
And btw, thanks a lot for a great tool (i.e., plotly) that I am enjoying everyday in notebooks!!!
If you follow the above comment and install the right version it should still work👍
You mean installing kaleido==0.1.0.post1 ?
You mean installing
kaleido==0.1.0.post1?
Yes, that fixes for me
I also had this same issue using Python 3.11.3 on a 64 bit Windows machine, and installing kaleido==0.1.0.post1 worked. However, my teammate is trying to install that kaleido version on his Linux machine and is getting "ERROR: No matching distribution found for kaleido==0.1.0.post1". But when he installed the latest version of kaleido (0.2.1) things worked fine for him and it didn't "hang" on the write_image() function like it does on mine with the latest version.
If it's not getting fixed, a warning should be thrown. plotly/plotly.py#4401
Note, conda install -c conda-forge python-kaleido==0.1.0 also worked for me.
So it seems like the above workaround does help. But it is the only thing preventing cross-platform environment files (provided there are packages for all platforms, of course), since that lone working version (Windows) does not exist on other platforms (example from Linux):
$ pip install kaleido==0.1.0.post1
ERROR: Could not find a version that satisfies the requirement kaleido==0.1.0.post1 (from versions: 0.0.1rc3, 0.0.1rc4, 0.0.1rc5, 0.0.1rc6, 0.0.1rc8, 0.0.1rc9, 0.0.1, 0.0.2, 0.0.3, 0.0.3.post1, 0.1.0a2, 0.1.0a3, 0.1.0, 0.2.0rc1, 0.2.0, 0.2.1)
ERROR: No matching distribution found for kaleido==0.1.0.post1
I understand that it might be too difficult to come up with a new version of kaleido that would actually solve the problems. Just re-releasing that old thing on Windows or at least the warning suggested in plotly/plotly.py#4401 with clear instructions on what to do would help a ton!
The same issue for
Windows 11, 23H2
python 3.8.17
plotly==5.15.0
kaleido>=0.2.0rc1,<=0.2.1
After switching back to kaleido==0.1.0.post1, it becomes normal.
I notice that my conda environment path contains a "space" (because it is installed in my user folder, while my user folder contains a "space"), I am not sure whether the issue is caused by this, but I am quite sure that I need to modify the script "C:\Users\User name\.conda\envs\env-name\Library\bin\kaleido.cmd" like this:
@echo off
-C:/Users/User name/.conda/envs/env-name\Library\bin\KaleidoApp/kaleido.cmd %*
+"C:/Users/User name/.conda/envs/env-name\Library\bin\KaleidoApp/kaleido.cmd" %*I did this when kaleido==0.2.1 was installed. If I do not modify it, the write_image(...) will not work at all. However, after I reinstalled kaleido==0.1.0.post1, my modification was still there, which made me a little bit frustrated.
Anyway, with all these configurations, the problem can be solved. Maybe I also need to test it in Linux. If I can get more results, I will post it here.
Update on 11/21/2023
I have confirmed that the kaleido==0.2.1 works on Linux (Debian 12). Certainly, the experiment is run when the Kaleido is installed in a folder with the path not containing spaces:
/usr/local/lib/python3.8/site-packages/kaleido/executable/bin/kaleido
I still have no idea whether the Windows write_image hang issue is caused by the space character in the path. I notice that this issue is marked as solved in issue #85. However, I think this path issue still exists in the newest version of Windows. Because it is not raised by the Python script, but raised by the kaleido.cmd (mentioned before).
it's incredible this hasn't been fixed yet
I agree completely, the 0.1.0.post1 version workaround worked for me on Win10 Python 3.9 but this functionality (saving a produced image) just seems to foundational that I don't understand why it's not a top priority. It only takes one incident like this before potential plotly users are turned off from ever trying it again.
Had to reply to this one.
IPC on Windows can be a nightmare. Things that don't block on Linux will block on Windows.
Anyways, a trivial workaround is a synchronous/single-process mode and use that as the default for windows. Or, scale it using a method that doesn't involve pipes (I suspect that's the issue here; and the nuances are many).
I may take a look, since Orca is also being a PITA right now. It certainly hurts my confidence in the Plotly ecosystem though.
Datapoint: kaleido 0.2.1 hangs on my environment. Work pushed us from conda and was previously using orca through conda.
Running Windows 10.0.19045, VSC, Python 3.12
Regular install of kaleido hung on write_image(), same as above. Removal was even difficult from my venv, pip uninstall didn't remove from site-packages. Lib was engaged when I tried to delete, found kaleido.exe running in the background via Task Manager but ending that still did not disengage whatever was running in the background. No soft reboots of apps fixed.
Restart computer and all apps. Was able to delete manually package from \venv\site-packages. Installed pip install kaleido==0.1.0.post1 and write_image() is working as expected.
I had the same problem using python 3.10 and going back to the suggested kaleido==0.1.0.post1 worked fine for me. Thanks to whoever suggested that!
Same issue with win11, downgraded and it works. Any further information? Any way to fix it that is not downgrading?