mamba: Mamba 0.7.14 segfaults on macOS
Here is a full output:
$ mamba create -n xonsh xonsh
conda-forge/osx-64 Using cache
conda-forge/noarch Using cache
pkgs/main/noarch [====================] (00m:00s) No change
pkgs/r/noarch [====================] (00m:00s) No change
pkgs/r/osx-64 [====================] (00m:00s) No change
pkgs/main/osx-64 [====================] (00m:00s) No change
Transaction
Prefix: /Users/ondrej/miniconda3/envs/xonsh
Updating specs:
- xonsh
Package Version Build Channel Size
────────────────────────────────────────────────────────────────────────────────────────────────
Install:
────────────────────────────────────────────────────────────────────────────────────────────────
backports 1.0 py_2 conda-forge/noarch Cached
backports.functools_lru_cache 1.6.1 py_0 conda-forge/noarch Cached
ca-certificates 2021.1.19 hecd8cb5_0 pkgs/main/osx-64 Cached
certifi 2020.12.5 py39h6e9494a_1 conda-forge/osx-64 Cached
conda-suggest 0.1.1 pyh9f0ad1d_0 conda-forge/noarch 11 KB
conda-suggest-conda-forge 2020.11.25 h694c41f_0 conda-forge/osx-64 91 KB
libcxx 11.0.1 habf9029_0 conda-forge/osx-64 Cached
libffi 3.3 h046ec9c_2 conda-forge/osx-64 Cached
ncurses 6.2 h2e338ed_4 conda-forge/osx-64 Cached
openssl 1.1.1j hbcf498f_0 conda-forge/osx-64 Cached
pip 21.0.1 pyhd8ed1ab_0 conda-forge/noarch Cached
prompt-toolkit 3.0.16 pyha770c72_0 conda-forge/noarch 244 KB
prompt_toolkit 3.0.16 hd8ed1ab_0 conda-forge/noarch 4 KB
pygments 2.8.0 pyhd8ed1ab_0 conda-forge/noarch 736 KB
python 3.9.2 h2502468_0_cpython conda-forge/osx-64 13 MB
python_abi 3.9 1_cp39 conda-forge/osx-64 4 KB
readline 8.1 h9ed2024_0 pkgs/main/osx-64 Cached
setproctitle 1.2.2 py39hcbf5805_0 conda-forge/osx-64 15 KB
setuptools 52.0.0 py39hecd8cb5_0 pkgs/main/osx-64 Cached
sqlite 3.34.0 h17101e1_0 conda-forge/osx-64 2 MB
tk 8.6.10 hb0a8c7a_1 conda-forge/osx-64 Cached
tqdm 4.58.0 pyhd8ed1ab_0 conda-forge/noarch Cached
tzdata 2021a he74cb21_0 conda-forge/noarch 121 KB
wcwidth 0.2.5 pyh9f0ad1d_2 conda-forge/noarch Cached
wheel 0.36.2 pyhd3deb0d_0 conda-forge/noarch Cached
xonsh 0.9.27 py39h6e9494a_0 conda-forge/osx-64 1 MB
xz 5.2.5 haf1e3a3_1 conda-forge/osx-64 Cached
zlib 1.2.11 h7795811_1010 conda-forge/osx-64 Cached
Summary:
Install: 28 packages
Total download: 17 MB
────────────────────────────────────────────────────────────────────────────────────────────────
Confirm changes: [Y/n]
Finished prompt_toolkit (00m:00s) 4 KB 2 KB/s-toolkit [=> ] (00m:00s) 44 KB / 244 KB ( 19.18 KB/s)
Finished conda-suggest-conda-forge (00m:02s) 91 KB 22 KB/s-toolkit [===> ] (00m:02s) 143 KB / 244 KB ( 35.11 KB/s)
Finished python_abi (00m:00s) 4 KB 885 B/sts [=> ] (00m:02s) 147 KB / 736 KB ( 33.27 KB/s)
Finished prompt-toolkit (00m:04s) 244 KB 42 KB/sts [=> ] (00m:04s) 211 KB / 736 KB ( 36.82 KB/s)
Finished conda-suggest (00m:10s) 11 KB 780 B/s [==> ] (00m:11s) 557 KB / 1 MB ( 38.10 KB/s)
Finished tzdata (00m:01s) 121 KB 7 KB/s [==> ] (00m:13s) 669 KB / 1 MB ( 39.48 KB/s)
Finished pygments (00m:15s) 736 KB 44 KB/s [==> ] (00m:14s) 669 KB / 1 MB ( 38.75 KB/s)
Finished setproctitle (00m:00s) 15 KB 872 B/s [> ] (00m:11s) 287 KB / 2 MB ( 16.59 KB/s)
Finished xonsh (00m:25s) 1 MB 51 KB/s [===> ] (00m:23s) 1 MB / 2 MB ( 40.24 KB/s)
Finished sqlite (00m:30s) 2 MB 49 KB/s [> ] (00m:29s) 2 MB / 13 MB ( 46.47 KB/s)
Finished python (01m:58s) 13 MB 106 KB/s
Segmentation fault: 11
Now, I was running mamba in another terminal also (that one finished without a segfault). Perhaps it is related. When I reran the above command it succeeded.
Either way, it should not segfault like this, but give a useful error message.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (10 by maintainers)
Hey @certik in the long run yes but it’s not yet ready! For the name, there is another issue opened https://github.com/mamba-org/mamba/issues/1068
You could try shell alias or bash completer if you use bash! We should definitely think about creating a symlink or hardlink to have
umambaWe have lockfiles’ in place for both
mambaandmicromambanow.I’ve started implementing a lock file approach here: #752
Have to do the same for Windows. I think we’ll globally lock the package cache for now, otherwise the waiting will be quite complicated (until we refactor how we get packages and put this into a more task-based approach, using TaskFlow or similar).
https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/detail/file_locking_helpers.hpp
PS: boost to the rescue, maybe we can borrow some ideas here: https://www.boost.org/doc/libs/1_44_0/doc/html/boost/interprocess/file_lock.html
Thanks for opening this issue. I think it’s very much related to running multiple mamba’s in parallel (if I got that correctly?). They share the same package cache and therefore might try to write to the same files.
In #696 we are considering to add more robustness improvements. For this case, we could either have a global lock on the package cache, or a lock per package.
Any chance you have experience with lock(file) solutions in C++?