Memory corruption rant.

[Jesse Phillips]

Vladimir Panteleev Wrote:

> On Wed, 18 May 2011 02:18:22 +0300, Jesse Phillips  
> <jessekphillips+D at gmail.com> wrote:
> 
> > [snip memory corruption rant]
> 
> I've nothing to contribute but by own anecdotal experience. So: are you  
> doing *any* allocations or throwing exceptions in finalizers (destructors  
> of objects on the heap)? If you are, don't do it. :P
> 
> -- 
> Best regards,
>   Vladimir                            mailto:vladimir at thecybershadow.net

Well I do use allocations to get values out of dll calls, but I didn't want to negotiate ownership so I duplicated everything it gave me and promptly freeing it through the free function it provides, and I ignore ownership of the values I give it (so I wouldn't be surprised if I had memory leaks, but it's not like the DLL will tell me when it is done with the memory)

As for the destructor thing, I'll have to check, I originally tried to use a reference counted struct and believe I may had thown something in a destructor there (think that one is safe?). But when I move to class I'm pretty sure I just gave up on cleaning up. I mean I'm done with it when I exit my program anyway.

And thing thing is that it is consistent. In that a build that fails will always fail and a build the succeeded always continues to function. So not only should it not be destroying anything yet, it really seems to be how the code is generated.

I actually had a print statement which printed some values of StopWatch, and I could consistently use that to get an access violation, and I just hoped I wouldn't have any more issues.

What does D do when it runs out of stack space? (Not that it is likely I am)