Resource Bug

[Ildiz]

Hey,
I've been playing around with the AI code all morning (as part of my thesis) but GAE keeps crashing.
Basically when the AI deplete a resource e.g. a gold vein. The game crashes, this points to part of the:
void HarvestCommandType::update(Unit *unit) function.

I disabled all the AI functionality (bar auto attack) and set about depleting my own resources to see if it still crashed.
It did. This time though it points to line 776 of the vector include file.

Can't really say much more than that. It's a really odd bug, brings up a dialog box with 'break' and 'continue' options.
Is there any known fix for this? Couldn't find anything with a quick browse / search of the GAE forums.

Cheers,
Matt

P.S: If this helps, this is the line that appears in the debug output.
Unhandled exception at 0x01465db4 in glestadv.exe: 0xC0000005: Access violation reading location 0xfeeefefa.

[Omega]

Hey,
I've been playing around with the AI code all morning (as part of my thesis) but GAE keeps crashing.
Basically when the AI deplete a resource e.g. a gold vein. The game crashes, this points to part of the:
void HarvestCommandType::update(Unit *unit) function.

I disabled all the AI functionality (bar auto attack) and set about depleting my own resources to see if it still crashed.
It did. This time though it points to line 776 of the vector include file.

Can't really say much more than that. It's a really odd bug, brings up a dialog box with 'break' and 'continue' options.
Is there any known fix for this? Couldn't find anything with a quick browse / search of the GAE forums.

Cheers,
Matt

P.S: If this helps, this is the line that appears in the debug output.
Unhandled exception at 0x01465db4 in glestadv.exe: 0xC0000005: Access violation reading location 0xfeeefefa.

We'll need more information, namely OS, graphics card, and all the technical stuff, as well, you'll need to copy the entire crash log and paste it here. That should be in your personal folder/glestae. As well, have you tried using a precompiled binary?

[Ildiz]

We'll need more information, namely OS, graphics card, and all the technical stuff, as well, you'll need to copy the entire crash log and paste it here. That should be in your personal folder/glestae. As well, have you tried using a precompiled binary?

Tech info:
Windows Vista 64 bit
Intel Core 2 Quad Q9550 2.83 GHz
ATI Radeon HD 4870 x2
(Yeah yeah, Intel with ATI not the best combo etc. etc. - I doubt this affects the game at all, run all my other games fine)

As for the crash log, I cannot find that anywhere at all. I compiled with the guide for windows.
Searched through all the folders and can't find anything with Crash or Log as the name :S

[Omega]

\
As for the crash log, I cannot find that anywhere at all. I compiled with the guide for windows.
Searched through all the folders and can't find anything with Crash or Log as the name :S

In windows vista, the crash logs will be saved at C:\Users\user\glestadv the two files to look for are the gae-crash.txt (crash log) and glestadv-crash_date.png (image of the crash). The glestadv-error.log will be used if the crash is related to the data. Because you compiled this yourself, can you please first check to see if the windows installer works? That narrow it down between either your compiled version (where theres a wide variety of things that could go wrong) and your system. And of course, make sure your graphics card is up to date.

Unrelated:

(Yeah yeah, Intel with ATI not the best combo etc. etc. - I doubt this affects the game at all, run all my other games fine)

Actually, Intel with AMD (the new name for ATI) is the best way to go, as Intel makes the best processors and ATI makes the best graphics cards (bearing in mind that is all opinionated).

[Ildiz]

In windows vista, the crash logs will be saved at C:\Users\user\glestadv the two files to look for are the gae-crash.txt (crash log) and glestadv-crash_date.png (image of the crash). The glestadv-error.log will be used if the crash is related to the data.

Well I looked here for both of these files and neither are here, only "glestadv-error.txt" which is empty.
When the code breaks, it doesn't end the program, just freezes it. I have to task manager my way back to the code and the error message is there with the 'break' and 'continue' options.

Because you compiled this yourself, can you please first check to see if the windows installer works? That narrow it down between either your compiled version (where theres a wide variety of things that could go wrong) and your system.

Ok time to sound like a complete newbie, what is the windows installer thing you're talking about?

I'll try break it again tomorow and see if the logs are only temp files, which could be the problem since it's been several hours since I last broke it.

[Omega]

Ok time to sound like a complete newbie, what is the windows installer thing you're talking about?

You can find that right here: https://forum.megaglest.org/index.php?topic=6283.0

Alternatively, the sourceforge page may be a bit harder to use, but will always be up to date, whereas that one is just for 0.3.2 and when 0.4 is released, there will be a new topic.
http://sourceforge.net/project/glestae

[hailstone]

Being an unhandled exception I don't think there will be any log files. If there is a retry button it will break into the debugger instead of freezing. I'm not able to reproduce the crash. The problem seems to be a null or invalid pointer being dereferenced, possibly one in a vector. A stack trace would be useful.

