jamesdolezal
commented
1 year ago Thanks, Sara. The error is not able to be reproduced in all environments, which makes me think this could be a software dependency issue. I will start by comparing software versions in detail with M1/M2 systems that work, to see if I can track down potential culprits. Can you upload your conda environment, so I can reproduce it locally?
skochanny
Description
On my M1 Mac, after installing slideflow via conda and pip
To Reproduce
Steps to reproduce the behavior:
Since I thought this was initially about package conflicts, I essentially started from scratch on my Mac with everything. I reinstalled conda & cleaned its cache, cleaned pip's cache, reinstalled homebrew, reinstalled xcode, and updated my Mac to the latest version. Then, I installed slideflow. As prereqs I needed the xcode dev kit installed, as well as libvips, which I installed with Homebrew.
xcode-select --installbrew updatebrew upgradebrew install vipsThen installed the conda environment in python3.8 with additional dependencies pyqt imagecodecs and pyqtgraph which are required for Studio. Then installed the tensorflow and pytorch requirements with conda as well. Finally, cloned slideflow's git repo, switched to the dev-2.1 branch. In the requirements file I commented out cplex, smac, and cucim as they aren't available for the Mac M1.conda create -y -n sf python=3.8 pyqt imagecodecs pyqtgraph numcodecs(installed these upon env creation else if trying during pip install slideflow PyQt5.5.15.9 package is downloaded and that wheel is not compiled for M1.)conda activate sfconda install pytorch::pytorch torchvision torchaudio -c pytorchconda install -c apple -y tensorflow-depspython3 -m pip install tensorflow-macos tensorflow-metalpython3 -m pip install cffi(otherwise error with pyvips)git clone https://github.com/jamesdolezal/slideflow.gitcd slideflowgit checkout dev-2.1python3 -m pip install -r requirements.txtFull environment list: sf_env_m1mac.txt
I started slideflow studio with
python3 slideflow-studio.pybut got a Segmentation Fault 11. Full crash report from apple attached in segfault_gflw.txt. The thread crashed at glfwGetMonitorWorkarea segfault_glfw.txtI used a Python3 interactive shell to verify that OpenGL, GLFW, and Slideflow could be successfully imported. I also used the Xquartz OpenGL test programs to verify that OpenGL/GLFW libraries on my Mac's system were installed and working properly. I also downloaded cellpose and napari and tried out their GUIs, and they worked without issue. I then began troubleshooting
slideflow-studio.pyto try and narrow down the issue.I found that the segfault was being caused by some issue with a single function in the slideflow code:
glfw.get_monitor_workarea()which is used to get the width/height of the monitor. It’s used in both theslideflow-studio.pyfile (for the splash screen) as well as instudio._glfw.pyto initialize the main window. I noticed that this was the only thing that it was used for, so I went ahead and commented out those lines and replaced them with the monitor’s width & height (1400, 900), which I got fromglfw.get_video_mode()used right below theglfw.get_monitor_workarea()part of the code inslideflow-studio.py. Then it worked, and the splash screen came up, but it still crashed when trying to initialize the main window. So I also did the same thing instudio._glfw.pyand then the main slideflow window popped up. I can click around, and even load in a slide. It’s fast, and it works. So it appears that, aside from this single function, OpenGL and GLFW are working properly, but there is some bug with eitherglfw.get_monitor_workarea()from the glfw python binding or possibly from the base GLFWglfwGetMonitorWorkarea.However… then i came to another issue: a Bus error which crashes the program. Sometimes it appears to happen randomly, but it is definitely triggered when i am trying to use the File>Open Slide or File >Open Project, but I noticed it also occurs when I am stretch the window’s size too far beyond the boundaries of my monitor. The Open stuff requires a new window to pop up, and stretching the monitor could also be an issue with querying monitor size. So once again, it feels like it comes down to this whole “get monitor workarea” bug. But in the most recent traceback, the crash doesn’t happen with that specific GLFW function. It happens with ImageIO, which is an Apple package. Or perhaps rather, a thread dispatch call. bus_error.txt
Expected behavior
Slideflow Studio to open
Environment:
pip, source): see above