Re: [Adonthell-devel] Python weirdness (a real weirdy one) - please test

[Kai Sterker]

Am Sonntag, 27.07.03 um 16:11 Uhr schrieb Alexandre Courbot:

> Today I wanted to port my intersection tests to 0.4. I had some weird 
> python
> errors, so I've tried on another simpler example (it's 
> test/gfxtest.py).

For some reason, I think that there are some bugs in the python 
callback stuff. Because with your gfxtest code, I get exactly the same 
error that I get with inputtest.py. (Although that could also be 
something OS X related). Anyway, I am using 2.2.2 as well. On running 
gfxtest.py, I get a black window with a little white rectangle. After 
pressing a key, I get:

In callback!

Program received signal EXC_BAD_ACCESS, Could not access memory.
PyErr_Occurred () at Python/errors.c:81

(gdb) bt
#0  PyErr_Occurred () at Python/errors.c:81
#1  0x00a86b08 in python::show_traceback() () at python.cc:30
#2  0x007ae294 in python::functor_1ret<input::keyboard_event*, 
int>::run(input::keyboard_event*) (this=0xa44b20, arg1=0xbffff860) at 
../../../src/python/callback.h:170
#3  0x007aed70 in base::membertranslator_1ret<input::keyboard_event*, 
int, python::functor_1ret<input::keyboard_event*, int>, int 
(python::functor_1ret<input::keyboard_event*, 
int>::*)(input::keyboard_event*)>::thunk(base::functor_base const&, 
input::keyboard_event*) (address@hidden, p1=0xbffff860) at 
../../../src/base/callback.h:460
#4  0x008d4a58 in base::functor_1ret<input::keyboard_event*, 
int>::operator()(input::keyboard_event*) const (this=0xa44b20, 
p1=0xbffff860) at ../../src/base/callback.h:429
#5  0x008ad340 in input::listener::raise_event(input::event*) 
(this=0xa44790, ev=0xbffff860) at listener.cc:110
#6  0x008ad444 in input::manager::raise_event(input::event&) 
(address@hidden) at manager.cc:41
#7  0x00eb2c5c in sdl_LTX_input_manager_update () at 
sdl/manager_sdl.cc:512
#8  0x007afb00 in input::manager::update() () at 
../../../src/input/manager.h:59
#9  0x00784208 in _wrap_manager_update (self=0x0, args=0x3416a0) at 
py_input_wrap.cc:1984
#10 0x000745e4 in eval_frame (f=0x3568d0) at Python/ceval.c:2014
#11 0x00075a0c in PyEval_EvalCodeEx (co=0x341640, globals=0x0, 
locals=0x7ae294, args=0x3568d0, argcount=3500576, kws=0x0, kwcount=0, 
defs=0x356a1c, defcount=0, closure=0x0) at Python/ceval.c:2595
#12 0x00078514 in PyEval_EvalCode (co=0xb73f14, globals=0x0, 
locals=0xa86b08) at Python/ceval.c:481
#13 0x00029c98 in run_node (n=0x3416a0, filename=0x0, globals=0x0, 
locals=0x3568d0, flags=0x5b530) at Python/pythonrun.c:1079
#14 0x0002946c in PyRun_SimpleFileExFlags (fp=0xa0006b0c, 
filename=0xbffffe62 "test/gfxtest.py", closeit=1, flags=0x341640) at 
Python/pythonrun.c:685
#15 0x000060c4 in Py_Main (argc=-1073742238, argv=0xa0006b0c) at 
Modules/main.c:364
#16 0x00001fc8 in _start (argc=-1073742238, argv=0xa0006b0c, 
envp=0xbffffe6d) at /SourceCache/Csu/Csu-45/crt.c:267
#17 0x00001e48 in start ()


Could it be that some of our code overwrites some python/error checking 
related parts of the heap? That might explain why you have the error 
flag set, while I get a crash in PyErr_Occured(). The location is 
pretty much the same, I'd say, but different endianness might cause the 
different result.


> It's the line "arg4 = (unsigned short) PyInt_AsLong(obj3);" which 
> fails,
> setting the error flag (PyErr_Occurred is not None) after that. But! 
> obj3 IS
> an integer! I can print it using PyObject_Print, it prints the right 
> value.
> And PyInt_Check returns true! And after the call to PyObject_Print the 
> value
> in arg4 is the right one.

Maybe it's not the conversion that fails, but rather something that 
messes with PyErr_Occurred, as said above. Since my python related 
problems with 2.3c1 were not the fault of python, I'll install that 
again and retry. But I'd say it is our fault, not that of python.

Kai