Compiles but locks up when generating chunks
#1
I opened up the sln in VC2012 and compiled it. Seemed to be all right but when I join the server, I get something about going over 1GB of ram, it dumps mem, and i always close it before it finishes dumping mem because it takes a long time.

Heres the log:
Code:
[16b0|17:30:42] --- Started Log ---
[16b0|17:30:42] Creating new server instance...
[16b0|17:30:42] Reading server config...
[16b0|17:30:42] Starting server...
[16b0|17:30:42] Starting up server.
[16b0|17:30:42] Compatible clients: 1.2.4, 1.2.5, 1.3.1, 1.3.2, 1.4.2, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.5, 1.5.1, 1.5.2
[16b0|17:30:42] Compatible protocol versions 29, 39, 47, 49, 51, 60, 61
[16b0|17:30:42] IPv4: Port 25566 is open for connections
[16b0|17:30:42] IPv6: Port 25566 is open for connections
[16b0|17:30:42] Generating protocol encryption keypair...
[16b0|17:30:42] Creating WebAdmin...
[16b0|17:30:42] Starting WebAdmin on port 8080
[16b0|17:30:42] Loading settings...
[16b0|17:30:42] -- Loading Groups --
[16b0|17:30:42] Loading group: Admins
[16b0|17:30:42] Permission: *
[16b0|17:30:42] Loading group: Mods
[16b0|17:30:42] Permission: core.time
[16b0|17:30:42] Permission: core.item
[16b0|17:30:42] Loading group: Vips
[16b0|17:30:42] Permission: core.teleport
[16b0|17:30:42] Loading group: Default
[16b0|17:30:42] Permission: core.build
[16b0|17:30:42] Permission: core.help
[16b0|17:30:42] Permission: core.playerlist
[16b0|17:30:42] Permission: core.pluginlist
[16b0|17:30:42] Permission: core.spawn
[16b0|17:30:42] -- Done Loading Groups --
[16b0|17:30:42] -- Loading crafting recipes from crafting.txt --
[16b0|17:30:43] -- 224 crafting recipes loaded from crafting.txt --
[16b0|17:30:43] -- Loading furnace recipes --
[16b0|17:30:43] ERROR: FurnaceRecipe, syntax error
[16b0|17:30:43] Got 13 furnace recipes, and 13 fuels.
[16b0|17:30:43] Loading worlds...
[16b0|17:30:43] cWorld::cWorld(world)
[16b0|17:30:43] Using a cache for biomegen of size 64.
[16b0|17:30:43] Using a cache for Heightgen of size 64.
[16b0|17:30:43] world/world.ini [Physics]:WaterSimulator not present or empty, using the default of "Floody".
[16b0|17:30:43] world/world.ini [Physics]:LavaSimulator not present or empty, using the default of "Floody".
[16b0|17:30:43] Loading plugin manager...
[16b0|17:30:43] Loading plugins
[16b0|17:30:43] Initialized Core v.12
[16b0|17:30:43] Initialized ChatLog v.3
[16b0|17:30:43] Loaded 9 plugin(s)
[16b0|17:30:43] Loading MonsterConfig...
[16b0|17:30:43] Starting Authenticator...
[16b0|17:30:43] Starting worlds...
[16b0|17:30:43] Preparing spawn area in world "world"...
[110c|17:30:43] 73 chunks to load, 0 chunks to generate
[1544|17:30:44] Initializing entity #1 (cPickup) at {341.50, 65.00, -303.43}
[1544|17:30:44] Initializing entity #2 (cPickup) at {361.50, 48.00, -355.50}
[16b0|17:30:44] Lighting spawn area in world "world"...
[14a0|17:30:44] 10 chunks remaining to light
[16b0|17:30:44] Starting server...
[1120|17:30:44] ServerTickThread
[16b0|17:30:44] Starting InputThread...
[16b0|17:30:44] Initialization done, server running now.
[0dc0|17:31:17] Client "192.168.1.104" connected!
[0dc0|17:31:17] New ClientHandle created at 0E77B410
[0dc0|17:31:17] Creating a new cSocketThread (currently have 0)
[17bc|17:31:18] LOGIN Stephen304
[1694|17:31:18] Got 200 OK :D
[1694|17:31:18] Got result: YES
[1694|17:31:18] Result was "YES", so player is authenticated!
[1694|17:31:18] Created a player object for "Stephen304" @ "192.168.1.104" at 0EA10028, ID 3
[1694|17:31:18] Added Stephen304 to group Admins
[1694|17:31:18] Player Stephen304 has permissions:
[1694|17:31:18] *
[1694|17:31:18] Player "Stephen304" was read from file, spawning at {-391.27, 63.00, -298.70} in world "world"
[1694|17:31:18] Initializing entity #3 (cPlayer) at {-391.27, 63.00, -298.70}
[1694|17:31:18] Streaming chunks centered on [-25, -19], view distance 9
[1694|17:31:18] cChunk: Entity #3 (cPlayer) at [-25, 0, -19] spawning for player "Stephen304"
[0d58|17:31:18] Generating chunk [-24, 0, -21]
[0d58|17:31:20] Generating chunk [-25, 0, -21]
[0d58|17:31:20] BioGenCache: 1 hits, 9 misses, saved 10.00 %
[0d58|17:31:20] BioGenCache: Avg cache chain length: 6.00
[0d58|17:31:20] CompoGenCache: 1 hits, 9 misses, saved 10.00 %
[0d58|17:31:20] CompoGenCache: Avg cache chain length: 6.00
[0d58|17:31:20] Generating chunk [-26, 0, -21]
[0d58|17:31:20] Generating chunk [-23, 0, -17]
[0d58|17:31:21] Generating chunk [-27, 0, -17]
[0d58|17:31:21] Generating chunk [-26, 0, -17]
[0d58|17:31:21] Generating chunk [-25, 0, -17]
[0d58|17:31:21] Generating chunk [-24, 0, -17]
[0d58|17:31:21] Generating chunk [-22, 0, -22]
[0d58|17:31:21] Generating chunk [-28, 0, -22]
[0d58|17:31:21] Generating chunk [-22, 0, -21]
[0d58|17:31:21] Generating chunk [-28, 0, -21]
[0d58|17:31:21] Generating chunk [-22, 0, -20]
[0d58|17:31:21] Generating chunk [-28, 0, -20]
[0d58|17:31:21] Generating chunk [-22, 0, -19]
[0d58|17:31:22] Generating chunk [-28, 0, -19]
[0d58|17:31:22] Generating chunk [-22, 0, -18]
[0d58|17:31:22] Chunk generator performance: 4.82 ch/s (17 ch total)
[0d58|17:31:22] Generating chunk [-28, 0, -18]
[0d58|17:31:22] Generating chunk [-22, 0, -17]
[0d58|17:31:22] Generating chunk [-28, 0, -17]
[0d58|17:31:22] Generating chunk [-22, 0, -16]
[0d58|17:31:22] Generating chunk [-28, 0, -16]
[0d58|17:31:22] Generating chunk [-27, 0, -16]
[0d58|17:31:22] Generating chunk [-27, 0, -22]
[0d58|17:31:22] Generating chunk [-26, 0, -16]
[0d58|17:31:22] Generating chunk [-26, 0, -22]

