Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Making use of backtrace?

Name: Anonymous 2010-09-01 6:00

Incoming wall of text.

I want to be able to make use of the backtrace function in order to ease debugging when my application crashes for a user. I found an implementation which seems to work on MinGW, so on the target platforms I can pretty much use SEH or signals to catch a crash, get a backtrace and do something with it (I also realize that sometimes, I won't be able to do anything good in the handler due to the state of the application. I'm willing to take that risk.)

The problem is, I don't know where to begin. I of course need the debugging information to be on a server of sorts, but I'm not even sure what I should do to get this information. How do I generate it? I know gdb can determine what line of code an address is, and I'm guessing gdb is using embedded debug info - but I can't find any reasonable sources of information for the format or how I could do this without the information embedded (although I have a feeling i could just extract and strip, it sounds redundant to me.) I'm also not sure how, using signals, I would get the backtrace, since I'm pretty sure signal handlers get a different thread. (But hell if I know. I've never actually done one.)

I saw Google Breakpad, but this is an awful solution. I checked everything out from source and it seems it doesn't really work on Windows without hacking around, and definitely not with MinGW. It might be useful for reference, but i don't think it is actually helpful in my case. Too many dependencies, not enough docs, no MinGW support... not worth it.

Any advice? I'm new here, but I'm hoping unlike /g/ people here actually know their stuff. I'm primarily concerned with MinGW right now, since I bet this will be much simpler under Linux and etc.

Name: Anonymous 2010-09-01 20:48

>>33
Well, If you already have good and solid codebases, there's no reason to move, however if you're writing something out yourself, you should experiment with less common approaches, especially if it can save you development time, make maintenance easier and if done right, give you decent performance. I'm not saying performance is easier to achieve in high-level languages - it's harder than in C, you actually have to work for it, but if you know what you're doing, you can make the right tradeoffs and achieve comparable performance with less effort. Of course, doing so require intimate knowledge of a lot of things (multiple languages, the computer architecture, the OS' platform, general compsci(at least the ability to estimate your algorithms runtime/memory requirements and how it can be improved) and so on).

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List