mechanicmarx / gamekit

Automatically exported from code.google.com/p/gamekit
0 stars 0 forks source link

Latest Vehicle Demo crashes on Windows #100

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
---------
1. Include the vehicle demo in the CMake build instructions
2. Build all targets in MSVC
3. Try to run the AppVehicleDemo

What is the expected output? What do you see instead?
---------
Expected output is, as per the working OSX build, the club silo blender scene 
with a working mini car. What actually happens is a crash on line 607 of 
bFile.cpp with an invalid oldPtr.

What version of the product are you using? On what operating system?
---------
Latest checkin of code (r609) on Windows XP SP2 using MSVC 8

Original issue reported on code.google.com by BenT.Sol...@gmail.com on 7 Sep 2010 at 5:58

GoogleCodeExporter commented 8 years ago
AppVechicleDemo is working fine on me. (vs2010 windows7 r609)
Try, remove the clubsilo_demo.blend file & recheckout.

Original comment by harkon...@gmail.com on 7 Sep 2010 at 9:34

GoogleCodeExporter commented 8 years ago
Removed the blend, deleted build directory (i.e. directory populated by CMake), 
recreated projects from scratch, rebuilt projects. Same result. 

This is only happening with the vehicle demo. The standard runtime & logic 
demos are both working fine and the issue does not occur on the Mac (OSX 10.6). 

I cannot be sure it was a recent build that caused this as I have been building 
and testing on the Mac for a few weeks now, but am tempted to work my way back 
to find when it stopped working (I suspect the type changes for 64 bit stuff - 
it makes sense given the error is in mismatched pointers).

Original comment by BenT.Sol...@gmail.com on 7 Sep 2010 at 11:03

GoogleCodeExporter commented 8 years ago
Nice find, This is because of the previous 64-bit commit I made.

All this pointer to pointer look up is a bit involved, the error is due to 
going over the 64bit buffer size. So for each 64bit pointer, it was reading (n 
*4)  pointers, so we get an overflow.

Original comment by snailr...@gmail.com on 7 Sep 2010 at 12:03

GoogleCodeExporter commented 8 years ago

Original comment by snailr...@gmail.com on 7 Sep 2010 at 12:10

GoogleCodeExporter commented 8 years ago
And to confirm, r610 does indeed fix the problem locally :)

Nice to know that intuition (that it was a 64 bit pointer issue) is still a 
desirable trait in programming -laugh-

Original comment by BenT.Sol...@gmail.com on 7 Sep 2010 at 12:54