[cctbxbb] draw_symops <-- cctbx(/phenix) broken due to boost segfault handling ?
Ralf W. Grosse-Kunstleve
rwgk at yahoo.com
Mon Jul 6 08:08:11 PDT 2009
Could you post the full traceback of the original crash?
Set only BOOST_ADAPTBX_FPE_DEFAULT but not BOOST_ADAPTBX_SIGNALS_DEFAULT.
That should tell you where the segfault originates.
Another approach is to compile everything with -g and use valgrind. That will
even give you line numbers. However, it may be tricky to make this work. Hopefully
the traceback will give enough of a clue.
Ralf
________________________________
From: Cameron Mura <cmura at virginia.edu>
To: Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>; cctbxbb at phenix-online.org; Pymol-users <pymol-users at lists.sourceforge.net>
Sent: Sunday, July 5, 2009 9:14:23 PM
Subject: Re: [cctbxbb] draw_symops <-- cctbx(/phenix) broken due to boost segfault handling ?
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/90b2871e/attachment-0001.htm
More information about the cctbxbb
mailing list