[cctbxbb] draw_symops <-- cctbx(/phenix) broken due to boost segfault handling ?

Sun Jul 5 20:38:00 PDT 2009

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

-- 
-------------------------------------------------------
 Cameron Mura
 Assistant Professor
 University of Virginia
 Department of Chemistry
 McCormick Road, Box 400319
 Charlottesville, VA 22904-4319
 Email: cmura at virginia.edu
 Web: http://muralab.org
 Tel: 434.924.7824
 Fax: 434.924.3710
-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.phenix-online.org/pipermail/cctbxbb/attachments/20090705/a411c891/attachment-0001.htm