Re: [cgkit-user] segfault help?

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

Hi Alejandro,

On 16.03.12 10:52, Alejandro Aguilera Martínez wrote:
> It seems I didn't test enough after downloading the last code and
> compiling it. Importing pygame doesn't solve the problem. So no matter
> what I import before, doing "from cgkit.all import *" throws a
> segmentation fault. I think the questions you've done here are still
> relevant to the issue so here are my answers.
> [...] 
> ldd /usr/local/lib/python2.6/dist-packages/cgkit/_core.so
> linux-gate.so.1 =>  (0x00f03000)
> libboost_python-py26.so.1.40.0
> => /usr/lib/libboost_python-py26.so.1.40.0 (0x0059b000)
> libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x00e21000)
> libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00791000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005e6000)
> [...]
> 
> ldd /usr/lib/libboost_python-py26.so.1.40.0
> linux-gate.so.1 =>  (0x00a3f000)
> libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x002bd000)
> libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x008dd000)
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00ff0000)
> librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00110000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x004c3000)
> [...]
> Is that the problem? Is a normal thing that every library has got a
> different version?

What do you mean they have a different version? From what I can see,
both libs pick up the same versions, don't they? For example, both pick
up libstdc++ from /usr/lib/libstdc++.so.6
So that looks ok to me.

> To try this just wrote a python script with one line that says "from cgkit.all import *".
> Exporting LD_DEBUG=libs and running the script gives a really big list of things, and also a lot of errors. Here are the two different errors:
> 
>      22788:	/usr/lib/mesa/libGL.so.1: error: symbol lookup error: undefined symbol: FunctionType (fatal)
>      22788:	/usr/lib/libGLU.so.1: error: symbol lookup error: undefined symbol: FunctionType (fatal)
> 
> Those two lines are printed lots of times. I can send you the log in a file if you want.

I see those as well. I have to admit, I don't know what symbol that is
and who needs it, but as I see the same here and I don't get the
segfault, it's probably not related to our problem.

I think the most interesting libraries we should look for at this point
are boost and std++, so when I set LD_DEBUG to "libs" and I run the
import I get this:

     30815:     find library=libboost_python.so.5 [0]; searching
     30815:      search cache=/etc/ld.so.cache
     30815:       trying file=/usr/lib64/libboost_python.so.5
     30815:
     [...]
     30815:     find library=libstdc++.so.6 [0]; searching
     30815:      search cache=/etc/ld.so.cache
     30815:       trying file=/usr/lib64/libstdc++.so.6

You could try the same, but I guess you will just see the same paths
that ldd already showed you (but the LD_DEBUG method will tell you what
really happens as this displays what actually gets loaded).
But as you said, you actually always get the segfault, no matter whether
pygames was imported first or not, I don't expect to see any real
difference then.

By the way, as it seems C++ exceptions don't make it into Python-land,
what happens if you run the following from a Python shell:

>>> from cgkit.cgtypes import *
>>> vec3(0).normalize()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: vec3.normalize(): divide by zero

This is basically the exception that causes the segfault on your
machine. So do you see the above ZeroDivisionError exception or does it
also segfault?

Another test would be to import the lookat module directly as this is
the one that causes the crash in your case:

>>> import cgkit.lookat

Does that also segfault?

- Matthias -