[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Segfaults in python on 32-bit (i386/armel/armhf) #8051

Open
mbanck opened this issue Nov 28, 2024 · 2 comments
Open

Segfaults in python on 32-bit (i386/armel/armhf) #8051

mbanck opened this issue Nov 28, 2024 · 2 comments
Labels
bug

Comments

@mbanck
Copy link
Contributor
mbanck commented Nov 28, 2024 •
edited
Loading

Describe the bug

Running from rdkit import Chem leads to a segfault on 32-bit architectures (Debian architectures i386 armel and armhf), see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1083076 or the build logs that show all python-based tests failing, e.g. this one: https://buildd.debian.org/status/fetch.php?pkg=rdkit&arch=i386&ver=202409.2-2&stamp=1732738941&raw=0

To Reproduce
Install RDKit on 32-bit i386, go into python, execute from rdkit import Chem

Expected behavior
Importing rdkit/Chem works fine

Screenshots

(sid_armel-dchroot)mbanck@amdahl:~$ python3
Python 3.12.7 (main, Nov  8 2024, 17:55:36) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from rdkit import Chem
Segmentation fault
(sid_armel-dchroot)mbanck@amdahl:~$

Configuration (please complete the following information):

  • RDKit version: 202409.2
  • OS: Debian unstable
  • Python version (if relevant): 3.12.7
  • Are you using conda? no
  • If you are using conda, which channel did you install the rdkit from? n/a
  • If you are not using conda: how did you install the RDKit? Debian package

Additional context

Backtrace (first ten frames):

(gdb) bt
#0  0xf79c833c in boost::python::objects::enum_base::add_value(char const*, long) () from /lib/arm-linux-gnueabi/libboost_python312.so.1.83.0
#1  0xf5311144 in boost::python::enum_<RDKit::SmilesWrite::CXSmilesFields>::value (this=0xfffed910, name=0xf53a1fc4 "CX_ALL", x=RDKit::SmilesWrite::CX_ALL) at /usr/include/boost/python/enum.hpp:93
#2  init_module_rdmolfiles () at ./Code/GraphMol/Wrap/rdmolfiles.cpp:1725
#3  0xf79d5dd4 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const () from /lib/arm-linux-gnueabi/libboost_python312.so.1.83.0
#4  0xf5f4b288 in boost::python::detail::translate_exception<RDKit::CIPLabeler::MaxIterationsExceeded, void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)>::operator() (this=<optimized out>, handler=..., 
    f=..., translate=0xf5f49d4c <rdMaxIterationsExceededTranslator(RDKit::CIPLabeler::MaxIterationsExceeded const&)>) at /usr/include/boost/python/detail/translate_exception.hpp:39
#5  boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)> >::operator()<bool, boost::python::detail::translate_exception<RDKit::CIPLabeler::MaxIterationsExceeded, void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)>, boost::_bi::rrlist2<boost::python::detail::exception_handler const&, boost::function0<void> const&> > (this=<optimized out>, 
    f=..., a=<synthetic pointer>...) at /usr/include/boost/bind/bind.hpp:368
#6  boost::_bi::bind_t<bool, boost::python::detail::translate_exception<RDKit::CIPLabeler::MaxIterationsExceeded, void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)> > >::operator()<boost::python::detail::exception_handler const&, boost::function0<void> const&> (this=<optimized out>, 
    a1=..., a2=...) at /usr/include/boost/bind/bind.hpp:1298
#7  boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<RDKit::CIPLabeler::MaxIterationsExceeded, void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(RDKit::CIPLabeler::MaxIterationsExceeded const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke (function_obj_ptr=..., a0=..., a1=...) at /usr/include/boost/function/function_template.hpp:137
#8  0xf5c74fc4 in boost::python::detail::translate_exception<RDKit::ConformerException, void (*)(RDKit::ConformerException const&)>::operator() (this=<optimized out>, handler=..., f=..., 
    translate=0xf5bf48d4 <rdExceptionTranslator(RDKit::ConformerException const&)>) at /usr/include/boost/python/detail/translate_exception.hpp:39
#9  boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(RDKit::ConformerException const&)> >::operator()<bool, boost::python::detail::translate_exception<RDKit::ConformerException, void (*)(RDKit::ConformerException const&)>, boost::_bi::rrlist2<boost::python::detail::exception_handler const&, boost::function0<void> const&> > (this=<optimized out>, f=..., a=<synthetic pointer>...)
    at /usr/include/boost/bind/bind.hpp:368
#10 boost::_bi::bind_t<bool, boost::python::detail::translate_exception<RDKit::ConformerException, void (*)(RDKit::ConformerException const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(RDKit::ConformerException const&)> > >::operator()<boost::python::detail::exception_handler const&, boost::function0<void> const&> (this=<optimized out>, a1=..., a2=...)
    at /usr/include/boost/bind/bind.hpp:1298
@mbanck mbanck added the bug label Nov 28, 2024
@mbanck mbanck changed the title Segfaults in python on 32-bit ARM (armel/armhf) Segfaults in python on 32-bit (i386/armel/armhf) Nov 28, 2024
@greglandrum
Copy link
Member

@mbanck thanks for reporting this.
I'm not quite sure how I can reproduce it since I don't have access to a 32bit machine.

I'm trying to figure out how important this is... do you have any sense for how many people are using debichem on 32bit architectures?

@mbanck
Copy link
Contributor Author
mbanck commented Nov 29, 2024

One does not need to have a 32bit machine, a 32bit chroot (or maybe even docker container?) would suffice.

I agree that there are probably not a lot of people running it on 32bit today, but crashes like this indicate some unsafe code somewhere so it would be good to fix it in my opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@greglandrum @mbanck