[Ildiz]

Ok here is an update.
The Windows installer version of GAE works fine (without the resource bug) HOWEVER, I did manage to crash it again xD
I tried to morph 11 units at the same time and it froze up. It made a crash.txt for this one, and the image.

So the resource crash doesn't happen on this version, just a different error.

So what could be the cause of the build version exception? Should I just re-create it using the guide again and see if that fixes it?

Regards,
Matt.

P.S - above crash info to follow.

Crash.txt for the above crash:
Crash
Version: Advanced Engine 0.3.2
Time: Tue Mar 22 12:09:26 2011
Description: Access violation (Reading address: 0x000004D8)

Call Stack:
  Frame       Code address
  0x00BBF6E4  0x01123AAE Glest::ProtoTypes::MorphCommandType::update+0x7e at cmd_types_general.cpp(671)
  0x00BBF704  0x011AA56A Glest::Sim::SimulationInterface::doUpdateUnitCommand+0xea at sim_interface.cpp(424)
  0x00BBF734  0x011B2A3B Glest::Sim::World::updateFaction+0xbb at world.cpp(273)
  0x00BBF750  0x011B2C19 Glest::Sim::World::processFrame+0xa9 at world.cpp(317)
  0x00BBF774  0x011A9CD6 Glest::Sim::SimulationInterface::updateWorld+0xd6 at sim_interface.cpp(248)
  0x00BBF7B8  0x01084CD7 Glest::Gui::GameState::update+0x127 at game.cpp(265)
  0x00BBF810  0x010CADD6 Glest::Main::Program::loop+0x426 at program.cpp(284)
  0x00BBFD88  0x010C8837 Glest::Main::glestMain+0x3b7 at main.cpp(16707566)
  0x00BBFD90  0x010C8A0D main+0x1d at main.cpp(225)
  0x00BBFDD8  0x01241D93 __tmainCRTStartup+0xfb at crt0.c(266)
  0x00BBFDE4  0x76A8ECCB BaseThreadInitThunk+0xe
  0x00BBFE24  0x7711D24D RtlCreateUserProcess+0x8c
  0x00BBFE3C  0x7711D45F RtlCreateProcessParameters+0x4e

=======================

Image for the crash:
http://img202.imageshack.us/img202/9526/glestadvcrash.jpg

[Ildiz]

Ok so, I just updated my graphics drivers - they released one a couple of weeks ago and mine didn't tell me.
So, I ran the build version again and yes, it still broke again.
Again, still happenening when the resource is depleted, this time though, instead of breaking in the vector file it broke in the object.cpp at the code (line 56):
bool MapObject::getWalkable() const{
   return objectType==NULL? false: objectType->getWalkable();
}

I don't know how much of a difference this makes to you, but it's still breaking for me.

[hailstone]

Are you testing with or without your code changes?

I assume you're using VisualStudio, if so copy/paste the call stack when it goes to the debugger (bottom right).

[Ildiz]

Ok so, I went through all the code I had commented and removed all the comments (which i thought i did yesterday but i missed some in ai_rule.cpp), I've only used ai.cpp and ai_rule.cpp.

