[Byte™]

Honestly, I've been slacking off in the debugging department just fooling around with learning a new feature in the language then I hope to the next feature. But I've been wanting to push some real software and want to create a backtrace when software crashes than have it auto send via upload on my server. I heard MSVC has a PDB / minidump (as said I've heard about them so I don't know much about them) that you can load back into Visual Studio and it loads the stack/variable values etc, pretty much a visualization of what happened when it crashed. So how would I go about doing this in Linux?

Here are my questions

• What exactly is inside of a stack trace? And what does it all mean? (Stacktrace provided below) (I've learned a bit about the stack frames, and it contains the function address)
  


• I've seen backtrace examples that contain information like this:
  
  Code

  $ ./test
Error: signal 11:
./test(handler+0x19)[0x400911]
/lib64/tls/libc.so.6[0x3a9b92e380]
./test(baz+0x14)[0x400962]
./test(bar+0xe)[0x400983]
./test(foo+0xe)[0x400993]
./test(main+0x28)[0x4009bd]
/lib64/tls/libc.so.6(__libc_start_main+0xdb)[0x3a9b91c4bb]
./test[0x40086a]


• But if this just contains the function address, how would I be able to load the variables the user had at the point of the crash
  
  


• Am I thinking about stack traces all wrong? Is it just about learning what function the program crashed in? Or is it about dumping the memory and able to step through it.  (Able to read Variables in GDB, step through, figure out what is being called next, etc)
  

Honestly, I may have this idea of what stack tracing is able to do completely wrong as I don't know at all what it does but if you are willing to take the time to set me straight and how its all done correctly, I am ready to listen.

Thank you for your time. (Btw if you write an essay-sized response, I will definitely read it as I am super interested in this type of stuff)

[Auriana]

When an application crashes in a debugger a list of stack frames are generated leading up to the crash. It not only shows memory allocated locally but the heap as well. Because you're viewing the stack, all local variables are on the stack itself. Each stack frame contains a base pointer and a stack pointer. As the stack pointer increases in memory, data above it becomes overwritten. When the stack pointer goes down in memory, data above it becomes redundant and ready to be overwritten. The top of the stack trace would show the last function to be called and as you go down each return address would indicate the caller.

In the example you posted, main would be the most relevant caller in your stack trace at the bottom of the stack. Above main, foo was called next, then bar, then baz. Viewing the local variable values themselves would depend on which debugger you're using. I believe in WinDBG you can access a specific thread in a stack dump and view local variable values. Of course the names will probably be stripped, and instead you will see something like:

Code

mov [esp-8],FirstValue
mov [esp-4],Second value

Or relative to EBP if move ebp,esp instruction was executed.

And arguments would be accessed through ESP/EBP+

Here's a GDB reference you can look at.
sourceware.org/gdb/onlinedocs/gdb/Backtrace.html