Opened 10 years ago

Closed 10 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
Version: 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 10 years ago.
savegame: talk to Uhura and select "woo"

Download all attachments as: .zip

Change History (13)

by tsoliman, 10 years ago

Attachment: qfg3-thief.000 added

savegame: talk to Uhura and select "woo"

comment:1 by tsoliman, 10 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, 10 years ago

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

Will check the current status

comment:3 by tsoliman, 10 years ago

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

comment:4 by tsoliman, 10 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, 10 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, 10 years ago

Owner: set to bluegr
Resolution: worksforme

comment:7 by tsoliman, 10 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[] = { 5, 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, 10 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, 10 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, 10 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, 10 years ago

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

comment:12 by wjp, 10 years ago

I merged the second pull request. Thanks!

Note: See TracTickets for help on using tickets.