On Fri, 2004-06-11 at 20:55 +0200, Eric Pouech wrote:
I'm not sure I understand the purpose of the --backtrace-all.
When a user says "I pressed this button and the app hung" it's convenient to have *somewhere* to start from - this is another attack vector.
There's no way you can ensure a complete synchro between all threads & processes to get a global picture of the whole system
Yes, I know that, but it doesn't have to be precise. For the situations I'm thinking of most of the (interesting) threads will be blocked waiting for an event or deadlocked on a critical section anyway. It's common enough to have some automatic *easy* command we can give to a non-technical user.
At the moment you have to teach them how to start winedbg, walk the process list, attach to it, walk the threads list, get a backtrace for each thread etc if you decide you want to see some backtraces. This is (a) complicated and (b) some non-technical users can't do it, it's too many steps.
This way we can reduce it to: Please run "winedbg --backtrace-all >log" when the app hangs, and send us the "log" file.
, so the option is likely not very useful (except for the threads which are in a wait operation), but you will miss some other information for that (ie an event (entering/leaving CS...) tracker tool would be better).
It's just somewhere to start from, rather than a cutting edge debugging tool :)
More over, I don't like either adding options to winedbg. So, I'd prefer adding an option to actually process the commands from a file (or even a string from command line) would be better.
Well, as I said the reason I'd like this is because it's super easy. Processing commands from the command line would be nice but that's not something you can put in an email or on IRC to a confused user. They'll just get it wrong, and you still need to know PIDs and TIDs and such. This is easier for them.
And, finally, you leak the handle for the snapshot.
Oops! I'll send a fixed version.
thanks -mike