[Adonthell-devel] Re: SDL_mixer

[Kai Sterker]

On Sun, 06 Jan 2002 12:48:22 +0100 (CET) Kai Sterker wrote
> I've changed our code back to the 1.2.0 mixer version, and am ashamed to
> say that it appear to work. Even under heavy load it ran fine for quite
> some time, so I guess the problem was related to the new SDL_mixer.

Or maybe not. I played some more and this time got 3 crashes inmidst a
song (all roughly the same kind, like the one below):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1993)]
0x8121bd2 in eval_code2 (co=0x85e6150, globals=0x85eb294, locals=0x0,
    args=0x8567e20, argcount=3, kws=0x8567e2c, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2259
2259    Python/ceval.c: No such file or directory.
Current language:  auto; currently c
(gdb) bt
#0  0x8121bd2 in eval_code2 (co=0x85e6150, globals=0x85eb294, locals=0x0,
    args=0x8567e20, argcount=3, kws=0x8567e2c, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2259
#1  0x8122d9d in fast_function (func=0x85e78f4, pp_stack=0xbfffe334, n=3,
    na=3, nk=0) at Python/ceval.c:3015
#2  0x8121431 in eval_code2 (co=0x828d248, globals=0x8471c34, locals=0x0,
    args=0x838ea70, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0,
    closure=0x0) at Python/ceval.c:1966
#3  0x8122c8c in call_eval_code2 (func=0x837b3d4, arg=0x838ea64, kw=0x0)
    at Python/ceval.c:2959
#4  0x8122882 in call_object (func=0x837b3d4, arg=0x838ea64, kw=0x0)
    at Python/ceval.c:2799
#5  0x8122b4c in call_method (func=0x837b3d4, arg=0x81cf114, kw=0x0)
    at Python/ceval.c:2916
#6  0x8122865 in call_object (func=0x844d32c, arg=0x81cf114, kw=0x0)
    at Python/ceval.c:2797
#7  0x812274e in PyEval_CallObjectWithKeywords (func=0x844d32c, arg=0x81cf114,
    kw=0x0) at Python/ceval.c:2734
#8  0x81006ef in PyObject_CallObject (o=0x844d32c, a=0x0)
    at Objects/abstract.c:1529
#9  0x80e38a1 in py_object::call_method (this=0x8274bac, address@hidden,
    args=0x0) at py_object.cc:105
#10 0x8155292 in py_object::run (this=0x8274bac, args=0x0) at py_object.h:126
#11 0x80b4dca in mapcharacter::update (this=0x8274b28) at mapcharacter.cc:723
#12 0x80b0708 in landmap::update (this=0x875dd9c) at landmap.cc:191
#13 0x80eecf7 in adonthell::main_loop (this=0x875dd90) at adonthell.cc:77
#14 0x80eec59 in adonthell::main (this=0x875dd90, wnd=0x84d0908, name={
      static npos = 4294967295, static nilRep = {len = 0, res = 0, ref = 4,
        selfish = false},
      dat = 0xbfffe5ec "\230\223\e\b\220\003#\bì\bM\bl\rM\b\230\223\e\b\b\tM\b
\220Ýu\b\220^:@<æÿ¿¶)\022\b"}) at adonthell.cc:51
#15 0x80d5e29 in _wrap_adonthell_main (self=0x0, args=0x823c454)
    at py_adonthell_wrap.cc:8738
[...]


I also have a new theory: the song-change script is executed from the
audio thread. So unlike any other script, it might interrupt the python
interpreter while another script runs, mess up the internals and cause a
crash. (either instantly, or a little later).

On a fast box, like your's, the chance that song change and execution of
another python script happen at the same time is rather small. But on my
old P200 it is much more likely, which might explain why I face more
problems.

The workaround would of course be to use a different python thread for
the song change script.

Or, perhaps easier: just set a flag in the audio thread and periodically
check that from the main thread and call the songchange script when
necessary.

I will try that and see what happens.


Kai