Opened 9 years ago

Closed 9 years ago

#5698 closed defect (fixed)

SCI: QFG3: Script error in uhuras tent "woo"

Reported by: tsoliman Owned by: wjp
Priority: normal Component: Engine: SCI
Keywords: script Cc:
Game: Quest for Glory 3


Script error:
[VM] kMemory[72]: signature mismatch via method ::export 6 (script 999, room 440, localCall 0xffffffff)!

To reproduce, use attached save. Talk to Uhura and select "Woo"

linux self compiled git master @ 33c3e19

Ticket imported from: #3300241. Ticket imported from: bugs/5698.

Attachments (1)

qfg3-thief.000 (54.6 KB ) - added by tsoliman 9 years ago.
savegame: talk to Uhura and select "woo"

Download all attachments as: .zip

Change History (13)

by tsoliman, 9 years ago

Attachment: qfg3-thief.000 added

savegame: talk to Uhura and select "woo"

comment:1 by tsoliman, 9 years ago


Call stack (current base: 0x0):
0: script 994 - Glory::replay()
obj@0001:34d2 pc=0004:04e5 sp=ST:0001 fp=ST:0000 argp:ST:0001
1: script 0 - Glory::doit()
by 0 obj@0001:34d2 pc=0001:0324 sp=ST:0006 fp=ST:0003 argp:ST:0002
2: script 994 - Game::doit()
by 1 obj@0001:34d2 pc=0004:067c sp=ST:000b fp=ST:0008 argp:ST:0007
3: script 996 - User::doit()
by 2 obj@001e:043c pc=001e:00a6 sp=ST:000d fp=ST:000d argp:ST:000c
4: script 996 - User::handleEvent(001e:041c)
by 3 obj@001e:043c pc=001e:0351 sp=ST:0015 fp=ST:0010 argp:ST:000e
5: script 998 - Uhura::handleEvent(001e:041c)
by 4 obj@0067:0212 pc=0012:0614 sp=ST:0018 fp=ST:0018 argp:ST:0016
6: script 950 - View::handleEvent(001e:041c)
by 5 obj@0067:0212 pc=0013:02b9 sp=ST:001c fp=ST:001b argp:ST:0019
7: script 950 - CueObj::changeState(0000:0003)
by 6 obj@0013:045c pc=0013:0149 sp=ST:0020 fp=ST:001f argp:ST:001d
8: script 440 - uhuraTell::doVerb(0000:0002)
by 7 obj@005c:189a pc=005c:06f0 sp=ST:0024 fp=ST:0023 argp:ST:0021
9: script 23 - Teller::doVerb(0000:0002)
by 8 obj@005c:189a pc=004b:0223 sp=ST:0028 fp=ST:0027 argp:ST:0025
a: script 23 - uhuraTell::respond()
by 9 obj@005c:189a pc=004b:03e5 sp=ST:002a fp=ST:002a argp:ST:0029
b: script 440 - uhuraTell::doChild(0000:ffb5)
by a obj@005c:189a pc=005c:06d6 sp=ST:002d fp=ST:002d argp:ST:002b
c: script 23 - Teller::doChild(0000:ffb5)
by b obj@005c:189a pc=004b:0721 sp=ST:0031 fp=ST:0030 argp:ST:002e
d: script 999 - export 6 (005d:0164, 0000:001b)
by c obj@005c:189a pc=0003:02bd sp=ST:0037 fp=ST:0034 argp:ST:0031

comment:2 by bluegr, 9 years ago

I don't get this... this error should have been fixed already:

Will check the current status

comment:3 by tsoliman, 9 years ago

FWIW I am using the quest for glory anthology version of QFG3.

comment:4 by tsoliman, 9 years ago

Thanks for linking to #3040722.
I couldn't figure out what r4766774 means and found that it is 4766774b3dbd8824276ad7ff2e3c916b6dc1de37 (matched by date of comment in bug #3040722)

comment:5 by bluegr, 9 years ago

r4766774 is the SVN revision - we used SVN back then

I just verified this, I can't reproduce this bug anymore, even with your saved game. Can you try a full rebuild?

comment:6 by bluegr, 9 years ago

Owner: set to bluegr
Resolution: worksforme

comment:7 by tsoliman, 9 years ago

I did a full rebuild.
Here's what coming out of the commented-out debug call from that fix's diff.

ldi: 999, 0, 4, 0, acc = 0000:0000, script 23, local script 23
lt?: 0, 0, 4, 0, acc = 0000:03e7, script 23, local script 23
jmp: -60, 0, 4, 0, acc = 0000:0001, script 23, local script 23

This looks (at face value) to match the patch's "before" bytes
const byte qfg3DialogCrash[] = {
0x34, 0xe7, 0x03, // ldi 3e7 (999)
0x22, // lt?
0x33, // jmp [back] ---> BUG! Infinite loop

Yet it is still not being applied. I will debug more and try to see what is going on.

comment:8 by tsoliman, 9 years ago

I put a breakpoint in line 1156 of script_patches.cpp where it says:
if (memcmp(signatureData, &scriptData[byteOffset], matchBytesCount)) // Byte-Mismatch?
That only triggers if signature->scriptNr==23
This memcmp is returning false. Here are the memory values.
byteOffset == 1865
matchBytesCount == 5
signatureData[0] == scriptData[byteOffset] == 0x34
signatureData[1] == scriptData[byteOffset+1] == 0xe7
signatureData[2] == scriptData[byteOffset+2] == 0x3
signatureData[3] == scriptData[byteOffset+3] == 0x22
signatureData[4] == scriptData[byteOffset+4] == 0x33

the while loop continues and sets matchAdjust = 0x34 and byteoffset 1922
In the next iteration it sets matchBytesCount == 0 .. not sure why it cares about this anymore since it matched the whole signature.
the 3rd iteration goes "Out-Of-Bounds?" and breaks out of the loop

matchAdjust is not zero and so we don't return the offset. Eventually it returns -1.

That's why the patch doesn't apply here.

comment:9 by tsoliman, 9 years ago

My understanding (just from looking at code): patch sigs are one or more hunks. Each hunk is 1 byte which gives "length of data" and the rest of the bytes are data. The patches I looked at are all 1 hunk. After the last hunk, getting the next hunk length gives zero which means "stop working on hunks".

Let me know if I am totally misunderstanding the way patch sig matching works.

I think I have a fix in
Please look at it and see if it makes any sense to you.

comment:10 by tsoliman, 9 years ago

Apparently adding a zero to the end of the signature also works :)
I think this might be a platform dependent thing (LordHoto said you were on windows)

comment:11 by wjp, 9 years ago

Owner: changed from bluegr to wjp
Resolution: worksformefixed
Status: newclosed

comment:12 by wjp, 9 years ago

I merged the second pull request. Thanks!

Note: See TracTickets for help on using tickets.