From: Cameron M. <cm...@vi...> - 2009-07-05 19:47:15
|
Hi all, Apologies for the message to both mailing lists, but perhaps someone on either cctbxbb or pymol-users has had some recent experience with this... The subject line more-or-less says it all: I'm wondering if anyone has recently used Rob Campbell's draw_symops (or draw_symops_cctbx) Python modules with a relatively recent (within past year) version of the cctbx (particularly the Boost C++ parts) ? I succeeded in doing this a few years ago to generate images such as the ones near the top of http://muralab.org/~cmura/PyMOL/Sandbox/, but I can't get it to work on my present system (64-bit Fedora 10; Python 2.5.2 with Python 2.6 coexisting). Below is what happens when I... 1) Initiate a new PyMOL session (using a PyMOL v1.1 that I built in-place from source, so should be compatible with local python, system libs, etc) 2) load PDB files (tried with a few diff't files; verified that they contain proper CRYST specifications) 3) do the usual 'run draw_symops_cctbx.py' 4) call draw_symops() -- either implicitly, or by explicit specification of the u.c. params (i.e., using something like "draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)") ...which crashes the pymol session and yields the following trace: > PyMOL>draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1) > libc backtrace (48 frames, most recent call last): > /usr/bin/python [0x400649] > /lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576] > /usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1] > *<snip> > ... > ... > </snip>* > /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493] > /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so > [0x7ff19691db16] > > /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x9f) > [0x7ff19692a2ef] > /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so > [0x7ff196920b08] > > /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*, > _object*) const+0x125) [0x7ff196920635] > > /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so(boost::python::detail::caller_arity<2u>::impl<cctbx::sgtbx::rt_mx > (*)(cctbx::sgtbx::space_group const&, unsigned long), > boost::python::default_call_policies, > boost::mpl::vector3<cctbx::sgtbx::rt_mx, cctbx::sgtbx::space_group > const&, unsigned long> >::operator()(_object*, _object*)+0x12a) > [0x7ff18f820a3a] > /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so > [0x7ff18f8034cc] > > /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::throw_error_already_set()+0xe) > [0x7ff196929dde] > /usr/lib64/libstdc++.so.6(__cxa_allocate_exception+0x2f) [0x3444cc2cdf] > /lib64/libc.so.6 [0x3440832f90] > Segmentation fault (libc call stack above) > This crash may be due to a problem in any imported > Python module, including modules which are not part > of the cctbx project. To disable the traps leading > to this message, define these environment variables > (e.g. assign the value 1): > BOOST_ADAPTBX_FPE_DEFAULT > BOOST_ADAPTBX_SIGNALS_DEFAULT > This will NOT solve the problem, just mask it, but > may allow you to proceed in case it is not critical. > PyMOL: abrupt program termination. I tried the recommendation of setting the BOOST_ADAPTBX* env vars, but this doesn't remedy the problem. Also, I tried accomplishing this with many combinations of workflows: 1) old cctbx (e.g., 2005_04_29_1615), latest stable release of cctbx (2009_02_15_2320), bleeding-edge cctbx (2009_07_04_0143) 2) pre-built cctbx binaries versus building myself from src (for each of the above), insuring, again, optimal match between local system libs... 3) cctbx alone, cctbx in the context of Phenix, cctbx +/- its own bundled Python (2.5 and 2.6) Also, I tried this with different combinations of Rob's scripts -- e.g., the 'symop_axes.dat'-dependent "draw_symops.py", versus the 'all_axes_new.py'-dependent "draw_symops_cctbx.py". Interestingly, I found that get_all_axes() from 'all_axes_new.py' works fine for different PDB files. Investigating the above draw_symops stacktrace led me to this post from Ralf Grosse-Kunstleve to python-dev: http://mail.python.org/pipermail/python-dev/2008-September/082639.html It looks like exactly the same problem that's causing the pymol/draw_symops scripts to choke. Also, I can verify that issuing commands such as in Ralf's post (boost_adaptbx.segmentation_fault, boost_adaptbx.divide_by_zero) result in the same segfaults and errors as in his post, so... I believe this is the crux of it. Before delving into Boost codebase, cctbx's exception-handling in C++/Python Boost, etc., I'm wondering if anyone else has seen anything like this...? or has advice on how best to proceed? Any tips or suggestions would be most greatly appreciated. Thanks, Cam -- ------------------------------------------------------- Cameron Mura Assistant Professor University of Virginia Department of Chemistry McCormick Road, Box 400319 Charlottesville, VA 22904-4319 Email: cm...@vi... Web: http://muralab.org Tel: 434.924.7824 Fax: 434.924.3710 ------------------------------------------------------- |
From: Cameron M. <cm...@vi...> - 2009-07-06 04:14:28
|
Hi Ralf, Thanks for your note... > > I tried the recommendation of setting the BOOST_ADAPTBX* env vars, > but this doesn't remedy the problem. > > Did you get the same traceback? -- That would mean the env vars aren't > defined in the right context. With the env vars defined, there > shouldn't be any tracebacks anymore, just plain "Abort". Right -- This is what happened. I verified that the pymol context was aware of these env vars: > PyMOL>import os > PyMOL>print os.environ.get('BOOST_ADAPTBX_FPE_DEFAULT') > 1 > PyMOL>print os.environ.get('BOOST_ADAPTBX_SIGNALS_DEFAULT') > 1 So... with the vars set, no backtrace... just a simple crash: > <snip>....PyMOL session....</snip> > ...... > COMPND 6 ENGINEERED: YES; > COMPND 7 MUTATION: YES > ...... > Symmetry: Found 12 symmetry operators. > CmdLoad: "1avv.pdb" loaded as "1avv". > PyMOL>run draw_symops_cctbx.py > Finished importing for draw_symops_cctbx.py > PyMOL>draw_symops 1avv > /usr/bin/pymol: line 4: 4756 Segmentation fault cctbx.python > /usr/lib64/python2.5/site-packages/pymol/__init__.py $* > $] > You snipped out the most interesting part of the traceback. The first > part is always the Python startup right, the red part below(?) [up to frame 1/19] > and anything after boost::python::handle_exception is just the code > producing the tracebacks. right, blue part below(?) [beyond libc's frame 13/19] > The important clues are somewhere in the middle. Following is what happens in a simpler test run, outside of pymol, just divide_by_zero.py from the command line (result is essentially identical to your Sep-08 post to python-dev): > $] cctbx.python > /root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py > > Now dividing by zero (in C++) ... > show_stack(1): > /root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py(11) > run > show_stack(2): > /root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py(26) > <module> > libc backtrace (19 frames, most recent call last): > /usr/bin/python [0x400649] > /lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576] > /usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1] > /usr/lib64/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x1cd) > [0x34584ddfed] > /usr/lib64/libpython2.5.so.1.0(PyRun_FileExFlags+0x96) [0x34584dca06] > /usr/lib64/libpython2.5.so.1.0 [0x34584dc931] > /usr/lib64/libpython2.5.so.1.0(PyEval_EvalCode+0x32) [0x34584c0aa2] > /usr/lib64/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x715) [0x34584c0865] > /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x658d) [0x34584bfe6d] > /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x36f3) [0x34584bcfd3] > /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so > [0x7f20bb3ba3b2] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x85) > [0x7f20bb3c6625] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::function0<void>::operator()() > const+0x34) [0x7f20bb3c6f94] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so > [0x7f20bb3bd398] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*, > _object*) const+0x125) [0x7f20bb3bcec5] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/boost_python_meta_ext.so(boost::python::objects::caller_py_function_impl<boost::python::detail::caller<double > (*)(double const&, double const&), > boost::python::default_call_policies, boost::mpl::vector3<double, > double const&, double const&> > >::operator()(_object*, > _object*)+0xf3) [0x7f20bb5f5333] > > /root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/boost_python_meta_ext.so > [0x7f20bb5f0a54] > /lib64/libc.so.6 [0x3440832f90] > Floating-point error (Python and libc call stacks above) > This crash may be due to a problem in any imported > Python module, including modules which are not part > of the cctbx project. To disable the traps leading > to this message, define these environment variables > (e.g. assign the value 1): > BOOST_ADAPTBX_FPE_DEFAULT > BOOST_ADAPTBX_SIGNALS_DEFAULT > This will NOT solve the problem, just mask it, but > may allow you to proceed in case it is not critical. > $] I'm still at somewhat of a loss (mainly due to ignorance about boost/python interactions), but will let you know if I solve it. thanks, cam === Ralf W. Grosse-Kunstleve wrote (on 07/05/2009 11:38 PM): === > Hi Cameron, > > There are quite a few 3rd party extensions causing floating-point > exceptions (e.g. we have to turn off the floating-point traps when > using wxPython). > > > I tried the recommendation of setting the BOOST_ADAPTBX* env vars, > but this doesn't remedy the problem. > > Did you get the same traceback? -- That would mean the env vars aren't > defined in the right context. With the env vars defined, there > shouldn't be any tracebacks anymore, just plain "Abort". > > You snipped out the most interesting part of the traceback. The first > part is always the Python startup, and anything after > boost::python::handle_exception is just the code producing the > tracebacks. The important clues are somewhere in the middle. > > Ralf > > ------------------------------------------------------------------------ > *From:* Cameron Mura <cm...@vi...> > *To:* cc...@ph...; Pymol-users > <pym...@li...> > *Sent:* Sunday, July 5, 2009 12:33:53 PM > *Subject:* [cctbxbb] draw_symops <-- cctbx(/phenix) broken due to > boost segfault handling ? > > Hi all, > > Apologies for the message to both mailing lists, but perhaps someone > on either cctbxbb or pymol-users has had some recent experience with > this... > > The subject line more-or-less says it all: I'm wondering if anyone has > recently used Rob Campbell's draw_symops (or draw_symops_cctbx) Python > modules with a relatively recent (within past year) version of the > cctbx (particularly the Boost C++ parts) ? I succeeded in doing this > a few years ago to generate images such as the ones near the top of > http://muralab.org/~cmura/PyMOL/Sandbox/, but I can't get it to work > on my present system (64-bit Fedora 10; Python 2.5.2 with Python 2.6 > coexisting). > > Below is what happens when I... > > 1) Initiate a new PyMOL session (using a PyMOL v1.1 that I built > in-place from source, so should be compatible with local python, > system libs, etc) > > 2) load PDB files (tried with a few diff't files; verified that they > contain proper CRYST specifications) > > 3) do the usual 'run draw_symops_cctbx.py' > > 4) call draw_symops() -- either implicitly, or by explicit > specification of the u.c. params (i.e., using something like > "draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)") > > ....which crashes the pymol session and yields the following trace: >> PyMOL>draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1) >> libc backtrace (48 frames, most recent call last): >> /usr/bin/python [0x400649] >> /lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576] >> /usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1] >> *<snip> >> .... >> .... >> </snip>* >> /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493] >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so >> [0x7ff19691db16] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x9f) >> [0x7ff19692a2ef] >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so >> [0x7ff196920b08] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*, >> _object*) const+0x125) [0x7ff196920635] >> >> /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so(boost::python::detail::caller_arity<2u>::impl<cctbx::sgtbx::rt_mx >> (*)(cctbx::sgtbx::space_group const&, unsigned long), >> boost::python::default_call_policies, >> boost::mpl::vector3<cctbx::sgtbx::rt_mx, cctbx::sgtbx::space_group >> const&, unsigned long> >::operator()(_object*, _object*)+0x12a) >> [0x7ff18f820a3a] >> /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so >> [0x7ff18f8034cc] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::throw_error_already_set()+0xe) >> [0x7ff196929dde] >> /usr/lib64/libstdc++.so.6(__cxa_allocate_exception+0x2f) [0x3444cc2cdf] >> /lib64/libc.so.6 [0x3440832f90] >> Segmentation fault (libc call stack above) >> This crash may be due to a problem in any imported >> Python module, including modules which are not part >> of the cctbx project. To disable the traps leading >> to this message, define these environment variables >> (e.g. assign the value 1): >> BOOST_ADAPTBX_FPE_DEFAULT >> BOOST_ADAPTBX_SIGNALS_DEFAULT >> This will NOT solve the problem, just mask it, but >> may allow you to proceed in case it is not critical. >> PyMOL: abrupt program termination. > I tried the recommendation of setting the BOOST_ADAPTBX* env vars, but > this doesn't remedy the problem. > > Also, I tried accomplishing this with many combinations of workflows: > 1) old cctbx (e.g., 2005_04_29_1615), latest stable release of cctbx > (2009_02_15_2320), bleeding-edge cctbx (2009_07_04_0143) > 2) pre-built cctbx binaries versus building myself from src (for each > of the above), insuring, again, optimal match between local system libs... > 3) cctbx alone, cctbx in the context of Phenix, cctbx +/- its own > bundled Python (2.5 and 2.6) > > Also, I tried this with different combinations of Rob's scripts -- > e.g., the 'symop_axes.dat'-dependent "draw_symops.py", versus the > 'all_axes_new.py'-dependent "draw_symops_cctbx.py". Interestingly, I > found that get_all_axes() from 'all_axes_new.py' works fine for > different PDB files. > > Investigating the above draw_symops stacktrace led me to this post > from Ralf Grosse-Kunstleve to python-dev: > http://mail.python.org/pipermail/python-dev/2008-September/082639.html > It looks like exactly the same problem that's causing the > pymol/draw_symops scripts to choke. Also, I can verify that issuing > commands such as in Ralf's post (boost_adaptbx.segmentation_fault, > boost_adaptbx.divide_by_zero) result in the same segfaults and errors > as in his post, so... I believe this is the crux of it. Before > delving into Boost codebase, cctbx's exception-handling in C++/Python > Boost, etc., I'm wondering if anyone else has seen anything like > this...? or has advice on how best to proceed? Any tips or suggestions > would be most greatly appreciated. > > Thanks, > Cam |
From: Cameron M. <cm...@vi...> - 2009-07-21 02:43:58
|
Hi all, In case anyone else runs into it, just wanted to let you know that I've solved the (possibly Fedora 10-specific) segfault-induced crashing described in the email below. In a nutshell, it required editing the module in question (in this case, line 153 of "all_axes_new.py") so that it loops over the space group matrices of an sgtbx-returned object ('mysg') by calling all_ops() to explicitly render the object iterable; i.e., loop over mysg.all_ops() rather than plain mysg. In this case, change this: > for smx in space_group_info.group(): to this: > for smx in space_group_info.group().all_ops(): With best regards, Cam -- ------------------------------------------------------- Cameron Mura Assistant Professor University of Virginia Department of Chemistry McCormick Road, Box 400319 Charlottesville, VA 22904-4319 Email: cm...@vi... Web: http://muralab.org Tel: 434.924.7824 Fax: 434.924.3710 ------------------------------------------------------- === Cameron Mura wrote (on 07/05/2009 03:33 PM): === > Hi all, > > Apologies for the message to both mailing lists, but perhaps someone > on either cctbxbb or pymol-users has had some recent experience with > this... > > The subject line more-or-less says it all: I'm wondering if anyone has > recently used Rob Campbell's draw_symops (or draw_symops_cctbx) Python > modules with a relatively recent (within past year) version of the > cctbx (particularly the Boost C++ parts) ? I succeeded in doing this > a few years ago to generate images such as the ones near the top of > http://muralab.org/~cmura/PyMOL/Sandbox/, but I can't get it to work > on my present system (64-bit Fedora 10; Python 2.5.2 with Python 2.6 > coexisting). > > Below is what happens when I... > > 1) Initiate a new PyMOL session (using a PyMOL v1.1 that I built > in-place from source, so should be compatible with local python, > system libs, etc) > > 2) load PDB files (tried with a few diff't files; verified that they > contain proper CRYST specifications) > > 3) do the usual 'run draw_symops_cctbx.py' > > 4) call draw_symops() -- either implicitly, or by explicit > specification of the u.c. params (i.e., using something like > "draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)") > > ...which crashes the pymol session and yields the following trace: >> PyMOL>draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1) >> libc backtrace (48 frames, most recent call last): >> /usr/bin/python [0x400649] >> /lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576] >> /usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1] >> *<snip> >> ... >> ... >> </snip>* >> /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493] >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so >> [0x7ff19691db16] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x9f) >> [0x7ff19692a2ef] >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so >> [0x7ff196920b08] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*, >> _object*) const+0x125) [0x7ff196920635] >> >> /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so(boost::python::detail::caller_arity<2u>::impl<cctbx::sgtbx::rt_mx >> (*)(cctbx::sgtbx::space_group const&, unsigned long), >> boost::python::default_call_policies, >> boost::mpl::vector3<cctbx::sgtbx::rt_mx, cctbx::sgtbx::space_group >> const&, unsigned long> >::operator()(_object*, _object*)+0x12a) >> [0x7ff18f820a3a] >> /root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so >> [0x7ff18f8034cc] >> >> /root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::throw_error_already_set()+0xe) >> [0x7ff196929dde] >> /usr/lib64/libstdc++.so.6(__cxa_allocate_exception+0x2f) [0x3444cc2cdf] >> /lib64/libc.so.6 [0x3440832f90] >> Segmentation fault (libc call stack above) >> This crash may be due to a problem in any imported >> Python module, including modules which are not part >> of the cctbx project. To disable the traps leading >> to this message, define these environment variables >> (e.g. assign the value 1): >> BOOST_ADAPTBX_FPE_DEFAULT >> BOOST_ADAPTBX_SIGNALS_DEFAULT >> This will NOT solve the problem, just mask it, but >> may allow you to proceed in case it is not critical. >> PyMOL: abrupt program termination. > I tried the recommendation of setting the BOOST_ADAPTBX* env vars, but > this doesn't remedy the problem. > > Also, I tried accomplishing this with many combinations of workflows: > 1) old cctbx (e.g., 2005_04_29_1615), latest stable release of cctbx > (2009_02_15_2320), bleeding-edge cctbx (2009_07_04_0143) > 2) pre-built cctbx binaries versus building myself from src (for each > of the above), insuring, again, optimal match between local system libs... > 3) cctbx alone, cctbx in the context of Phenix, cctbx +/- its own > bundled Python (2.5 and 2.6) > > Also, I tried this with different combinations of Rob's scripts -- > e.g., the 'symop_axes.dat'-dependent "draw_symops.py", versus the > 'all_axes_new.py'-dependent "draw_symops_cctbx.py". Interestingly, I > found that get_all_axes() from 'all_axes_new.py' works fine for > different PDB files. > > Investigating the above draw_symops stacktrace led me to this post > from Ralf Grosse-Kunstleve to python-dev: > http://mail.python.org/pipermail/python-dev/2008-September/082639.html > It looks like exactly the same problem that's causing the > pymol/draw_symops scripts to choke. Also, I can verify that issuing > commands such as in Ralf's post (boost_adaptbx.segmentation_fault, > boost_adaptbx.divide_by_zero) result in the same segfaults and errors > as in his post, so... I believe this is the crux of it. Before > delving into Boost codebase, cctbx's exception-handling in C++/Python > Boost, etc., I'm wondering if anyone else has seen anything like > this...? or has advice on how best to proceed? Any tips or suggestions > would be most greatly appreciated. > > Thanks, > Cam > -- > ------------------------------------------------------- > Cameron Mura > Assistant Professor > University of Virginia > Department of Chemistry > McCormick Road, Box 400319 > Charlottesville, VA 22904-4319 > Email: cm...@vi... > Web: http://muralab.org > Tel: 434.924.7824 > Fax: 434.924.3710 > ------------------------------------------------------- > > ------------------------------------------------------------------------ > > _______________________________________________ > cctbxbb mailing list > cc...@ph... > http://www.phenix-online.org/mailman/listinfo/cctbxbb > |