Mike Hearn a écrit :
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.
well, in that case the mini-dumps are the way to go (even if they don't have the pre-defined semantics for system wide thread information, but they do have what you need). This will embed more details that what you've done (OS version, loaded modules...)
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.
agreed on a user friendliness of the operation. My idea with mini-dump is that we could use this vector to get back information from any user after any problematic operation: - a crash - an app hanging up...
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.
I was thinking of (for your example, even if I still don't like the idea) of: - adding a new command to winedbg (say 'bt *' to get what you described) - add a new option to winedbg, which is run the command passed in parameter. so, the command line would be winedbg -e 'bt *' (we could this way have better flexibility if needed). I was not talking about asking the user to do 'info proc' at the winedbg prompt followed by a bt <tid> for each known thread id
A+