[cctbxbb] draw_symops <-- cctbx(/phenix) broken due to boost segfault handling ?
Cameron Mura
cmura at virginia.edu
Sun Jul 5 21:14:23 PDT 2009
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 <cmura at virginia.edu>
> *To:* cctbxbb at phenix-online.org; Pymol-users
> <pymol-users at lists.sourceforge.net>
> *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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.phenix-online.org/pipermail/cctbxbb/attachments/20090706/14bb15dc/attachment.htm
More information about the cctbxbb
mailing list