Any ideas? Was there some compile setup i missed?

WAIT NEVERMIND I GOT IT ISSUE SOLVED.

I built in debug mode or whatever, selecting release and rebuilding produced an executable that worked perfectly :3
Reply
Thanks given by:
#2
There is a problem between VS2012's debug mode and our memory leak finder. The VC2012 runtime allocates way too many memory blocks in std::vector constructors. This causes the chunk generator and generally the chunkmap to be very slow - as you can see from your performance stats, not even 5 chunks per second generated, while on a regular machine we get as many as 40 chunks per second generated in the debug mode.

For this reason, and a few others, we use VS2008 for the development. That also means that you can't commit the changes in the project file. Therefore, I recommend you also get MSVC 2008, the Express version should still be available as a free download from MS.

I have added a link to the VC2008 Express iso image to the wiki. It seems this piece of software is rather difficult to procure nowadays Sad
http://download.microsoft.com/download/E...504728.iso
Reply
Thanks given by:
#3
Can't I just not use debug mode then? Everything works fine in release mode.

I'll just download it from Dreamspark.
Reply
Thanks given by:
#4
You're losing a lot of valuable stuff in release mode - all the asserts, all the debugging logging, a memory leak finder...

The server works, but the problem is when it doesn't work because you changed something, and you need to find out why. Then the release mode is really tough. Smile
Reply
Thanks given by:
#5
(06-21-2013, 01:21 AM)xoft Wrote: You're losing a lot of valuable stuff in release mode - all the asserts, all the debugging logging, a memory leak finder...

The server works, but the problem is when it doesn't work because you changed something, and you need to find out why. Then the release mode is really tough. Smile

Hmmm, well really I'm never used to any debug mode, I just try things and go over what I did if it doesn't work. The closest I really get is probably firebug for html/css and adding console logs in php.
Reply
Thanks given by:
#6
Yeah, well, web technologies don't support much debugging as such. C++ is different in this way.

You can have (and are advised to have) asserts - those are conditions that you *believe* should be true, but just in case, you test them. Because such tests can be costly, you don't want them in the release version, so they're compiled in only in the debug version. If such an assert fails for some reason, the debugger will show you exactly what went wrong.
For an example of this, have a look at the cChunkDef::GetBlock(). It checks if all three coords are valid. But you don't want this check in the release, because you *know* the code doesn't pass invalid coords. This particular assert is actually quite useful, it bites me personaly a few times a month, when I code something and forget to convert between relative and absolute coords, or something similar.

Debugging logging is useful for having a sneak peak at some values or at what codepaths are taken while the game is running, without actually going through the debugger. Usually if you set a breakpoint and step through the debugger, the client will disconnect shortly because of a timeout. Logging allows you to see stuff without that. Also, logging is written to a file, so you have a reference even after the program terminates.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)