Memory problems
Options
I'm using a custom heap implementation and have encountered a few problems, which I don't know how to deal with.
1) when using const char strings to create KeyObjects or ValueObjects I get an assert, that memory was allocated as array and deleted as a scalar or vice versa.
2) I get an error that a pointer that should be deleted isn't a valid heap pointer (_CrtisValidHeapPointer). The problem occurs when free is called in the Photon::Enetpeer::serializeToBuffer method (I only call the litePeer->service method). I've debugged all calls to malloc and new that happen during that method call and it looks a litte bit strange, because the pointer that should get freed with the free function isn't in the memory region that the malloc calls return. Instead it is exactly 32 byte after a memory position that is returned by the custom heap class. The allocation happens in Photon::EnetComman::serialize (92 byte in my case).
The question is, if this behavior is correct. It seems that memory allocated with new is deleted with free, which seems a little bit strange. Maybe important to know is, that the custom heap class only uses new and delete operators, so malloc and free work on another memory area.
1) when using const char strings to create KeyObjects or ValueObjects I get an assert, that memory was allocated as array and deleted as a scalar or vice versa.
ExitGames::Common::Hashtable parameters; parameters.put(1,"test");or
ExitGames::Common::KeyObject<ExitGames::Common::JString>* keyObject = new ExitGames::Common::KeyObject<ExitGames::Common::JString>("test");
delete keyObject;
2) I get an error that a pointer that should be deleted isn't a valid heap pointer (_CrtisValidHeapPointer). The problem occurs when free is called in the Photon::Enetpeer::serializeToBuffer method (I only call the litePeer->service method). I've debugged all calls to malloc and new that happen during that method call and it looks a litte bit strange, because the pointer that should get freed with the free function isn't in the memory region that the malloc calls return. Instead it is exactly 32 byte after a memory position that is returned by the custom heap class. The allocation happens in Photon::EnetComman::serialize (92 byte in my case).
The question is, if this behavior is correct. It seems that memory allocated with new is deleted with free, which seems a little bit strange. Maybe important to know is, that the custom heap class only uses new and delete operators, so malloc and free work on another memory area.
0
Comments
-
Hi MEX.
Yes, this looks indeed like a bug in Photons memory management, that has not come to attention with the default memory management, but only gets triggered, when using a custom implementation.
btw.: It's generally considered very bad style to override new and delete globally for exactly this reason: This way you are also affecting memory management of 3rd party code, which you may not be able to change and which may not be written in a way that is agnostic of the actual implementation of new and delete (although depending on a specific implementation of new and delete of course isn't exactly good style, either) or which may overrides them itself.
As fate would have it, we have just recently implemented a custom memory allocation implementation into the upcoming Photon C++ Client version 3.0.5.0.
This version has not yet been released, but we hope to be able to release it this month.
This release will most probably fix your issues.
Are you able to wait that long?
What platform(s) do you need the client for? Maybe we could check, if its possible to provide you with a prerelease.0
