Re: [cgkit-user] segfault help?

[Matthias B. <mat...@gm...>]

Hi Alejandro,

On 20.02.12 10:06, Alejandro Aguilera Martínez wrote:
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from cgkit.all import *
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00b96c17 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
> (gdb) bt
> #0  0x00b96c17 in __cxa_allocate_exception () from /usr/lib/libstdc
> ++.so.6
> #1  0x007aaa07 in
> support3d::mat4<double>::setLookAt(support3d::vec3<double> const&,
> support3d::vec3<double> const&, support3d::vec3<double> const&) ()
>    from /usr/local/lib/python2.6/dist-packages/cgkit/_core.so
> #2  0x0079dc8f in lookAt (pos=..., target=..., up=...) at
> wrappers/py_mat4.cpp:102
> [...]
> 
> It seems the seg fault has "moved". I tried the same prinf approach in
> LookAt method in py_math4.cpp:99, but there are no prints.
> 
> Am I in the wrong method? What can I do now?

You were adding prints to the function mentioned in item #2 in the stack
trace. But item #1 also is part of cgkit, that's in
supportlib/include/mat4.h, line 1085. As the problem seems to be
allocating an exception (item #0), I take it the setLookAt() method
throws a EZeroDivisionError exception (which can happen if pos and
target are the same point). Normally, this shouldn't result in a crash,
but just, well, throw the exception.

To me this looks like there is a clash between versions of the C++
runtime or Boost.Python. Do you have several versions of Boost.Python on
your system? Did you compile Boost yourself?
You could use ldd to check what dependencies the Boost.Python lib and
the cgkit _core lib has (check that the C++ runtime matches).
So on your system that would be:

ldd /usr/lib/libboost_python-py26.so.1.40.0

and

ldd /usr/local/lib/python2.6/dist-packages/cgkit/_core.so

Is there anything suspicious? (different versions of the same library?)

You could also use the LD_DEBUG environment variable to check which
libraries actually get loaded. This can be used to instruct the runtime
linker to print debug information.
If you set it to "help" and just run any program (such as "ls"), it will
print a list of values you can set that variable to. You could probably
try one of "libs" or "files" to see which libraries are actually picked
up while running the Python program.
If you then do the same with the version that imports pygame, we could
compare the output and see if it picks up a different version of the C++
runtime (or any other library).

Cheers,

- Matthias -