Re: [cgkit-user] cgkit on Ubuntu 8.10
Brought to you by:
mbaas
Menu
▾
▴
Re: [cgkit-user] cgkit on Ubuntu 8.10
|
From: Matthias B. <mat...@gm...> - 2009-03-08 16:54:49
|
Hi Karel,
Karel Skoupy wrote:
> The stack trace and the python -v listing is attached.
Thanks for that! (I totally forgot about the python -v option)
I think these two brought us a step further.
Unsurprisingly, the joystick module is not the problem, it just happened
to be the last module imported before the crash. The -v listing has also
revealed that this import was not done from __init__.py (which I was
assuming), but from the scene module (which is one of the first modules
imported in __init__.py).
Importing the scene module actually has a side-effect. It creates the
global scene object which triggers some C++ code in its constructor:
_scene = Scene()
The Scene object itself is a Python object but in the constructor it
creates the root WorldObject and the Timer object which result in calls
to C++ code. It looks like the creation of this Scene object fails for
some reason.
According to the stack trace, the crash happens in
_WorldObjectChildIterator::next() which is defined in
wrappers/py_worldobject2.cpp. This code is actually part of the
wrappers, not the C++ lib itself. The class _WorldObjectChildIterator
implements the Python iterator that allows you to iterate over the
children objects of a WorldObject (which are stored in a STL map).
I don't know what part of the code actually does this iteration. At that
point, there is just the root WorldObject around (which has no children
yet anyway) and I can't think of anything at the moment, where the
children would get inspected.
Could you please run the following sequence in a Python shell:
>>> import cgkit._core
>>> cgkit._core._set_debug_flag(True)
>>> from cgkit.all import *
On my machine, this dumps the following output:
0x1889c08: Component::Component("WorldRoot")
0x1889c28: Slot<T>::Slot(aflags=0) (N9support3d4vec3IdEE)
0x1889c5c: Slot<T>::Slot(initialvalue, aflags=0) (N9support3d4mat3IdEE)
0x1889cc0: Slot<T>::Slot(initialvalue, aflags=0) (N9support3d4vec3IdEE)
0x1889cf4: Slot<T>::Slot(aflags=0) (N9support3d4mat4IdEE)
0x1889cf4: TransformSlot::onTransformChanged()
0x1889d98: Slot<T>::Slot(aflags=2) (N9support3d4mat4IdEE)
0x1889e54: Slot<T>::Slot(aflags=2) (N9support3d4vec3IdEE)
0x1889ea8: Slot<T>::Slot(aflags=2) (N9support3d4mat3IdEE)
0x1889f2c: Slot<T>::Slot(aflags=0) (d)
0x1889f4c: Slot<T>::Slot(aflags=2) (d)
0x1889f90: Slot<T>::Slot(initialvalue, aflags=0) (b)
0x1889fa8: Slot<T>::Slot(aflags=0) (N9support3d4vec3IdEE)
0x1889fd8: Slot<T>::Slot(aflags=0) (N9support3d4vec3IdEE)
0x1889c08: WorldObject::WorldObject("WorldRoot")
0x1889f2c: Slot<T>::addDependent(0x1889f4c)
0x1889f4c: Slot<T>::onValueChanged()
0x1889f2c: Slot<T>::addDependent(0x1889ea8)
0x1889ea8: Slot<T>::onValueChanged()
0x1889f2c: Slot<T>::addDependent(0x1889e54)
0x1889e54: Slot<T>::onValueChanged()
0x1889cf4: Slot<T>::addDependent(0x1889d98)
0x1889d98: Slot<T>::onValueChanged()
0x1889c08: Component::addSlot("transform", 0x1889cf4)
0x1889c08: Component::addSlot("pos", 0x1889c28)
0x1889c08: Component::addSlot("rot", 0x1889c5c)
0x1889c08: Component::addSlot("scale", 0x1889cc0)
0x1889c08: Component::addSlot("cog", 0x1889e54)
0x1889c08: Component::addSlot("inertiatensor", 0x1889ea8)
0x1889c08: Component::addSlot("mass", 0x1889f2c)
0x1889c08: Component::addSlot("totalmass", 0x1889f4c)
0x1889c08: Component::addSlot("worldtransform", 0x1889d98)
0x1889c08: Component::addSlot("visible", 0x1889f90)
0x1889c08: Component::addSlot("linearvel", 0x1889fa8)
0x1889c08: Component::addSlot("angularvel", 0x1889fd8)
0x1889f90: Slot<T>::setValue(val)
0x651698: Component::Component("Timer")
0x6516c8: Slot<T>::Slot(initialvalue, aflags=0) (d)
0x651698: Component::addSlot("time", 0x6516c8)
0x2461998: SizeConstraint::SizeConstraint()
0x245c648: SizeConstraint::SizeConstraint()
I suppose on your end, this sequence may terminate earlier because of
the bug. It would be interesting to know how much of the above actually
gets executed.
And just out of curiosity, what happens if you import the scene module
manually:
>>> import cgkit.scene
Does this also crash? (just to confirm that this is the culprit)
If not, does a subsequent import cgkit.all still crash?
> I can give it a try to find it, since it happens on my system. My
> problem is, that I have little time for it now.
> I installed cgkit because I need to render few simple 3d images and I
> wanted to have it quickly done, because I promised those images in
> November. It's my problem, of course, that I promised something I have
> no expertise in, I didn't know how complicated it would be.
> As I'm really in a hurry, I need first to solve my problem with those
> images, I'll either try to learn enough of the RenderMan to generate a
> rib directly or to learn blender and to do it by hand. I'm afraid that
> if I try to debug cgkit now, I'll spend few more nights with no
> guarantee of solving my problem.
No problem, I can understand that.
Out of curiosity again, what images do you need to render? Can I be of
any assistance? I take it as you contemplated using Python for that, it
may be more of a procedural image? Was your intention to use the
RenderMan binding directly? If so, the above bug doesn't have to bother
you as that one doesn't make use of all that scene stuff (just don't
import cgkit.all).
> When you install PyProtocols, make sure to use the --without-speedups
> (or something like that) option. There seems to be a bug in the C part
> of PyProtocols that sometimes causes exceptions. Sooner or later I
> actually want to get rid of the dependency on PyProtocols but I'm afraid
> that will take a while.
>
> So do you also get the crash on OSX?
>
> Well, no (not yet), I tried to install only the binary from
> cgkit-2.0.0alpha8-py2.5-macosx10.4.dmg
> <http://downloads.sourceforge.net/cgkit/cgkit-2.0.0alpha8-py2.5-macosx10.4.dmg?use_mirror=dfn>
> It didn't install until I installed python-2.5.4-macosx.dmg
> <http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg> from
> python.org <http://python.org>, and it didn't install with Python-2.6.1.
The binary is compiled against Python 2.5, it won't work with other
versions (whenever the major or minor version number changes, any Python
extension module needs to be recompiled).
By the way, are you using OSX 10.4 (which is what I still have) or 10.5?
(it would be interesting to know if the binary also works on 10.5)
> I already had Python-2.5.4 installed in /usr/local from MacPorts but it
> wasn't taken by the installer.
Yes, I think the installer needs the framework version.
> Now I have no idea how to install the extras into the locations where
> those dmg's expect them.
pygame has binaries as well, you should be able to install them just as
you did with cgkit as well.
PyProtocols is installed just like on other systems as well, by running
the setup.py script (python setup.py install). You may have to do that
as an Administrator though. And you have to make sure to run the setup
script using the correct Python interpreter! (the one that you want to
install the package for)
All the packages are installed into the main site-packages directory
which I think is always a path like this:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
But you never have to provide this path explicitly. The Python
interpreter knows that itself.
> I'm sorry but I do all my development on linux or standard unix, we use
> Mac just as a multimedia center, I didn't have time to learn how to
> maintain open source software there. Can I somehow combine the MacPorts
> with those two dmg's above?
If it's the same Python version (same major/minor version), then I don't
really see a reason why this should not work. Just point your PYTHONPATH
to the site-packages directory of the MacPorts version before running
the framework version.
> Otherwise I can install all the extras from
> MacPorts so they will end up in /usr/local but then I probably have to
> install the cgkit from sources and pray that it doesn't segfault, right?
Right. If you are using 10.4 then I would be very surprised when it
segfaults (as this is the system I have here as well).
By the way, on 10.4 I had a hard time using Python (and Boost) from
MacPorts because Boost.Python always linked against the system Python
(which is 2.3 on OSX 1.4) istead of the MacPorts Python. But this was a
while ago, maybe they have fixed that in the meantime. And I think on
OSX 10.5 it wouldn't matter because the system Python is also 2.5.
Cheers and sorry for all the inconvenience,
- Matthias -
|