But I am using almost the same code
Can you try running this inside EE app instead of a separate project?

Just replace this post's code with your own thread calls
http://www.esenthel.com/community/showth...3#pid42393

The threading code is not the problem, something in the engine must be. Something that's related to this it seems. Maybe the keyword is the "almost" here?

No, I can't do this easily in EE. Some header file issues that I don't have the time to sort out. However, if you can provide me a working example in EE2, I'll gladly run it for you.

For now please test this version, it's your class used in EE environment.

I can reproduce the leak with this. We now have the clear comparison that it works outside of EE but not in an EE app. So the question now is what the engine is doing that we don't see. I would help you find it, but I can't look into the engine code.

The leak is generated by thread creation in the project, that's not done by the engine, but by the codes in the project. So you don't really need the engine code for that.
What I would recommend, is to perhaps press F8 to launch the project in VS.
And try changing project settings? For example libraries used, etc.
Perhaps this issue occurs only when using certain libraries, like libcmt.lib, etc.
Also, did you try to update your:
1) bios
2) all windows updates
3) try reinstalling all VS redistributables (2008/2010/2012)
4) try compiling under different VS versions (2008/2010/2012)
5) try using different libraries/project settings

Greg, this is a fresh install and fully up to date. And I have already proven, that the thread creation itself is not causing any leaks when run outside of EE.
It could very well be that creating these threads (which is not advisable anyway) is just triggering some other memory related behavior. I have seen weirder things than this.

I tried to experiment with a few project settings, disabled a few optimizations, removed a few unnecessary libraries, also removed the libcmt libs and disabled "Disable all default" libraries. But no change.

I also tried an external leak detection software that I used in the past (DeLeaker), but it caused some exceptions with the app. Maybe DeLeaker is not up to date enough.

Can other users with AMD CPU's please also run this EE2 project that Greg posted here: http://www.esenthel.com/community/showth...2#pid42432
Just extract the archive inside your projects folder. Then watch the apps memory while running. Make sure that the app has focus.
Zervox already reported that it happened for him as well, but maybe it was a misunderstanding.

I have intel i5 and the memory never goes up except when working on the world editor
I hope to see your problem fixed as soon as possible

Greg, I've investigated the leaks further and ran another memory debugger over the EE app with quite a few results. I sent you the results to your email. Did you have a chance yet to take a look at them?

Hi, yes, but unfortunately it's not helpful at all.
Can anyone with AMD cpu test the 2.0 app from this post http://www.esenthel.com/community/showth...2#pid42432 and observe if they have growing memory usage over time?

ok i tested it about 10-15 min (edit: 45 min now) and did not notice any big change, it ran very constantly.
windows 7, 12 gb ddr3, amd athlon x4 3ghz


by the way, i noticed is that glow maps not always work, sometimes it crashes... i will try to reproduce

another point me and some teammates noticed, that after some while working in the editor in collaborative mode, the terrain get some ugly stripes which is very much work to remove by smoothing out

it should be very important to have a ressource list used by a world map since sometimes esenthel spit outs some error for a missing file, which has been removed in editor before.

another thing which stops my progress is that some code working on my mac build does not compile on a windows machine and vice versa... this frightend me a bit

last an auto update function for dedicated servers would be great and a function like "backup all projects on dedicated server" to pack all into an archive

im using visual c++ 2010 express
maybe you want to logon our server and test it yourself, just pm me

no growing memory except if D.sync is false it will start a bit higher and jump a bit in memory usage but it doesn't grow it will jump between maybe 8 different amounts of memory(talking less than half a meg memory jump from min to max) but it doesn't increase over time.

Greg, I'm sure this won't be easy to find. So as a compromise and quick solution why don't you change the code in the editor to not recreate threads in each frame but only once at the beginning and then re-using these threads each frame? This would be much more efficient anyway. Who knows who else might have problems with this and is not speaking up or silently uninstalls the product.

Hi,
Next version will have this improvement.
I've made so the threads are created at start and used only when needed.
However this was not changed for the entire editor, but for just some places, hopefully it should be enough.