Follow @RoyOsherove on Twitter

An interesting Memory Leak problem.

Udi is having a hard time figuring out a nasty weird memory leak problem. I have no idea what the answer is, but I'm sure one of you smart people out there could chime in. I'd love to see what the answer to this problem is.
so - here's an exerpt that explains when the memory leak occurs and the explanation that is currenly suggested:
After asking around a bit, nobody could give me an explanation. Eventually, one of my programmers gave somebody a call, and he had an explanation. Now, this person could speak only Russian, so what I'm saying here comes via a second hand translation by my programmer (I don't speak any Russian). The reason he gave for this happening was that DLL's have a heap which is separate from that of the EXE, and that although structs are value types, they still have heap representation - they are objects that behave like primitives. Now, in cases when the thread is created within code from the DLL, automatic cleanup of memory allocated on the heap doesn't occur when using structs. When the thread is created within code from the EXE, the memory is automatically cleaned up.

I had a hard time believing this, to say the least, but I couldn't find any other explanation. After checking it up a bit, and talking to some more people, I was still left high and dry. Everywhere I looked (and heard), there was no justification to his claim. However, by that exact same information, my problem shouldn't have been occurring.

So, like I said before, the solution is to have the code that creates the threads on the EXE. If anyone can tell me why, I'd truly appreciate it - especially if you can find documentation supporting it :)

Introducing: NUnitX and the Rollback attribute - Seamless database rollback with Nunit

Microsoft is losing the community battle - against itself