Help debugging Broken Sword II crash

[ner0]

First of all, I need to be upfront and disclose that I'm the one causing the crash (unwillingly though), but I don't seem to get anything in the log or console to debug exactly why the crash happens.

A bit of much needed context:
I'm attempting to reverse engineer Broken Sword 2 TEXT.CLU file which contains dialogue and menu text (translations and all that). This has probably been done since there are some scarce fan translations out there it seems, and I don't like to "reinvent the wheel" as it were, but I just couldn't find any tools or documentation about the format. So I've been using my very modest set of skills to do it myself (here if anyone is interested, it's ongoing I suppose, don't need to clutter the forum with it unless necessary).

At this point I have a pretty good idea about the structure of TEXT.CLU, except that halfway through my tests the game started to crash on launch, especially after a dialogue line goes beyond a certain length, but unfortunately there is no useful information to debug the crash. Debugging commands are very useful when the game is running, on launch not so much.

I'm willing to put the effort in to see this through anyway, but I figured I would ask for suggestions since I've been stuck with this particular problem and it makes me wonder what is it about the file that crashes ScummVM since no parsing error is printed in the console. The structure seems to comply, I keep thinking that maybe a buffer's size dictated by something else is being overflown or there is some detail about the structure of this file that I might have missed - even though I triple-checked

I ended up posting this in the Junkyard section because I don't think this fits anywhere else, if anywhere.

I appreciate any replies in advance.

P.S: I'm using the PC Gamer Demo (English) version to approach this, it's probably safe to link it but unwarranted at this point.

[Praetorian]

Are you testing with a debug version of ScummVM? I believe our dailies are debug builds. You could always build your own of course from the source code. Maybe that would provide a bit more info upon the crash.

I think debugging is the way to go here. Do a step debug as soon as the game launches (if the crash happens at launch) and check where it fails.

I am not very familiar with the sword2 engine but quick-looking at the code, it looks like at least some relevant parsing code is here:
https://github.com/scummvm/scummvm/blob ... 2/resman.h
https://github.com/scummvm/scummvm/blob ... resman.cpp

Are you making all your changes with a hex editor? That sounds like a lot of hassle and it could go wrong very easily. Typically a script (python or c++) to automate the process is preferable here.

[ner0]

Thanks for the suggestions, I was already using a rudimentary script for that purpose but since the issue would be triggered easily I was doing more manual trial and error stuff.

Anyway, I seem to have figured out the last piece of the puzzle, which is that the byte-size of all Text Resources must be divisible by 4, which means that if the length of any dialogue is changed, and the size of the Text Resource ends up not being divisible by 4, then one must add null padding at the end of the resource until it is divisible by 4.

This sort of escaped me because earlier on I was already facing a similar situation, but was quickly put on the right track by the console debug with outputs an assertion, as is the case here: https://github.com/scummvm/scummvm/blob ... n.cpp#L475 (although the divisibility is 8 in this one due to the offset/chunk size pair).

I've looked a bit more into resman.cpp but I didn't find any direct assertion, verbosity, or otherwise, that would validate if the resource is logically sane. Maybe it just assumes that the first assertion was successful and nothing else should go wrong, but then crashes somewhere else when parsing the resource. Granted that an official resource would always be valid, but I'm just pointing out that it asserts if the lookup table size is good, but not the text resources. Although checking the resources would require more resources than is probably worth it. Anyway, at least a try/catch/throw would be nice.

I still wonder if the original engine would also crash given the same situation, I assume it would since all resources are divisible by 4 - quite a few of them using null padding too.

Edit:
This may be where it crashes or at least where it starts:

Code: Select all

_totalResFiles = size / 4;

It probably gets a whole number, but will lead to a crash eventually, here I think it could prevent the crash by having:

Code: Select all

assert((size % 4) == 0);
_totalResFiles = size / 4;