StackWalking

[Maarc]

Xuri asked me a question the other day with regards to debug vs release mode, and why sometimes things only happen in release mode that don't happen in debug. Ultimately, he was looking for something similar to a Call Stack for when users use it and crash.

At the time, I didn't think you could do much. But perhaps I've been proven wrong.

http://www.codeproject.com/threads/StackWalker.asp

I got that address today in an email from CodeProject. Amongst other things, it's claim to fame is being able to dump out a CallStack, validly, at *any* stage. It's late here and I don't have time, but a naive implementation could be as simple as wrapping most of the main() func in a try/catch block, and executing the StackWalker in the catch section.

Sure, it's not pretty, and it wouldn't solve anything, really.... but it may at least give us some way of being able to isolate where some of the user's problems are coming from.

Thoughts? Ideas? Suggestions?

Oh, I do realise this is a win32 thing only, I'm certainly not advocating it as a catch all. But it might help when working with those who do run on Windows and don't have a copy of VC.

[punt]

disclaimer:
Didn't follow the link


Is it windows or VS only? Will it support mingw?


At this point, one could just tear out all the linux code, getting it working on windows vs/mingw well, then analyze the changes needed.

At that point, one could take out such hacks such as this, for hopefully it wont be as needed (thus, not linux not a problem).

[lingo]

It windows debugged API, supply by dbghelp.dll. so should work for mingw.

I google and found something similar for linux

http://www.hpl.hp.com/research/linux/libunwind/

but callstack walking really should be used as last resort. I think test case should be implement first. I nominate cxxtest as our unit test module, any other suggestion?

[Xuri]

Anything that can give us ANY clues as to what will cause errors like the infamous "teleport crash error" which only a limited amount of users experience (but who in return experience it CONSTANTLY, without fail), has to be a good thing =)

[giwo]

I agree wholeheartedly.

Basically any issue that I can't reproduce (be it in debug or release) doesn't get fixed, as it stands. If we are lucky, these problems get solved unintentionally as work progresses, but even then it can be a long wait (far too long for many of our users).

We need to generate some method of reporting where a crash happened, even if it's not an entire callstack (though a callstack would be more helpful as most of our crashes actually happen deep within STL headers). This would provide the user with some tangible information when the program crashes, and us a place to start looking for wierdness if we can't reproduce it.

[lingo]

Yes, you guys are right, finding those few critical bugs should be high priority. So besides "teleport crash error", any other candidates for the callstack trace?

If this is deem a very high priority, I volunteer to write the code.

[Xuri]

Unless, I'm the only one not experiencing this one... here's another candidate viewtopic.php?t=568

[lingo]

Well stackwalking is more valuable than i realized. It can help us find out the incompatibility of the newer UO client.