Closed GoogleCodeExporter closed 9 years ago
Pretty sure this is because many objects are created but never destroyed.
I think this is mostly Units and Bullets.
Should probably store every created object in a vector that never gets
overwritten and delete them onGameEnd. (like a cumulative object array)
I'm going to create a map that illustrates the issue.
Original comment by AHeinerm
on 27 Nov 2010 at 3:46
I might be wrong, but I didn't see where those objects were destroyed.
Original comment by AHeinerm
on 27 Nov 2010 at 4:06
Yeah it must be something else, I've created and killed thousands of units but
there isn't much of a change.
Also when it mentions it has run out of memory, it's not referring to HD
storage, but RAM.
Original comment by AHeinerm
on 27 Nov 2010 at 5:52
Yeah it make perfect sence that it is a memory problem, because when I ran it
again I could see that StarCraft continued using more and more RAM and ended up
with using just over 400 MB, started with just over 100 MB. I just couldn't see
in the error message anything about memory other than storage, but I guess it
wouldn't have made the memory dump if it has been an error on my HD?
Hope you find a solution to what is not deleted correctly.
Original comment by twsandb...@gmail.com
on 28 Nov 2010 at 8:19
Attachments:
I forgot to say that I'm using the build in Reset method
BWAPI.bwapi.Broodwar.restartGame() in the onEnd event and just before the
restart I call Sleep(1000). I'm not sure if it is nessesary to sleep it, but I
saw you did that for the map GoliathsZerglings.scm on the forum:
http://www.broodwarai.com/forums/index.php?s=c80bc889964ef0bb501c3486c36c7063&sh
owtopic=815.
Bot my bot crashed, when using the map, so I just thought that is was easier to
just use the build-in restart game method, than find out the bug that made it
crash on the map.
Original comment by twsandb...@gmail.com
on 28 Nov 2010 at 8:32
No, a Sleep in the bot is not necessary, but is in the map so that the bot has
time to recognize that it has won/lost and perform any updates or calculations
using the remaining units, rather than having them immediately destroyed and
not having access to them anymore.
Original comment by AHeinerm
on 28 Nov 2010 at 4:00
I'm leaning towards some kind of client/server issue. My Broodwar isn't
exceeding 56 MB over the course of several games (using the restart() method as
well).
Original comment by AHeinerm
on 28 Nov 2010 at 4:48
Tried again and ran for much longer time than last time and crashed with the
use of 800+ MB RAM. Do you think the problem is in the BWAPI client/server or
between the Mono bridge and BWAPI?
Original comment by twsandb...@gmail.com
on 28 Nov 2010 at 6:43
This time I got this error file.
Original comment by twsandb...@gmail.com
on 28 Nov 2010 at 6:45
Attachments:
It's the same error, Storm allocating memory for the standard.SNP module. It's
accumulating memory in Starcraft, so the problem should be in BWAPI and/or any
loaded modules.
Original comment by AHeinerm
on 29 Nov 2010 at 2:38
I found and fix some memory leaks in r3299 and r3300. I don't know if this
fixed the bug completely or if there is still something else causing a memory
leak.
Original comment by lowerlo...@gmail.com
on 7 Dec 2010 at 11:25
Thats great but I can unfortunately not test it before there is a new version
of BWAPI and the bwapi-mono-bridge has been updated to match the version.
I don't know how to do all the SWIG thing that is needed to talk with BWAPI.
Original comment by twsandb...@gmail.com
on 8 Dec 2010 at 9:19
Developers:
mono-bridge: http://code.google.com/p/bwapi-mono-bridge/
Currently at 3.3, waiting for update to 3.4 to verify if this issue should
remain.
Original comment by AHeinerm
on 6 Jan 2011 at 12:39
If possible, can you simplify your bot, log the game count, and create a port
of the simplified bot to C++ so that we can identify if the problem is in BWAPI
or bwapi-mono-bridge (or both)?
Original comment by AHeinerm
on 6 Jan 2011 at 12:42
I have tried to run it using Mono command prompt instead of the standard
Windows command prompt. I haven't had any brake downs yet, after using Mono
CMD. I'm not sure if it is just a coincidence.
Original comment by twsandb...@gmail.com
on 7 Jan 2011 at 8:57
Unfortunately it was only a coincidence. I have now also had a crash using Mono
CMD
Original comment by twsandb...@gmail.com
on 9 Jan 2011 at 10:46
Hi, there. I am having the same problem in Windows XP.
I am training a Reinforcement learning for unit micro management (3vs3, 6vs6
scenarios)
Game count is different, 60,000 6v6, 100,000 for 3v3, 30,000 for 6v6.
The computer that I am wokring on has 2GB of Ram. Though I am using the version
before the final release until now.
This does not happen often in my own laptop, it has windows 7 and 3gb of ram
(probably becaause of more RAM)
My error points to another file though:
File: Starcrat\SWAR\lang\net_record.cpp.
Line:690
What I mainly use in my code are std vectors to store frame information, action
rewards and Q values for my algorithm. And I reset them after each round.
I will try to see if I can find anything suspicous.
Original comment by shantia....@gmail.com
on 11 Jan 2011 at 8:45
@shantia.amirhossein Do you also use bwapi-mono-bridge? Knowing the type of
module and any bwapi-related dependencies are most important. What version of
BWAPI are you referring to?
The error reports are useless for this issue. It also seems to be
OS-independant as well. This is definitely a Starcraft, BWAPI, or client/bridge
issue.
Original comment by AHeinerm
on 12 Jan 2011 at 3:40
No, I directly use the c++ version of BWAPI. I was using version 3.3, now I am
testing with 3.4. I will report the results. I found a leak in my program
already so I am testing again.
Original comment by shantia....@gmail.com
on 17 Jan 2011 at 1:49
ok I ran a small scenario with 2vs2 zealots and ran it for 30 seconds. It took
about 1 minute for the memory leak debugger to stop writing on output.
I am using
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
and putting _CrtDumpMemoryLeaks(); in the onEnd() function.
I am doing it in debug mode but it does not tell me any program lines.
I still can see some variable of my code here like:
{507782} normal block at 0x077982B8, 32 bytes long.
Data: <unit_grid_target> 75 6E 69 74 5F 67 72 69 64 5F 74 61 72 67 65 74
but I also see strange stuff like:
{507585} normal block at 0x04185310, 20 bytes long.
Data: < R S pS > B0 52 18 04 D0 53 18 04 70 53 18 04 03 00 00 00
or some more meaningful stuff like:
{507218} normal block at 0x077824E0, 32 bytes long.
Data: <UNIT_NOT_VISIBLE> 55 4E 49 54 5F 4E 4F 54 5F 56 49 53 49 42 4C 45
and
{507122} normal block at 0x07781970, 32 bytes long.
Data: <SUNKEN_COLONY_TE> 53 55 4E 4B 45 4E 5F 43 4F 4C 4F 4E 59 5F 54 45
I will try get rid of those lines from my code, but what are the other ones? Is
it because that the AImodule is a part of the Dll and maybe the function should
be called at somewhere else?
I am not very experienced with it so all suggestions are welcome.
Original comment by shantia....@gmail.com
on 17 Jan 2011 at 5:45
Correction:
unit_grid_target is not a variable, is a part of a string that I print using
sprintf_s function to initials my neural network (flann)
Original comment by shantia....@gmail.com
on 17 Jan 2011 at 6:14
The memory leak bug is still there. I have updated to BWAPI mono-bridge 3.4.
I ran a evolutionary algorithm and 600 games were played before StarCraft
crashed. (StarCraft has stopped working...)
StarCraft Memory use were: 60.816 K, my client AI 16.896 K.
My AI client was still running after StarCraft crashed. But there is no error
messages.
What version of the product are you using? On what operating system?
BWAPI 3.4Beta
bwapi-mono-bridge 3.4a
Windows 7 x64
Starcraft 1.16.1
Original comment by twsandb...@gmail.com
on 20 Jan 2011 at 10:47
Thanks for the responses.
I added the leak dumping in r3418 for BWAPI DEBUG mode, as well as fixed a
memory leak that probably isn't related to the issue.
I am also getting those "leaks" mentioned in Comment 20, most of them are
strings, but there are occasional data segments, and of course these ones won't
output the file either.
Maybe we should breakpoint when the memory usage starts to become insane and
iterate all memory blocks to see where exactly something is happening. Storm
allocations (inside Starcraft, and some used in BWAPI) will have a unique
header containing the file and line number, and if we can find out which header
appears the most then we've identified our leak. If there is no header then at
least we know the leak is not in Starcraft or any of its related modules.
I am going to try testing again to see if I can reproduce it and perform the
above.
Original comment by AHeinerm
on 21 Jan 2011 at 2:29
Just want to mention that I can reproduce the issue just fine.
Original comment by AHeinerm
on 21 Jan 2011 at 3:27
Figured it out. THIS IS A STARCRAFT ISSUE, so if you didn't use bwapi and just
sat in single player and went to "Restart Game" a few thousand times, you would
encounter this same error. The reason why this hasn't surfaced is because
nobody has played a few thousand games without exiting the game once (and
reported it).
I will verify these findings in a test that will log all SMem handles that
havn't been freed.
Once I've verified this and any other possible Starcraft leaks, a simple patch
in BWAPI will fix them.
Original comment by AHeinerm
on 21 Jan 2011 at 4:54
Oh yeah, the object I was referring to is located here:
0x004197B0 DlgGrp_Constructor
And more specifically (the repeated handles I noticed in the debugger), here:
0x004EE2D0 LoadRaceUI
Original comment by AHeinerm
on 21 Jan 2011 at 4:56
Using the hack I added, the memory leak is confirmed inside of Starcraft.
Starcraft\SWAR\lang\game.cpp:183 - dlgs\protoss.grp
.?AU_DLGGRP@@:-2 - dlgs\protoss.grp
Starcraft\SWAR\lang\game.cpp:183 - dlgs\protoss.grp
.?AU_DLGGRP@@:-2 - dlgs\protoss.grp
Starcraft\SWAR\lang\game.cpp:183 - dlgs\protoss.grp
.?AU_DLGGRP@@:-2 - dlgs\protoss.grp
...
These lines will repeat for the number of games.
Original comment by AHeinerm
on 21 Jan 2011 at 6:01
thx for the findings :)
We are desperately waiting for the patch :) If there is a way to somehow exit
the StarCraft and rerun it with chaos luncher via an external program
automatically, we can survive till the patch comes out.
Cheers,
Original comment by shantia....@gmail.com
on 21 Jan 2011 at 8:15
If it really is the memory leak that causes StarCraft to crash after a random
number of restarts. How can it be that there is much difference in how many
games restart that can be made before the game crashes.
This time I could run around 5500 games (last time around 600 games) before
StarCraft crashed. Ram consumption was 184,044 K at the crash this time.
Original comment by twsandb...@gmail.com
on 21 Jan 2011 at 2:36
Forgot to say that there was around 1 GB unused RAM left, when the game crashed
(78 % physical memory used).
Original comment by twsandb...@gmail.com
on 21 Jan 2011 at 2:39
For me it is not very different. Depending on the number of units I use in
scenario, it scales up and down. But my SC crashes usually around 1GB of memory
use. In a 6v6 scenario it is around 60,000 restarts (though I do the restarts
by calling the function inside my .cpp file and I am not using Auto_Restart
thingi).
Original comment by shantia....@gmail.com
on 21 Jan 2011 at 2:41
I also use the build in game restart from code in a 1vs1 SSC map, with 9
goliaths against 21 hydralisks. How many days do you spent on running 60,000
games. I think that I can only run about 10,000 games a day.
Original comment by twsandb...@gmail.com
on 21 Jan 2011 at 3:10
Well, a 6v6 scenario is quiet fast, the most thing that takes time is the
update of my neural network (I use FANN). But around 8 hours is enough for
60,000 games in a 6v6 scenario for marines or zealots.
Original comment by shantia....@gmail.com
on 21 Jan 2011 at 3:34
You can restart the game almost immediately after it starts to test the leak. A
full game does not need to be run. As for crashing with memory remaining, it
happens to me as well.
Original comment by AHeinerm
on 21 Jan 2011 at 4:07
Fixed in r3422.
I think it crashes sooner because it doesn't use upper bounds of memory
(highest is 0x7FFFFFFF).
Original comment by AHeinerm
on 21 Jan 2011 at 6:53
Also it seems to follow a very high block alignment rule. The allocation is
probably limited by Storm.
Original comment by AHeinerm
on 21 Jan 2011 at 6:54
Original comment by AHeinerm
on 21 Jan 2011 at 6:55
[deleted comment]
Thanks and Cheers
Original comment by shantia....@gmail.com
on 21 Jan 2011 at 8:47
I still use gui, turning it off does not change the results very much for
me, but I am not using the mono bridge, I used that once 1 year ago and it
was sooooo slow and incomplete back then. I also run in window mode. It is
quite fast indeed, with your units at least you should be able to do 20,000
runs in 8 hours.
Original comment by shantia....@gmail.com
on 21 Jan 2011 at 8:53
Original issue reported on code.google.com by
twsandb...@gmail.com
on 27 Nov 2010 at 8:12Attachments: