Building Slate VM with Microsoft Visual C++ under Windows XP (was: 0.3 Updates)

[Brian T. Rice]

For the info of all (well, for Windows users)...

Jaco van der Merwe <jacovdmerwe at telkomsa.net> said:

> Hi Brian
> 
> I'm sending this email to you to post on the Slate mailing list if you don't
> mind. I apologise for the inconvenience. I'm not sure what's happening with
> the list, but for some reason the mailing list emails are not being
> delivered to this address any more, but I know for a fact that I am
> subscribed. Also, my yahoo address I use to post to mailing lists has not
> been accepted yet for subscription (it's been several days now), so I can't
> post directly to the list. I refuse to use this email address for posting
> due to the evil of spam!
> 
> Kind regards
> Jaco

I'll get the site administrator's attention to see what is the matter with 
your email situation.

> ---Message content follows---
> 
> Hi all,
> 
> Yeah! I've managed to compile and run the Slate VM with the Microsoft Visual
> C++ compiler as follows.
> 
> * Change all the "inline" function modifiers to "_inline".
> 
> * Remove the extraneous "ObjectPointer elements[0]" field from the following
> structs in both the "vm.c" and "vm.h" files.
> 
>     struct RoleTable
>     struct SlotTable
> 
> Make a Debug build and run the vm.exe with the little.image file and, lo and
> behold, it works!

Hooray! :)

> Now here comes the problematic part.
> 
> When I make a Release build the VM crashes with a memory access violation.
> Hmmm, so the debug build works but the release build crashes. Based on my
> experience with Visual C++ this is most probably a symptom of an
> uninitialised variable or pointer somewhere in the code which causes a
> memory smash. So why does it work with the debug build? A debug build in
> Visual C++ zeros all variables by default. This does not happen in the
> release build, so maybe somewhere there is an uninitialised variable or
> pointer lurking around which causes this. Here is the stack dump from VC++
> when the access violation occurs:
> 
>   vc7.exe!PSObjectHeap_cloneOopArray_sized_(ObjectHeap * oh=0x0012ae44,
> Object * proto=0x00000000, unsigned long oops=1)  Line 3075 + 0xa C
> > vc7.exe!PSObjectHeap_newOopArray_sized_(ObjectHeap * oh=0x0012ae44,
> unsigned long index=5, unsigned long oops=1)  Line 980 + 0x27 C
>   vc7.exe!PSInterpreter_newBlock_(Interpreter * i=0x0048fb68, unsigned long
> n=0)  Line 1090 + 0x19 C
>   vc7.exe!PSInterpreter_interpret(Interpreter * i=0x0048fb68)  Line 2837 +
> 0xd C
>   vc7.exe!main(int argc=2, char * * argv=0x00321688)  Line 95 + 0x1b C
>   vc7.exe!mainCRTStartup()  Line 259 + 0x12 C
> 
> Ok, I've just spent some time on tracing how the crash occurs.
> 
> It happens in the second iteration of the loop of the
> PSInterpreter_interpret() function. In this 2nd loop the value of op=9 and
> val=0. The code branches to the case 9 at line 2837 which calls
> PSInterpreter_newBlock_(i, val=0).
> 
> At line 1090 in the function PSInterpreter_newBlock_() the function
> PSObjectHeap_newOopArray_sized_(CurrentMemory, ArrayProto=5, 1) is called.
> 
> At line 980 in the function fPSObjectHeap_newOopArray_sized_() the function
> call PSObjectHeap_specialAt_(oh, index=5) returns 0. After passing this
> value into the function ObjectPointer_pointer(0,oops=1) the result remains
> 0. This value of 0 is then passed as the Object* proto argument into the
> function PSObjectHeap_cloneOopArray_sized_(oh, proto=0, oops=1). The memory
> access violation occurs in the first line of the latter function which
> accesses fields of the proto argument, which is now zero.
> 
> I hope this helps. When I have some more time I'll compare the execution of
> the release build with that of the debug build and determine where things
> start to differ. That should give a good pointer to the source of the
> problem.

Thanks, this is good information.

> Regards
> Jaco