[nfbcs] locating hard to find memory leaks

[Bryan Duarte]

Hello Tyler,

Although I have never messed with a mud engine before I have done work with serializing data for embedded systems. The first question I would ask you is what data structure are you using in C++ when storing the room objects? If it is a vector the way you are adding objects to the grid or list so to speak makes a difference in how C++ allocates memory to the vector. A vector allocates memory based on a memory alloc function automatically if one is not specified when it is initialized. Everything will run fine until that size is exceeded. Once the size is exceeded all elements are moved to another memory block and the size is reallocated automatically based on the STDLIB function. I am not sure about how this function allocates memory but for other data structures in java there is a default size, then when it grows it takes that number and basically doubles it. By the time you are done you could have resized two or three times and your structure could be very large even if it is not using all of the allocated memory. If you are able I would keep track of every object you are storing in the list, check the size, then use the "resize" function to attempt to get rid of any unused memory being allocated.  

Another thing I will suggest is looking into the JSON libraries for C++. JSON is a light weight easy to use method for serializing and deserializing information. You can create objects, make calls, and it is serializable with a simple function call. When developing distributed applications between an embedded system acting as a server such as a Raspberry PI, JSON is very easy to use and allows for data to be handled even on a small memory device such as the PI. 



Go Devils!

Bryan Duarte
Software Engineering Graduate student
ASU Fulton Engineering College
QwikEyes CEO

> On Oct 20, 2015, at 8:46 AM, Littlefield, Tyler via nfbcs <nfbcs at nfbnet.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,
> I am working on my mud engine:
> http://github.com/sorressean/aspen
> There appears to be a really weird issue when
> serializing/deserializing a lot of data. When the data is loaded, I
> end up increasing my memory to hold a 250x250 grid of rooms and exits
> from 100 KB to around 500 MB. I'm using TinyXML for this.
> Does anyone have any ideas in terms of how to track this down? Running
> valgrind doesn't seem to produce any results. This shouldn't be using
> this much memory at all--the objects are compact, which you can
> understand if you can hold 65000 rooms plus exits in memory. Any tips
> here would be awesome. Also if you're interested in a run, I provided
> a world generated grid here:
> https://dl.dropboxusercontent.com/u/10204868/wilderness.tgz
> to use after you clone aspen:
> mkdir -p aspen/data/areas
> put the extracted wilderness file there and run.
> Any tips/advice would be greatly appreciated.
> Thanks,
> - -- 
> Take care,
> Ty
> twitter: @sorressean
> web:http://tysdomain.com
> pubkey: http://tysdomain.com/files/pubkey.asc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJWJmG+AAoJEAdP60+BYxejZt4H/0wXby2sRfzG/MbssA52K3I7
> YKFxLfKGwgdPOG0ADrME2rv19z/lIWEPewI7uwYuQiQZydVsF4FAOQeghj4vnqjZ
> V7xMADTatlvmM3cznpmsg+JAtIW3XYhZq62halnTA15XVJFna5wDtLr6BZbQdGhC
> R84QYqQi6JmyM1idQQS9Q9k47xGGVkT9v8GR2pkzbnCemy8QhqTdoTAUbvFg4l/U
> CRr1PCbt31lsgCir8dqPzH6gx/+ujn812WCOhXJTTm93gTF5uUVR8x6wYeBz0w1g
> c9OyhmmMVa1LhwdoGHl7nOoJa/OIldaNl/8psAc1AQ5kIP+aKgJUDsiYWUtdQ3U=
> =kDiq
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/bjduarte%40asu.edu