On Wed, Jun 28, 2006 at 10:47:24AM +0200, Marc Dequènes wrote: > > Ok, when I have some time I'll run balazar and slune through gdb on my > > amd64 machines and send the results! > > I've got no amd64 available for tests, and i taggued +help the soya bug > since a while without success. So, i'd be glad to get a backtrace, > thanks :-)
After digging into CDBS internals to find out how to create a
python-soya with debugging symbols, I got the following result:
[EMAIL PROTECTED]/tmp>balazar
* Balazar * Balazar lives in /usr/share/games
* Balazar * PyOpenAL not installed, trying PySDL_mixer...
* Balazar * Warning! Neither PyOpenAL nor PySDL_mixer are installed;
* music and sound are disabled!
* Balazar * (Psyco not found ; if you are using an x86 processor,
* installing psyco can speed up Balazar a little)
* Soya * Using 8 bits stencil buffer
* Soya * version 0.11.2
* Using OpenGL 2.0.2 NVIDIA 87.62
* - renderer : GeForce 6600/PCI/SSE2
* - vendor : NVIDIA Corporation
* - maximum number of lights : 8
* - maximum number of clip planes : 6
* - maximum number of texture units : 4
* - maximum texture size : 4096 pixels
* Tofu * Creating new player guus...
* Balazar * Creating level 0, 0...
* Tofu * Level level_0_0 8159424 activated !
* Tofu * Player guus login !
[1] 15552 segmentation fault (core dumped) balazar
[EMAIL PROTECTED]/tmp>mv core core.balazar
[EMAIL PROTECTED]/tmp>gdb python2.4 core.balazar
GNU gdb 6.4.90-debian
...
Reading symbols from /var/lib/python-support/python2.4/soya/_soya.so...done.
Loaded symbols for /var/lib/python-support/python2.4/soya/_soya.so
..
Core was generated by `/usr/bin/python2.4 -O /usr/games/balazar'.
Program terminated with signal 11, Segmentation fault.
#0 __pyx_f_5_soya_5_Land__render (__pyx_v_self=0xbc30b0,
__pyx_v_coordsyst=0xbc30b0) at _soya.c:52935
52935 ((struct __pyx_vtabstruct_5_soya__Material *)((struct
__pyx_obj_5_soya__Material
*)__pyx_2)->__pyx_base.__pyx_vtab)->_activate(((struct
__pyx_obj_5_soya__Material *)__pyx_2));
(gdb) info frame
Stack level 0, frame at 0x7fffffe2c290:
rip = 0x2b6c798c1584 in __pyx_f_5_soya_5_Land__render (_soya.c:52935); saved
rip 0x2b6c798bd05d
called by frame at 0x7fffffe2c300
source language c.
Arglist at 0x7fffffe2c258, args: __pyx_v_self=0xbc30b0,
__pyx_v_coordsyst=0xbc30b0
Locals at 0x7fffffe2c258, Previous frame's sp is 0x7fffffe2c290
Saved registers: rbx at 0x7fffffe2c268, rbp at 0x7fffffe2c270, r12 at
0x7fffffe2c278, r13 at 0x7fffffe2c280, rip at 0x7fffffe2c288
(gdb) info locals
__pyx_v_cur = <value optimized out>
__pyx_v_index = 14846752
__pyx_v_pack = <value optimized out>
__pyx_v_tri = <value optimized out>
__pyx_2 = (PyObject *) 0xffffffffabb92a50
(gdb) print *__pyx_2
Cannot access memory at address 0xffffffffabb92a50
(gdb) bt 10
#0 __pyx_f_5_soya_5_Land__render (__pyx_v_self=0xbc30b0,
__pyx_v_coordsyst=0xbc30b0) at _soya.c:52935
#1 0x00002b6c798bd05d in __pyx_f_5_soya_8Renderer__render_list
(__pyx_v_self=0x9b70e0, __pyx_v_list=0x680480) at _soya.c:7352
#2 0x00002b6c79891c1c in __pyx_f_5_soya_8Renderer__render
(__pyx_v_self=0x9b70e0) at _soya.c:7100
#3 0x00002b6c798cdf8e in __pyx_f_5_soya_7_Camera__subrender_scene
(__pyx_v_self=<value optimized out>) at _soya.c:22383
#4 0x00002b6c7987f23f in __pyx_f_5_soya_7_Camera__render_scene
(__pyx_v_self=0xb66ce0) at _soya.c:22428
#5 0x00002b6c79825623 in __pyx_f_5_soya_7_Camera_render
(__pyx_v_self=0xb66ce0, __pyx_args=<value optimized out>, __pyx_kwds=<value
optimized out>) at _soya.c:22475
#6 0x00000000004744a7 in PyEval_EvalFrame ()
#7 0x0000000000474fec in PyEval_EvalCodeEx ()
#8 0x00000000004bbd73 in PyClassMethod_New ()
#9 0x00000000004139a0 in PyObject_Call ()
(More stack frames follow...)
Looking in _soya.c tells me the generated code that segfaulted
corresponded to "/home/jiba/src/soya/model/land.pyx":1148.
There I see that it calls the function chunk_get_ptr(), which returns a
void * type, which is then used and cast without any checks.
I find chunk_get_ptr() in chunk.c. This file is dedicated to putting
stuff into chunks and getting it out again, in the process completely
removing any type information and doing potentially harmful pointer
arithmetic.
Anyway, debugging chunk.c didn't show any errors, the last call to
chunk_get_ptr() before the crash returned the same pointer that was
added to it with chunk_add_ptr(). Still, it could mean that the Pack
that is being referenced in land.pyx around line 1148 has already been
deleted earlier, or that the pointer it retrieves from renderer.data is
not the pointer it expected. Anyway, here I quit, I hope you or the soya
developers can use this information.
Debugging results for slune will be added to #338913.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
