Serpent Isle hangs

[DirtyHairy]

Hi everybody!
I'm have some trouble getting SI running with exult. I've compiled a fresh exult 1.2 on a linux/ppc system (yellowdog). BG (with FoV) works fine, but when I want to start a SI (with SS) game, it segfaults and dies with a SDL parachute. I don't suspect the data files to be the culprit since they have worked for me in the past on another system (they are from a ultima VI + VII/2 cd collection). Just to make sure, I took the original files from the CD (I just unzipped the archive since I didn't want to go through the trouble of installing it in an emulation, I think that should work), but it didn't solve the crash. Sound or video don't seem to have anything to do with it (it happens regardless of my settings) and changing to the newest version of SDL doesn't help, either. The last lines appearing on stdout are exult finding the data files and setting up the paths, and after setting the patch directory, it dies.
Phew, long post... Has this anyone observed this before or got a clue?

[DirtyHairy]

Well, bad news: it also happens with latest CVS. Good news: the crash is triggered by the introduction; everything works alright when I disable the introduction, but it crashes when I trigger it manually from the menu. I tried to get a backtrace from gdb, but, unfortunately, only my first one was succesfull:

#0 0x10081ac0 in Palette::apply (this=0x10c4c790, repaint=false)
at palette.cc:118
#1 0x100c81b0 in playfli::play (this=0x7fffea60, win=0x10200210,
first_frame=0, last_frame=1, ticks=30055, brightness=1) at playfli.cc:153
#2 0x1009c91c in SI_Game::play_intro (this=0x10bc4820) at sigame.cc:214
#3 0x10047648 in Init () at exult.cc:773
#4 0x1004a080 in exult_main (runpath=Variable "runpath" is not available.
) at exult.cc:506
#5 0x1004b354 in main (argc=1, argv=0x7ffff824) at exult.cc:314

I wasn't able to reproduce this one; instead, I now always get

#0 0x0fec7774 in _int_free () from /lib/tls/libc.so.6
#1 0x0ffa2e54 in ?? () from /lib/tls/libc.so.6

So, anyone got a clue (perhaps some endianess issue) or should I submit this to the tracker?

[drcode]

Unfortunately, I don't think any of the developers have a PPC running Linux.

[DirtyHairy]

Hmmm, I did some debugging yesterday evening, and it seems the program enters Game::play_intro, enters the first playfli::play, decodes two chunks, goes to the very end of playfli::play alright and then crashes upon returning to play_intro without even executing a printf I put just after the call. Has anyone an idea what might be causing this behaviour?

[DirtyHairy]

After some fiddling, I finally sorted it out - it runs nice and smoothly now. It seems that
1) read1() doesn't handle signed chars on my system
2) pixbuf is one byte too short
I'll try the modified code on a x86 box when I find time and submit a patch to the tracker afterwards. The only thing I'm curious about: why does this work on other systems in the first place?

[Dominus]

sorry, we couldn't be much of help but it seems you really managed on your own
The patch would be welcome and I'm glad you worked it out.

[drcode]

As a guess, it may be that pixbuf has always been too short; but other systems may have a free byte or two after it that masks the bug.

[DirtyHairy]

OK, I've checked the changes on an x86 linux system; it works fine there as well, so I submitted the patch to the bug tracker (topic "si intro crashes..."). DrCode: I suppose so, but what I really don't get: on my system read1() always returns an signed char which caused pixpos to grow ridiculously large (~3k) and subsequently caused severe memory corruption: I can't see the reason why this works just fine on other systems - especially since someone already seems to have thought it neccesary to fix a similar problem for chunk 12 I suppose I would have spend ages trying to discover the culprit if it wasn't for that hint...

[Colourless]

I remember modifying a lot of the flic code, but I really can't remember eveything I did. Mostly it was for timing and ability to display a single frame and manually advance the frame (for compositing reasons among other things).