1

I have a docker image in which cppyy import has started crashing. I tried comparing outputs of pip freeze and apt list --installed between working and non working docker images, but see no differences.

Still on non working docker, importing cppyy causes as SIGSEGV. python -c "import cppyy" results in below stacktrace:

0x00007ff5fea9f6fd in Cppyy::IsEnum(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-fnbk157s/cppyy-backend_25a6e780aa5148f0b795ce9be8955f8f/src/clingwrapper.cxx:992 (discriminator 1) from /root/.local/lib/python3.8/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007ff5feaa73e0 in Cppyy::ResolveName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-fnbk157s/cppyy-backend_25a6e780aa5148f0b795ce9be8955f8f/src/clingwrapper.cxx:392 from /root/.local/lib/python3.8/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007ff5feaa7c15 in Cppyy::GetScope(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /usr/include/c++/9/bits/basic_string.h:6151 from /root/.local/lib/python3.8/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007ff5fcb44e22 in CPyCppyy::CreateScopeProxy(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, _object*, unsigned int) at /tmp/pip-install-fnbk157s/cpycppyy_e0cc3a6d83714b2aa9d7ba41e49f3748/src/ProxyWrappers.cxx:550 (discriminator 10) from /root/.local/lib/python3.8/site-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x00007ff5fcb0ae6c in <unknown> from /root/.local/lib/python3.8/site-packages/libcppyy.cpython-38-x86_64-linux-gnu.so

Any pointers to debug this?

ShadowRanger
  • 143,180
  • 12
  • 188
  • 271
Rajat Verma
  • 27
  • 4
  • doing nm on libcppyy_backend.so from non-working docker image, I see `0000000000029b60 d C.490.190159`. On a working image, this is `0000000000029b60 d C.490.190153` – Rajat Verma Mar 08 '22 at 17:20

1 Answers1

1

You can have a look at the issue I opened on GitHub https://github.com/wlav/cppyy/issues/42

This is a workaround

$ python -m pip install cppyy-cling==6.25.2 
$ python -m pip install cppyy-backend==1.14.7 --no-cache-dir --no-use-pep517
$ python -m pip install cppyy==2.2.0

And version 2.3.0 is out to fix this issue

Sebastiano Milardo
  • 26
  • 5
  • Yes, this appears to be the problem. The `cppyy-backend` code specifies `cppyy-cling>=6.25.2` and even though `cppyy==2.2.0` has explicitly `cppyy-cling==6.25.2`, the PEP517 build will use 6.25.3 in its build environment. The upshot being that the build and install backends differ. The solution is actually to install `cppyy-cling==6.25.3` after installing `cppyy` and ignoring the warning from pip. That way build and run-time are the same again. – Wim Lavrijsen Mar 08 '22 at 19:02
  • 1
    Fixed in repo by releasing 2.3.0. If you do not want 2.3.0, see the above mentioned github issue report on how to install a functional 2.2.0. – Wim Lavrijsen Mar 08 '22 at 20:04
  • I was using 1.9.3 and encountering this issue. moving to 2.3.0 solves this. Thanks @WimLavrijsen – Rajat Verma Mar 09 '22 at 06:42
  • 1.x and 2.x are very different (in a good way) b/c the latter has an upgraded Cling. Just for completeness, installing 1.9.3 would work the same way as above, with `--no-use-pep517` for `cppyy-backend` just with versions `cppyy-cling==6.21.5` and `cppyy-backend==1.14.2`. I haven't found a better way of working around PEP517 yet. – Wim Lavrijsen Mar 09 '22 at 15:51
  • Alright, 6.25.4 restores build-time backwards compatibility, so all old releases should be working again once the various wheels have been uploaded. Thanks for reporting and your patience. – Wim Lavrijsen Mar 09 '22 at 19:52