I ran it again with all the code uncommented (like it was when i downloaded it) and it broke again when the resource depleted.
It pointed to line 935 in the cmd_types_worker.cpp :
if (!this->canHarvest(res->getType())) { // wrong resource type, command changed

Which is supposed to stop their current command to stop them harvesting empty space, instead, it breaks.
I've pasted the call stack below, the first line is the one with the yellow arrow next to it when it breaks.

>   glestadv.exe!Glest::ProtoTypes::HarvestCommandType::update(Glest::Entities::Unit * unit=0x16f55478)  Line 935 + 0x3 bytes   C++
    glestadv.exe!Glest::Entities::Unit::doUpdateCommand()  Line 1310 + 0x42 bytes   C++
    glestadv.exe!Glest::Sim::SimulationInterface::doUpdateUnitCommand(Glest::Entities::Unit * unit=0x16f55478)  Line 422   C++
    glestadv.exe!Glest::Entities::Unit::doUpdate()  Line 1450   C++
    glestadv.exe!Glest::Sim::World::updateUnits(const Glest::Entities::Faction * f=0x15b9ffe0)  Line 279   C++
    glestadv.exe!Glest::Sim::World::processFrame()  Line 303 + 0x11 bytes   C++
    glestadv.exe!Glest::Sim::SimulationInterface::updateWorld()  Line 250   C++
    glestadv.exe!Glest::Gui::GameState::update()  Line 260 + 0xb bytes   C++
    glestadv.exe!Glest::Main::Program::loop()  Line 284 + 0x1b bytes   C++
    glestadv.exe!Glest::Main::glestMain(int argc=1, char * * argv=0x001228b8)  Line 190 + 0xb bytes   C++
    glestadv.exe!main(int argc=1, char * * argv=0x001228b8)  Line 225 + 0x10 bytes   C++
    glestadv.exe!__tmainCRTStartup()  Line 266 + 0x19 bytes   C
    glestadv.exe!mainCRTStartup()  Line 182   C

[Ildiz]

Ok so, I caved in and re-downloaded everything and followed the guide again.
Last time I downloaded it all, it was from the svn, this time it's from GIT.
Would this have made any difference?

The version I now have, works fine.
I'm going to play around with the code again and try to see if it breaks like last time with the same/similar changes, i'll try to trace the break as it were.

Watch this space.
Matt

[Ildiz]

I took the new version back to the same situation as the old version and there's no crash.
The only thing I can think of is I downloaded a broken version from the svn.

Problem seems to be fixed now, I just have to use the new version.

On another note:
How can I get this to work on an external HDD?
I'm currently using it on my desktop, and when I copy over the files to an external and try to build it on another PC, it tries to load the files from my desktop, something to do with CMake.

Is there a way to get this working on an external or something, because I need to hand in a working version of any code changes I make for my Thesis.

Cheers,
Matt

[John.d.h]

On another note:
How can I get this to work on an external HDD?
I'm currently using it on my desktop, and when I copy over the files to an external and try to build it on another PC, it tries to load the files from my desktop, something to do with CMake.

Here's what GAE's Linux compiling guide has to say:

Set configdir or datadir with '-DGAE_CONFIG_DIR=path -DGAE_DATA_DIR=path' as argument for cmake.

I know almost nothing about command line in Windows/DOS, so make of that what you will, but I think that if your external HDD is drive T, then you would be able to do something like:

Code: [Select]

cmake -DGAE_CONFIG_DIR=T:\GAE\config -DGAE_DATA_DIR=T:\GAE\data ..
http://sourceforge.net/apps/trac/glestae/wiki/CompileGuideLinux

[Yggdrasil]

The only thing I can think of is I downloaded a broken version from the svn.

svn is not used/updated anymore. Please only use git!

How can I get this to work on an external HDD?
I'm currently using it on my desktop, and when I copy over the files to an external and try to build it on another PC, it tries to load the files from my desktop, something to do with CMake.

The only problem i can think of is the cmake cache. Just generate a new project in a clean new build directory and you're always fine. Otherwise as John.d.h mentioned take a look at GAE_DATA_DIR and GAE_CONFIG_DIR in the cmake gui. Make sure you don't use absolute paths. Maybe also set GAE_CONFIG_DIR to have the configuration files on you external drive too.

Is there a way to get this working on an external or something, because I need to hand in a working version of any code changes I make for my Thesis.

Just package the source, no build directory. On linux that would be 'make package_source'. I can't remember how it's done on windows...

[hailstone]

When I submit assignments I like to make it as easy as possible for the markers. One time I got marked down because he didn't want (or didn't know how) to compile a library dependency that they required us to use. I even supplied the project files but didn't link it as a dependency in the same solution so it would say the library is missing if it wasn't compiled already.

There are other benefits to using relative paths. I would like to be able to copy the source and checkout a revision or branch without needing to do a full recompile. This is not possible if I need to generate the project files each time.

I tried setting windeps to relative path but any ENV{name} dependency comes out as absolute.

I think the best that can be done is to set all the paths as relative in CMake, generate, then change any remaining absolute paths in Visual Studio.

When running the exe from the data dir set GAE_DATA_DIR and GAE_CONFIG_DIR to '.'

Another solution might be to package with cmake and tell them to run a .bat file that generates the project files. Although if they have CMake installed and know how to use it then just get them to generate it themselves.

Edit: There's meant to be CMAKE options for relative paths but I couldn't get them working. (see http://www.ogre3d.org/forums/viewtopic.php?f=10&t=54399#p374726 )
Edit2: The options don't support the features we're using

[Yggdrasil]

There are other benefits to using relative paths. I would like to be able to copy the source and checkout a revision or branch without needing to do a full recompile. This is not possible if I need to generate the project files each time.

I can switch branches on linux and it just builds the needed stuff afterwards. Btw, if one header changes you needed to rebuild nearly everything anyway as it's included transitively everywhere. If one CMakeLists.txt was changed cmake detects it inside the VC project and regenerates it. I don't know if Visual Studio is able to use the old object files then.

The only real problem i see: If source files got added or deleted you have to manually regenerate with cmake because no CMakeLists.txt was touched as we search for source files and not list them explicitly.

I tried setting windeps to relative path but any ENV{name} dependency comes out as absolute.

Yeah, that's normal. windeps is just a hint for the "find" module to search there first. It sets the absolute path to the located library/header directory. We could set it directly instead of still searching for it like we're already doing for some dependencies because their find modules don't support hints.