Opened 16 years ago

Closed 16 years ago

Last modified 12 months ago

#1440 closed defect (fixed)

RC BS1+2: Crash while Video Playback (Windows)

Reported by: SF/florob Owned by: SF/ender
Priority: blocker Component: Engine: Sword1
Keywords: Cc:
Game:

Description

With Broken Sword 1 + 2 Sould Out version ScummVM's
current CVS crashes at some fixed points under WinXP for
me.
In BS1 it crashes in the intro when the balons fly in the
screen and in BS2 when george falls in the chair.
When these frames are skipped it doesn't crash when it
would normally, but some frames later (BS1 shortly before
the clown runs away).
console output:
WARNING: fnPlaySequence(4) called!
Fatal signal: Segmentation Fault (SDL Parachute
Deployed)

Ticket imported from: #892827. Ticket imported from: bugs/1440.

Change History (17)

comment:1 by Kirben, 16 years ago

Are you sure you encoded the cutscenes correctly ? I get no
crashes in those cutscenes when using latest ScummVM CVS
under Windows XP.
There were a few cutscenes fixes recently but just for some
issues with end of cutscenes and 640 x 480 cutscenes.

comment:2 by SF/florob, 16 years ago

I'm not perfectly true I have but I think when they are
"missencoded" it would be the fault of mencoder.
I also thought it might be a bug in Sid mencoder-686 package
but why would he always convert those frames wrong?
Also I thin an SDL Parachute is not the way ScummVM should
answer to missencoded files. But i don't really think mine are.

comment:3 by Kirben, 16 years ago

Try encoding at a different bitrate, to see if it helps.
I was unable to reproduce the problem with the Broken Sword
1/2 cutscenes which I encoded at 2400kb. But I reproduced
the error with the Broken Sword 1 demo cutscenes which I
encoded at default bitrate.
A back trace is below:
0x0052095a in Sword1::AnimationState::plotYUV(short*, int,
int, unsigned char* const*) (
this=0x264c378, lut=0x2ff0020, width=640, height=400,
dat=0x26517b0)
at sword1/animation.cpp:269
269 ptr[linepos ] = lut[i + dat
[0][ ypos ]];
(gdb) bt
#0 0x0052095a in Sword1::AnimationState::plotYUV(short*,
int, int, unsigned char* const*) (
this=0x264c378, lut=0x2ff0020, width=640, height=400,
dat=0x26517b0)
at sword1/animation.cpp:269
#1 0x00520b29 in Sword1::AnimationState::decodeFrame()
(this=0x264c378)
at sword1/animation.cpp:342
#2 0x00520c7a in Sword1::MoviePlayer::play(char const*)
(this=0x22fc20, filename=0x50455a "intro")
at sword1/animation.cpp:397
#3 0x00504629 in Sword1::Logic::fnPlaySequence
(Sword1::Object*, int, int, int, int, int, int, int)
(this=0x14a2908, cpt=0x0, id=0, sequenceId=4, d=0, e=0,
f=0, z=0, x=0) at sword1/logic.cpp:937

comment:4 by SF/florob, 16 years ago

It works encoded at 2400kb, but I leave this open 'cause I
think it is not a good behavior to crash. But you can close it if
you want to.

comment:5 by SF/ender, 16 years ago

Closing this, as we are not supporting self-encoded cutscenes.
(Feel free to submit a patch to fix the bug, however).

comment:6 by SF/ender, 16 years ago

Owner: set to SF/ender
Resolution: wontfix
Status: newclosed

comment:7 by Kirben, 16 years ago

Re-opening, as it occurs with official BS1 cutscene pack too.

comment:8 by Kirben, 16 years ago

Owner: SF/ender removed
Resolution: wontfix
Status: closednew

comment:9 by SF/ender, 16 years ago

Summary: BS1+2: Crash while Video PlaybackRC BS1+2: Crash while Video Playback (Windows)

comment:10 by SF/ender, 16 years ago

This appears to only occur under Windows. I'm testing on a Mac now just
to be sure.

comment:11 by SF/ender, 16 years ago

Priority: normalblocker

comment:12 by SF/ender, 16 years ago

Confirmed this to be a Windows only bug. Increasing priority as
Release Critical.

Unfortunatly, I have no idea at all how to fix it :P

comment:13 by eriktorbjorn, 16 years ago

I don't understand why it only happens with Windows, and I
don't understand exactly what's happening, but it should be
pretty easy to work around. The end result, and thus the
direct cause of the crash, is an out-of-bounds access to the
YUV-to-RGB lookup table.

I changed the code in plotYUV() to:

int u = (dat[1][cpos] + ROUNDADD) >> SHIFT;
int v = (dat[2][cpos] + ROUNDADD) >> SHIFT;
if (u >= BITDEPTH)
u = BITDEPTH - 1;
if (v >= BITDEPTH)
v = BITDEPTH - 1;
int i = ((v * BITDEPTH) + u) * 256;
// int i = ((((dat[2][cpos] + ROUNDADD) >> SHIFT) *
BITDEPTH) + ((dat[1][cpos] + ROUNDADD) >> SHIFT)) * 256;

Since I don't actually know which of the dat[] buffers
contain Y, U and V, I'm not sure if my variable names make
sense, and it'd be nicer if the code didn't explicitly have
to test for overflow... but you get the idea.

As I said, I have no clue why the problem doesn't happen on
every platform.

comment:14 by eriktorbjorn, 16 years ago

Please note that when I said that I changed the code, I
meant in my local copy of it. I haven't committed any such
changes to CVS.

comment:15 by SF/ender, 16 years ago

*nods*

Roever just made a slightly difference fix which is now applied to
CVS (head and branch). Closing bug.

comment:16 by SF/ender, 16 years ago

Owner: set to SF/ender
Resolution: fixed
Status: newclosed

comment:17 by digitall, 12 months ago

Component: Engine: Sword1
Note: See TracTickets for help on using tickets.