You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yesterday I found my calculation was not started after 11 hours.
I spend a whole day trace down the problem and found it is caused by cmd.read_pdbstr from a pymol2.PyMOL() session, which use to load PDB string into a pymol session in my Python script.
I then engineered a minimum reproduction of the bug in a simple script. I also found this bug does not exist in a specific pymol version I installed from a place I dont remember. (not the one in this repo) See reproduction below.
To Reproduce
Steps to reproduce the behavior:
create a new conda environment
run conda install pymol-open-source -c conda-forge (This installed version=3.1.0 build=py39he07333a_0 on my machine)
run this script:
import multiprocessing
import pymol2
def grow_each_window(args):
print("start")
call_read_pdbstr()
print("pass")
def call_read_pdbstr():
pms = pymol2.PyMOL()
pms.start()
pdb_str = "ATOM 1 N ASP A 1 45.117 64.639 61.562 1.00 0.00"
pms.cmd.read_pdbstr(pdb_str, "obj1")
pms.stop()
call_read_pdbstr()
with multiprocessing.Pool(processes=4) as pool:
pool.map(grow_each_window, range(3))
You will see the script stuck after printing start and never print out pass
Analysis
I made several experiment that removes the forever sleep
comment out line 16 in the script, that is, not calling read_pdbstr() before the Pool.
This will instantly print the "pass" out
Use another environment in my machine.
lt also instantly print the "pass" out?!
In that environment, if I run conda list pymol, I got:
# Name Version Build Channel
pymol 2.5.4 py39he7683a9_0 schrodinger
pymol-bundle 2.5.3 0 schrodinger
pymol-web-examples 2.4 1 schrodinger
For now I failed in all attempts reproducing this environment lol.
Analyzing the sleep process with pid shows that it is waiting for a lock
I found if I set the start method of multiprocessing to "spawn" install of the default "fork" the problem is gone. However, fork is in principle more efficient and likely there is a bug related to pymol2.PyMol()
Describe the bug
Yesterday I found my calculation was not started after 11 hours.
I spend a whole day trace down the problem and found it is caused by
cmd.read_pdbstr
from apymol2.PyMOL()
session, which use to load PDB string into a pymol session in my Python script.I then engineered a minimum reproduction of the bug in a simple script. I also found this bug does not exist in a specific pymol version I installed from a place I dont remember. (not the one in this repo) See reproduction below.
To Reproduce
Steps to reproduce the behavior:
conda install pymol-open-source -c conda-forge
(This installed version=3.1.0 build=py39he07333a_0 on my machine)Analysis
I made several experiment that removes the forever sleep
This will instantly print the "pass" out
lt also instantly print the "pass" out?!
In that environment, if I run
conda list pymol
, I got:For now I failed in all attempts reproducing this environment lol.
Analyzing the sleep process with pid shows that it is waiting for a lock
Environment
conda list
click to see full list
The text was updated successfully, but these errors were encountered: