GameMonkey Script

GameMonkey Script Forums
It is currently Mon Oct 15, 2018 10:15 am

All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Mon Oct 08, 2018 11:00 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Continuing the talk about the 64-bit issue: "gmLibHooks.cpp" throws an assertion exception.
viewtopic.php?p=3111#p3111

<code>
*reference = a_machine.AllocPermanantStringObject(&stringTable[*reference])->GetRef();
</code>

In "gmConfig_p.h" changed the "#if 0" to "#if 1" (to use 64-bit data types) and "GM_PTR_SIZE_64" is also set. But this made no difference.

I don't think I can reproduce the bug in gme. If you have no idea, I'll try to provide what I find when I dig into the problem further (or I may try to circumvent it).


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 10:51 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
I've found the part of the script that causes the assertion to fail, just that piece alone triggers it:

Code:
foreach(k in l) { }


Any idea?


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 11:20 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 707
No ideas yet. I did examine the code, but every part I looked at appeared okay. I examined the code generation and execution sections related to your description.

1) You said it asserted in gmLibHooks::BindLib() after case BC_SETGLOBAL. Can you please tell me the exact instruction that was being processed? eg. (eg. BC_GETGLOBAL)
This is the value used by the switch statement: switch(*(instruction32++))

2) At the assert location
GM_ASSERT(*reference >= 0 && *reference < (gmptr) strings.m_size);
What is the full value of *reference in hex?
I'd like to see the upper and lower 32bit words.

3) You've examined the gmConfig_p.h file. Can you please check that the file you're looking at is the one being used?
You can place #error in the code, compile, and confirm that line of code is being compiled.

4) You said your build is 64bit. Can you confirm _M_X64 and GM_PTR_SIZE_64 are set and being used correctly. You can sizeof(gmptr) to verify etc.

5) See if you can make a stand alone reproduction case that I can run using just GME to execute plain script.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 11:35 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Thank you Greg!

I'll examine it further. Already do.

I previously said that "foreach(k in l) { }" causes the assertion, forget that, actually that does not seem true. I just got it running without the assertion a few times.

So at this point I'm confused and will try to follow your steps.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 1:49 pm 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
While running this simple code "foreach(k in l) { }". (Which alone does not work in 32-bit; but I get a proper error message and no assert fail). Other simple stuff like "print("hi");" just works on 64 and 32-bit. So I go with the "foreach" that seems to throw that bug.


1) I get the following instructions.

Code:
BC_GETGLOBAL (53)  0x35
BC_PUSHINT (43)  0x2b
BC_FOREACH (36)  0x24
BC_SETTHIS (56) 0x38


"BC_SETTHIS" seems to cause the problem.


2) At that instruction, the reference has the value:
0x 00000214 0c4453e8

"strings.m_size" is 2


3) Yes, the "gmConfig_p.h" I have is used, I confirm.


4) Also "_M_X64" and "GM_PTR_SIZE_64" is defined. Also gmint's and gmfloat's is defined to be 64-bit. I even had to adjust some function calls in my code to reflect that.



ADDITIONAL NOTE:
On a 32-bit build the instructions are different after "BC_FOREACH (36)":

Code:
BC_GETGLOBAL (53)  0x35
BC_PUSHINT (43) 0x2b
BC_FOREACH (36)  0x24
BC_BRZ (29)  0x1d
BC_BRA (28)  0x1c
BC_POP2 (38) 0x26
BC_RET (34) 0x22



Also here is the bytecode, both for 32 and 64-bit that I save to disk:

64-bit:
Code:
67 6D 6C 30 00 00 00 00 14 00 00 00 00 00 00 00
1A 00 00 00 02 00 00 00 6C 00 01 00 00 00 66 75
6E 63 00 00 00 00 01 00 00 00 00 00 00 00 02 00
00 00 03 00 00 00 40 00 00 00 35 00 00 00 00 00
00 00 00 00 00 00 2B 00 00 00 FE FF FF FF FF FF
FF FF 24 00 00 00 01 00 00 00 1D 00 00 00 38 00
00 00 00 00 00 00 1C 00 00 00 18 00 00 00 00 00
00 00 26 00 00 00 22 00 00 00


32-bit:
Code:
67 6D 6C 30 00 00 00 00 14 00 00 00 00 00 00 00
1A 00 00 00 02 00 00 00 6C 00 01 00 00 00 66 75
6E 63 00 00 00 00 01 00 00 00 00 00 00 00 02 00
00 00 03 00 00 00 30 00 00 00 35 00 00 00 00 00
00 00 2B 00 00 00 FE FF FF FF 24 00 00 00 01 00
00 00 1D 00 00 00 28 00 00 00 1C 00 00 00 10 00
00 00 26 00 00 00 22 00 00 00


I don't know if they SHOULD be the same, but they are the same UP TO "30" in the middle. It looks kinda shifted after that with sometimes different numbers. That looks weird to me and may point to the problem.


Last edited by bavoha on Tue Oct 09, 2018 2:57 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 2:42 pm 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Ok, I figured the first part of the binary is the string table. Then the length and the instructions/functions. Leaves the puzzle why the instructions on 32 and 64 bit come out different in BindLib.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 2:50 pm 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
So, this is the (better formated) bytecode that may give clues:

64-bit
Code:
35 00 00 00   BC_GETGLOBAL
00 00 00 00
00 00 00 00
2B 00 00 00   BC_PUSHINT
FE FF FF FF
FF FF FF FF
24 00 00 00   BC_FOREACH
01 00 00 00
1D 00 00 00   BC_BRZ
38 00 00 00
00 00 00 00
1C 00 00 00   BC_BRA
18 00 00 00
00 00 00 00   
26 00 00 00   BC_POP2
22 00 00 00   BC_RET


32-bit
Code:
35 00 00 00   BC_GETGLOBAL
00 00 00 00
2B 00 00 00   BC_PUSHINT
FE FF FF FF
24 00 00 00   BC_FOREACH
01 00 00 00
1D 00 00 00   BC_BRZ
28 00 00 00
1C 00 00 00   BC_BRA
10 00 00 00
26 00 00 00  BC_POP2
22 00 00 00  BC_RET


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2018 3:08 pm 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Yep, the "foreach" opcode is too short in 64-bit. You see the 0x38 that it then uses as the next instruction.

I have no idea where to fix this tho.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2018 8:18 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
I tried changing the "case" in "BindLib" to only increment instruction-pointer the foreach-opcode by an int32:

Code:
case BC_FOREACH:
    instruction += sizeof(__int32);
    break;


It now outputs the correct instructions on 64-bit.

Is that a valid solution?


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2018 9:00 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 707
Excellent detective work there!
The foreach was indeed inconsistently sized.
I've pushed a fix for this. Please let me know if it works well for you.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2018 9:23 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Thank you!

Looks like it works, I've a pretty complex script with a dozent of foreach's that I now run without problems :)

I've to add, I now use gmscript for more than 6 years now, including it in dozens of projects and this was the first problem I ever had. Excellent library!

After reaching 64-bit and MacOS support, my next big goal is to integrate a debugger :)

Have a great day, I will now :)


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2018 9:55 am 
Offline

Joined: Fri Nov 04, 2016 11:43 pm
Posts: 15
Wait, a small error with the commit seems to be:

Code:
        case BC_BRZK :
        case BC_BRNZK :
        case BC_FOREACH : instruction += sizeof(gmuint32); break;



Code:
        case BC_BRZK :
        case BC_BRNZK :  instruction += sizeof(gmptr); break;
        case BC_FOREACH : instruction += sizeof(gmuint32); break;


I have use the version I adjusted previously, so I did not noticed it first.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 10, 2018 10:47 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 707
Your fall through case fix is correct, thanks!

Great to hear you've made good use of GM.
I still think it remains a pretty cool and useful tool.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group