[Bf-python] Memory bug in Bpy api

[Toni Alatalo]

On Wednesday 18 January 2006 01:04, you wrote:
> cgkit-2.0.0alpha5.tar.gz gives a compiler error when running scons in
> cgkit-2.0.0alpha5/supportlib, as per the install instructions).  I

i needed to symlink one .cpp or was it a header file, the one that it did not 
find anyway, from /usr/include to that supportlib dir. stoopid scons there 
did not search the file from system places. but that one symlink was enuf

cgkit is interesting for several other reasons too (like it might be cool to 
have a Blender wrapper there, like there already is for Ogre (and Maya?) .. 
tho i guess really useful only when using renderman, so it is not the worst 
lib to have to install (but yah it is easy enough for mr. Parker <ShortWave> 
to do a gui thing that does not have external deps)

> Since blender_reload() appears in the stack track (which is a function I
> think I added for 2.40), I'd like to suggest narrowing the scope
> somewhat to at least figure out which module is being reloaded. when

i tested again by commenting out all reloads, and it did not crash on the 
second startup anymore. and this finally, after more irc talk, brought me to 
see the root of the problem:

currently bpy preserves loaded modules, with their contents, in memory 
*between runs*. i dont know if this is a new or an old bug, but a bug anyway 
i think. here is a little test script:

import math

try:
    math.x += 1
except AttributeError:
    math.x = 1

print math.x

running this many times in Blender gives:
1
2
3
...

i just learned that mr. Parker added the reload()s to get rid of that 
behaviour, i.e. the old vars from previous runs in the modules he uses (like 
ShaderEditorGUI.py) in the blend were disturbing and reload() cleared them.

he also just told me that "14:47 < ShortWave> I think timmeh was going to 
clear out some text->cached thing to fix that" so perhaps a fix is underway 
already?

> this happens.  Obviously, it's even better if a simple script can
> recreate the problem :-)  Maybe just some prints in the script prior to
> the reload() (or even import) statements.

there is also some bug in Blender.Draw, 'cause for several ppl UI scripts 
crash occasionally. *goes back to trying to reproduce* aha! now i got it 
immediately when gave the script the path to the shaders, when it then 
creates several sliders, buttons etc:
Current Shader:  ambientlight.sl
Program received signal SIGSEGV, Segmentation fault.
0xb7de369d in PyObject_SetItem () from /usr/lib/libpython2.4.so.1.0

.. seems to be that happens when i guess Blender is calling some callback on 
the py side?

(between #0 and #16 there is just a lot of PyEval_EvalFrame etc)
#17 0xb7dfb1b6 in PyFunction_SetClosure () from /usr/lib/libpython2.4.so.1.0
#18 0xb7de0fdf in PyObject_Call () from /usr/lib/libpython2.4.so.1.0
#19 0xb7e4292c in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.4.so.1.0
#20 0xb7de0fa6 in PyObject_CallObject () from /usr/lib/libpython2.4.so.1.0
#21 0x0860bf54 in exec_callback ()
#22 0x0822524a in winqreadscriptspace ()
#23 0x081bd46a in scrarea_do_winhandle ()
#24 0x0814561d in screenmain ()
#25 0x081164a7 in main ()

either someone should go thru the code, or manage to make failing tests for 
slider etc. creating & callback using funcs.

to me it has seemed as if there are currently safe and unsafe ways to use 
Draw, 'cause we do have script UIs that dont ever crash, no?

> Ken

~Toni