opencv-python: segfault in docker when used with torch and matplotlib
Steps to reproduce
╰─$cat Dockerfile
FROM centos/python-36-centos7
USER root
WORKDIR /root
RUN yum update -y
RUN pip install --upgrade pip
RUN pip install opencv-python
RUN pip install -U matplotlib
RUN pip install torch==1.6.0+cpu -f https://download.pytorch.org/whl/torch_stable.html
COPY a.py /root/a.py
RUN python -X faulthandler a.py
╰─$cat a.py
import torch
try:
import cv2
except:
pass
import matplotlib.pyplot as plt
╰─$docker build -t test:v0 .
..................
Step 10/10 : RUN python -X faulthandler a.py
---> Running in 1b7bc36c9727
Fatal Python error: Segmentation fault
Thread 0x00007f185a430740 (most recent call first):
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/json/encoder.py", line 356 in _iterencode_dict
The command '/bin/sh -c python -X faulthandler a.py' returned a non-zero code: 139
It works if I use opencv-python-headless
instead.
Issue submission checklist
-
This is not a generic OpenCV usage question (looking for help for coding, other usage questions, homework etc.)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (11 by maintainers)
Commits related to this issue
- disable nodelete, see #381 — committed to opencv/opencv-python by skvark 4 years ago
- update openssl, no-pinshared, see #381 — committed to opencv/opencv-python by skvark 4 years ago
The fix is included now in the latest releases.
This repository and the packages are probably the first results when you google for opencv-python. The README clearly explains different available packages. Therefore, I would expect that pytorch maintainers (or any package maintainers / users who use these packages) would spend a few minutes of their time to read through the provided documentation.
There’s certainly some kind of conflict somewhere in those binaries (some overlapping symbols maybe…?) and it’s likely that the headless version works because it does not use the same symbols as
opencv-python
. So yeah, you are correct, not related directly to GUI but to the dependencies required by Qt and X11 (or something else, but since headless version works, I would expect this to be the case). GUI conflicts have been common earlier and it was just my initial guess based on the issue description.I’ll try to have a look into this when I have more time.