search

sharpdx / SharpDX

SharpDX GitHub Repository
http://sharpdx.org
MIT License
1.7k stars 638 forks source link

No memory leak warnings in v4.0.1? #913

Closed jclin closed 7 years ago

jclin commented 7 years ago

Hello,

Configuration.EnableObjectTracking = true doesn't seem to print memory leak warnings in Debug output, while a CI build that does. Is there something simple that I'm missing?

xoofx commented 7 years ago

I don't remember of any changes for 4.x related to this...

jclin commented 7 years ago

Strange, I get mem leak warnings when using the 4.0.0 release (after manually signing the assemblies), but not with the 4.0.1 release. I don't see how, but is it plausible that it's somehow related to the strong naming issue from earlier this week?

kburgoyne commented 7 years ago

#911 said something about 4.0.0 having Debug builds in it. That was fixed in 4.0.1. Might be related.

jclin commented 7 years ago

@kburgoyne Thanks, that makes sense. If the nuget packages are using the Release builds then the mem leak warning isn't going to be output to a (Debug) client's app's debug output window.

kburgoyne commented 7 years ago

@jclin Just wondering... do you know that messages from Release DLLs are not output to a Debug EXEs output window, or are you just assuming that might be true? I'm actually asking for my own education since I've never pondered that situation and it certainly seems like something to be kept in mind during future debugging of anything.

xoofx commented 7 years ago

@kburgoyne the code that outputs the leak is in ComObject.Dispose which is using Debug.WriteLine which unfortunately gets stripped out when compiling in release mode. In the past, this code was using Console.WriteLine, but many platforms were not supporting this...

That being said, we could add a static field ComObject.LogLeak of type Func<string> what would be initialized by default to a Debug.WriteLine, but you could overwrite it with our own Debug.WriteLine from your own assembly (so that it would keep it if you compile your own assembly in debug). PR Welcome.

jclin commented 7 years ago

@xoofx Sounds good, PR will hopefully be up later today.

kburgoyne commented 7 years ago

@xoofx Thanks.

Yes, as per MSDN Debug.WriteLine() is tagged [Conditional]. Never paid attention to that in the past. This has been educational...

MSDN: "By default, the output is written to an instance of DefaultTraceListener."

DefaultTraceListener.WriteLine() is NOT tagged [Conditional]. So perhaps with code that has a run-time flag to enable/disable diagnostic output to the Output window (code which might want to still work when runtime enabled even on a Release build), using DefaultTraceListener "might" be an approach. Not sure if DefaultTraceListener has any special considerations which Debug is taking care of.

Definitely something I shall have to keep in mind for possible consideration in various scenarios.

I'm a complete newbie when it comes to much of this Git stuff and things like PRs, so I've been hesitant to offer to make changes like this. If you know of a good learning site that is good at explaining the philosophy of what a person is doing when performing Git operations, I'd appreciate the reference. Particularly in a distributed team environment. Without the philosophy as a foundation, the details won't stick well with me.