Posts: 372
Threads: 29
Joined: Mar 2011
Thanks: 1
Given 21 thank(s) in 18 post(s)
03-14-2012, 08:18 AM
(This post was last modified: 03-14-2012, 08:19 AM by ThuGie.)
Hey,
I added leakfinder and am running it now.
Its all fine really really slow but thats fine the server keep crashing loads of times :p.
Different places each time though but still ok.
As it reveals different kinds of problems but atm still unable to narrow down where it go's wrong any more tips on how to increase the chance i find the location where it actually go's wrong ?
Should i look somewhere else then the Call Stack window ?
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Are you using MS Application Verifier? That's a really useful thing, too. It can enable loads of debugging features built into Windows, one of them being guard pages around heap allocations. It might help you pinpoint the issues in your app.
Otherwise there's not much that can be said in general, most of the times you'll be hunting a specific issue and there is no generic recipe for that.
You should be using the stack window, the watches, memory window etc. Also with App verifier, it outputs its debugging info into the Output window, that comes in handy as well. When judging multithreaded code, remember to ask yourself, upon each line, "is there any way this could be accessed by another thread simultaneously? Will it cause problems if another thread modified this under my hands?" Forgetting to lock things using critical sections is one of the most common source of heap problems in multithreaded programs.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
03-15-2012, 05:40 PM
(This post was last modified: 03-15-2012, 05:41 PM by xoft.)
App Verifier is a free standalone package from MS, but they bundle it with most of their dev software. I think it comes with Platform SDK as well as the Debugging Tools. Still, it's available as a standalone download if you want to be sure you have the latest version.
App verifier is only useful in combination with a debugger, because it triggers a breakpoint whenever it feels you're doing something wrong (such as freeing memory with an undeleted critical section in it); you need to be running under a debugger to catch that.
Settings: keep the default for the start. You'll see how many problems you hit.
You still need to add your exe to the list of applications for the verified to work on it.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
You need to run the program under a debugger in order to be able to catch the verifier output.
Then when the verifier throws an exception, use the debugger to view stack trace. Of course the first few items will be from verifier (it had to throw the exception somehow), but then it'll be your app's code doing the mischief.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Do you have VS configured to download symbol files from MS servers? You might need to, otherwise the stack can be mis-interpreted by VS, therefore not showing any of your code.