Weird Bug - Removing Unused Variable Causes Memory Leak?!?
Weird Bug - Removing Unused Variable Causes Memory Leak?!?
This video shows a strange bug I've encountered. When I remove an unused variable from my application it throws a memory leak. When I add it back, the memory leak goes away. The variable is not accessed at all by the application. Anyone have any advice? Thanks!
http://screencast.com/t/m2H8GLn7NBN2
This video shows a strange bug I've encountered. When I remove an unused variable from my application it throws a memory leak. When I add it back, the memory leak goes away. The variable is not accessed at all by the application. Anyone have any advice? Thanks!
http://screencast.com/t/m2H8GLn7NBN2
You are probably shifting your EXE's memory footprint in memory by a few bytes by adding/removing the variable. This can "re map" other uninitialized variables in your app to contain unreasonable random values - or reasonable ones. You need to backtrack on the leaks to find out where/why they were allocated and the root cause - probably a flag value in an uninitialized variable triggered it.
ReplyDeleteKevin McCoy Thanks for the input. I didn't think this was possible. I have range checking on etc so I would have thought the debugger would have caught it. I'll get my "fine-tooth-comb" out and get to work - thanks again.
ReplyDeleteDude, fix these hints and warnings. It hurts seeing them ;) Not saying it will fix this particular problem but often I have seen problems go away or finding them because you pay attention to these messages.
ReplyDeleteBtw it still does not beat the strangest bug I have encountered so far: removing a few lines of comments resulted in an access violation. Adding that comment back removed it - true story.
Steve Maughan Range checking will not detect a "reasonable" random value in an uninitialized variable.
ReplyDeleteAlso, Range checking only comes into play when you try to assign a value to a variable with code. In this case the variable is just inheriting random memory junk so there is no actual assignment.
Removing that variable shifted all of your class variables by one byte. There is a clue :-)
Kevin McCoy By 8 byte in case of 64bit. Fields are aligned and the class is not packed.
ReplyDeleteStefan Glienke Did he mention bittedness? I must have missed it.
ReplyDeleteKevin McCoy I think he did but it doesn't matter since on 32bit it still would be 4 byte because fields are also aligned.
ReplyDeleteFixed! It turned out to be a incorrect typecast. I had previously descended TWorldLayer from TStaticLayer. After deciding this complicated things, I descended TWorldLayer from TObject but there was still one typecast which was effectively overwriting memory. Thanks for your advice!
ReplyDeleteStefan Glienke point taken about the hints and warnings. But what do you do with warning such as:
ReplyDelete"[dcc32 Warning] smFiles.pas(242): W1002 Symbol 'IncludeTrailingBackslash' is specific to a platform"
I know it's platform specific but I'm still going to use it. Is there a way to suppress specific types of warnings?
use IncludeTrailingPathDelimiter.
ReplyDeleteAbout hints and warnings (although I strongly recommend fixing the code that causes them and only disable them as a last resort): http://stackoverflow.com/questions/631902/how-do-i-turn-specific-delphi-warnings-and-hints-off
And about the type casting: better use:
if obj is TSomeThing then TSomeThing(obj)
or
obj as TSomeThing
depending on the situation. The first does not cause an error and you should handle if its not true and the second will blow an exception into your face instead of silently corrupting your memory.
Stefan Glienke Many thanks!
ReplyDeleteSteve Maughan concerning the path delimiter, you should start using the TPath class from IOUtils. This problem could occur when combining parts of a path. There is TPath.Combine ()
ReplyDeleteOliver Funcke Thanks - I'll take a look (I love all of this advice!)
ReplyDelete