Opened 13 years ago
Closed 13 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 |
Description
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)
Change History (13)
by , 13 years ago
| Attachment: | qfg3-thief.000 added |
|---|
comment:1 by , 13 years ago
Backtrace:
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 , 13 years ago
I don't get this... this error should have been fixed already: http://sourceforge.net/tracker/?func=detail&aid=3040722&group_id=37116&atid=418820
Will check the current status
comment:4 by , 13 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 , 13 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 , 13 years ago
| Owner: | set to |
|---|---|
| Resolution: | → worksforme |
comment:7 by , 13 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 , 13 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 , 13 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 https://github.com/scummvm/scummvm/pull/37 Please look at it and see if it makes any sense to you.
comment:10 by , 13 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)
https://github.com/scummvm/scummvm/pull/38
comment:11 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | worksforme → fixed |
| Status: | new → closed |
savegame: talk to Uhura and select "woo"