<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:courier,monaco,monospace,sans-serif;font-size:10pt"><div><span style="color: rgb(0, 0, 0); font-family: Courier New,courier,monaco,monospace,sans-serif;">Could you post the full traceback of the original crash?</span><br style="color: rgb(0, 0, 0); font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="color: rgb(0, 0, 0); font-family: Courier New,courier,monaco,monospace,sans-serif;">Set only BOOST_ADAPTBX_FPE_DEFAULT but not </span><font style="font-family: Courier New,courier,monaco,monospace,sans-serif;" color="#3333ff"><span style="color: rgb(0, 0, 0);">BOOST_ADAPTBX_SIGNALS_DEFAULT.</span><br style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 0);">That should tell you where the segfault originates.<br>Another approach is to compile everything with -g and use valgrind. That will<br>even give you line numbers.
However, it may be tricky to make this work. Hopefully<br>the traceback will give enough of a clue.<br>Ralf<br style="color: rgb(0, 0, 0);"></span></font><tt><font color="#3333ff"><br></font></tt></div><div style="font-family: courier,monaco,monospace,sans-serif; font-size: 10pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Cameron Mura <cmura@virginia.edu><br><b><span style="font-weight: bold;">To:</span></b> Ralf W. Grosse-Kunstleve <rwgk@yahoo.com>; cctbxbb@phenix-online.org; Pymol-users <pymol-users@lists.sourceforge.net><br><b><span style="font-weight: bold;">Sent:</span></b> Sunday, July 5, 2009 9:14:23 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [cctbxbb] draw_symops <-- cctbx(/phenix) broken due to boost segfault handling ?<br></font><br><title></title>
Hi Ralf,<br>
<br>
Thanks for your note...<br>
<br>
<blockquote type="cite"><font color="#006600"><small>> I tried the
recommendation of setting the BOOST_ADAPTBX* env vars, but
this doesn't remedy the problem.<br>
<br>
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".</small></font></blockquote>
Right -- This is what happened. I verified that the pymol context was
aware of these env vars:<br>
<blockquote type="cite"><tt><font color="#3333ff">PyMOL>import os<br>
PyMOL>print os.environ.get('BOOST_ADAPTBX_FPE_DEFAULT')<br>
1<br>
PyMOL>print os.environ.get('BOOST_ADAPTBX_SIGNALS_DEFAULT')<br>
1</font><br>
</tt></blockquote>
So... with the vars set, no backtrace... just a simple crash:<br>
<blockquote type="cite"><font color="#3333ff"><tt><snip></tt><tt>....</tt><tt>PyMOL
session....</snip><br>
.......<br>
COMPND 6 ENGINEERED: YES;<br>
COMPND 7 MUTATION: YES<br>
.......<br>
Symmetry: Found 12 symmetry operators.<br>
CmdLoad: "1avv.pdb" loaded as "1avv".<br>
PyMOL>run draw_symops_cctbx.py<br>
Finished importing for draw_symops_cctbx.py<br>
PyMOL>draw_symops 1avv<br>
/usr/bin/pymol: line 4: 4756 Segmentation fault cctbx.python
/usr/lib64/python2.5/site-packages/pymol/__init__.py $*<br>
$]</tt></font><br>
</blockquote>
<br>
<blockquote type="cite"><small><font color="#006600">You snipped out
the most interesting part of the
traceback. The first part is always the Python startup</font></small></blockquote>
right, the red part below(?) [up to frame 1/19]<br>
<br>
<blockquote type="cite"><small><font color="#006600">and anything
after boost::python::handle_exception is just the code producing the
tracebacks.</font></small></blockquote>
right, blue part below(?) [beyond libc's frame 13/19]<br>
<br>
<blockquote type="cite"><font color="#006600"><small> The important
clues are somewhere in the middle.</small><br>
</font></blockquote>
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):<br>
<br>
<blockquote type="cite"><tt><font color="#cc0000">$] cctbx.python
/root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py
<br>
Now dividing by zero (in C++) ...<br>
show_stack(1):
/root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py(11)
run<br>
show_stack(2):
/root/software/cctbx/2009_02_15_2320/working/cctbx_sources/boost_adaptbx/command_line/divide_by_zero.py(26)
<module><br>
libc backtrace (19 frames, most recent call last):<br>
/usr/bin/python [0x400649]</font><br>
/lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576]<br>
/usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1]<br>
/usr/lib64/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x1cd)
[0x34584ddfed]<br>
/usr/lib64/libpython2.5.so.1.0(PyRun_FileExFlags+0x96) [0x34584dca06]<br>
/usr/lib64/libpython2.5.so.1.0 [0x34584dc931]<br>
/usr/lib64/libpython2.5.so.1.0(PyEval_EvalCode+0x32) [0x34584c0aa2]<br>
/usr/lib64/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x715) [0x34584c0865]<br>
/usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x658d)
[0x34584bfe6d]<br>
/usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x36f3)
[0x34584bcfd3]<br>
/usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493]<br>
/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so
[0x7f20bb3ba3b2]<br>
<font color="#3333ff">/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x85)
[0x7f20bb3c6625]<br>
/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::function0<void>::operator()()
const+0x34) [0x7f20bb3c6f94]<br>
/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so
[0x7f20bb3bd398]<br>
/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*,
_object*) const+0x125) [0x7f20bb3bcec5]<br>
/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]<br>
/root/software/cctbx/2009_02_15_2320/working/cctbx_build/lib/boost_python_meta_ext.so
[0x7f20bb5f0a54]<br>
/lib64/libc.so.6 [0x3440832f90]</font><br>
Floating-point error (Python and libc call stacks above)<br>
This crash may be due to a problem in any imported<br>
Python module, including modules which are not part<br>
of the cctbx project. To disable the traps leading<br>
to this message, define these environment variables<br>
(e.g. assign the value 1):<br>
BOOST_ADAPTBX_FPE_DEFAULT<br>
BOOST_ADAPTBX_SIGNALS_DEFAULT<br>
This will NOT solve the problem, just mask it, but<br>
may allow you to proceed in case it is not critical.<br>
$] <br>
</tt></blockquote>
<br>
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.<br>
<br>
thanks,<br>
cam<br>
<br>
<br>
<br>
<font color="#006600">=== Ralf W. Grosse-Kunstleve wrote (on 07/05/2009
11:38 PM): ===</font>
<blockquote type="cite">
<div style="font-family: courier,monaco,monospace,sans-serif; font-size: 10pt;">
<div><font color="#006600">Hi Cameron,<br>
<br>
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).<br>
<br>
> I tried the recommendation of setting the BOOST_ADAPTBX* env vars,
but
this doesn't remedy the problem.<br>
<br>
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".<br>
<br>
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.<br>
<br>
Ralf<br>
</font></div>
<div style="font-family: courier,monaco,monospace,sans-serif; font-size: 10pt;"><font color="#006600"><br>
</font>
<div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font color="#006600" face="Tahoma" size="2">
<hr size="1"><b><span style="font-weight: bold;">From:</span></b>
Cameron Mura <a rel="nofollow" class="moz-txt-link-rfc2396E" ymailto="mailto:cmura@virginia.edu" target="_blank" href="mailto:cmura@virginia.edu"><cmura@virginia.edu></a><br>
<b><span style="font-weight: bold;">To:</span></b>
<a rel="nofollow" class="moz-txt-link-abbreviated" ymailto="mailto:cctbxbb@phenix-online.org" target="_blank" href="mailto:cctbxbb@phenix-online.org">cctbxbb@phenix-online.org</a>; Pymol-users
<a rel="nofollow" class="moz-txt-link-rfc2396E" ymailto="mailto:pymol-users@lists.sourceforge.net" target="_blank" href="mailto:pymol-users@lists.sourceforge.net"><pymol-users@lists.sourceforge.net></a><br>
<b><span style="font-weight: bold;">Sent:</span></b> Sunday, July 5,
2009 12:33:53 PM<br>
<b><span style="font-weight: bold;">Subject:</span></b> [cctbxbb]
draw_symops <-- cctbx(/phenix) broken due to boost segfault handling
?<br>
</font><font color="#006600"><br>
Hi all,<br>
<br>
Apologies for the message to both mailing lists, but perhaps someone on
either cctbxbb or pymol-users has had some recent experience with
this...<br>
<br>
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 <a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://muralab.org/%7Ecmura/PyMOL/Sandbox/">http://muralab.org/~cmura/PyMOL/Sandbox/</a>,
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).<br>
<br>
Below is what happens when I...<br>
<br>
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)<br>
<br>
2) load PDB files (tried with a few diff't files; verified that they
contain proper CRYST specifications)<br>
<br>
3) do the usual 'run draw_symops_cctbx.py'<br>
<br>
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)")<br>
<br>
.....which crashes the pymol session and yields the following trace:<br>
</font>
<blockquote type="cite"><font color="#006600"><tt>PyMOL>draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)<br>
libc backtrace (48 frames, most recent call last):<br>
/usr/bin/python [0x400649]<br>
/lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576]<br>
/usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1]<br>
<b><snip><br>
.....<br>
.....<br>
</snip></b><br>
/usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so
[0x7ff19691db16]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x9f)
[0x7ff19692a2ef]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so
[0x7ff196920b08]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*,
_object*) const+0x125) [0x7ff196920635]<br>
/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]<br>
/root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so
[0x7ff18f8034cc]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::throw_error_already_set()+0xe)
[0x7ff196929dde]<br>
/usr/lib64/libstdc++.so.6(__cxa_allocate_exception+0x2f)
[0x3444cc2cdf]<br>
/lib64/libc.so.6 [0x3440832f90]<br>
Segmentation fault (libc call stack above)<br>
This crash may be due to a problem in any imported<br>
Python module, including modules which are not part<br>
of the cctbx project. To disable the traps leading<br>
to this message, define these environment variables<br>
(e.g. assign the value 1):<br>
BOOST_ADAPTBX_FPE_DEFAULT<br>
BOOST_ADAPTBX_SIGNALS_DEFAULT<br>
This will NOT solve the problem, just mask it, but<br>
may allow you to proceed in case it is not critical.<br>
PyMOL: abrupt program termination.<br>
</tt></font></blockquote>
<font color="#006600">I tried the recommendation of setting the
BOOST_ADAPTBX* env vars, but
this doesn't remedy the problem.<br>
<br>
Also, I tried accomplishing this with many combinations of workflows:<br>
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)<br>
2) pre-built cctbx binaries versus building myself from src (for each
of the above), insuring, again, optimal match between local system
libs...<br>
3) cctbx alone, cctbx in the context of Phenix, cctbx +/- its own
bundled Python (2.5 and 2.6)<br>
<br>
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.<br>
<br>
Investigating the above draw_symops stacktrace led me to this
post from Ralf Grosse-Kunstleve to python-dev:
<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://mail.python.org/pipermail/python-dev/2008-September/082639.html">http://mail.python.org/pipermail/python-dev/2008-September/082639.html</a><br>
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.<br>
<br>
Thanks,<br>
Cam</font></div>
</div>
</div>
</blockquote>
</div></div></div></body></html>