Making use of backtrace?

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.

Last time I checked, the sources for gdb were freely available for study at any given time.

>>2
Okay, you got me there. I never even thought of that, and I bet it will help a lot.

However, I still do have concerns about external vs embedded debugging info. If anyone has any information about that i'd appreciate it. For now, I'm gonna grab the gdb source and dig in.

On MSVC there are some debugging libraries which can give you what you want. You could implement this in a non-portable way if no library existed for this:
SEH handlers can access the context and thus ESP(stack pointer), knowing the stack pointer you can read the stack from esp up until you reach the return address of the call WinMain (addr+5). If you have debug symbols or function metadata, you can more faithfully reconstruct all the function calls and their arguments, however it's not an easy task. If you only have function addresses, you can "guess" an approximate backtrace(without arguments). It's nothing too terribly hard to do, but there are usually both official and unofficial libraries which can provide you support for this. I don't know enough about how MinGW handles this to give you information about this, but on Windows, using dbghelp (+pdb of the module) is one way to do this. Also this KERNEL32 API http://msdn.microsoft.com/en-us/library/bb204633(VS.85).aspx (CaptureStackBackTrace) kind of performs some of the functions you would have to do manually with the context and esp. http://www.gnu.org/software/libtool/manual/libc/Backtraces.html for a *nix solution.

>>4
Thanks for the time. I will check out the links.

As for my problem, I eventually realized that I could use objcopy to extract the debug info. With more googling, I hit a Stack Overflow which lead me to exactly what I needed to do. So I wrote a small test and sure enough was able to create a separated debug file. It worked in MinGW gdb.

So, I may change my game plan: gdb is capable of reading a dump file and symbols. If I could produce a dump file, I could probably get a decent amount of information using that coupled with symbols, no extra software. Lazy, perhaps, but I have a feeling a dump file would be more useful if possible. I'm worried though as I'm not sure just how much information is contained in a dump file. Will have to research.

As for getting the function arguments, hmm. I'll look into it. I know if I do it the way I'm thinking, it will most likely end up needing an implementation for each architecture, but if that ends up only being x86 and x86-64 it's not such a big deal.

>>5
Would you mind uploading your ``test'' program's source? I'm pretty interested in this kind of stuff.

Also, keep me informed of your progress, this is more interesting that half the other shit on here

I BACKTRACED IT

>>6
Sorry for the delayed response.

Well, my 'test' was to write a small application, compile it with debugging symbols (-g) then split the debugging symbols and try using it with gdb.

Basically: It wasn't the application that's interesting, even hello world would've done it.


Here's what I did (copied off of an rxvt window)

----------
xxxx@BIGBOX ~
$ gcc -g main.cpp -o main

xxxx@BIGBOX ~
$ objcopy --only-keep-debug main.exe main.debug

xxxx@BIGBOX ~
$ strip --strip-debug --strip-unneeded main.exe

xxxx@BIGBOX ~
$ objcopy --add-gnu-debuglink=main.debug main.exe

----------
At this point I have two artifacts, main.exe and main.debug. At this point, main.exe contains no debugging symbols.

Now lets see if it works.
----------
xxxx@BIGBOX ~
$ gdb main.exe
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from C:\msys\1.0\home\xxxx/main.exe...(no debugging symbols found)...done.
(gdb) symbol-file main.debug
Reading symbols from C:\msys\1.0\home\xxxx/main.debug...done.
(gdb) break main
Breakpoint 1 at 0x401379: file main.cpp, line 11.
(gdb) run
Starting program: C:\msys\1.0\home\xxxx/main.exe
[New Thread 83828.0x15990]

Breakpoint 1, main (argc=1, argv=0x331778) at main.cpp:11
11              puts("Test.");
(gdb) quit
A debugging session is active.

        Inferior 1 [process 83828] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]
------
Not very interesting just yet. However, if I combine this method of getting my debugging symbols and some google breakpad code, I might be able to get a useful result. Some googling shows that you can use google breakpad code to create a dump which can be used with symbols to create a backtrace with MinGW. All it takes is for me to get off my lazy ass and make use of it.

>>8
[/code] tags are not only for actual code, you know.

>>9
Yeah, I prefer it to [m] tags, especially when there's an apostrophe that turns all text following it a lovely shade of green.

>>10
#I personally prefer the green.

>>11
s/green/red/
wtf

>>12
`smoke code tags everyday
#for that refreshing redness

Okay, I'll remember to use code tags next time. I'm not used to text boards here, didn't even realize there was code tags.

>>14
we have lots of tags around here.

Dog. It's not a wall of text, you've broken it into paragraphs.

Go back to the imageboards.

Consequences will never /b/ the same! xDDDD

>>16
Thanks for the suggestion, but do you think even /g/ knows a fucking thing compared to /prog/?

I just wanted the opinion of someone worth listening to for once. I'm tired of their shit at the imageboards. And I got what I wanted, a push in the right direction. Worked out well.

>>18
You missed my point. Learn what a wall of text is. Use the knowledge to die in dignity.

>>16
Dog.

                 _    _             __  __   ______   _   _                                         
                | |  | |           |  \/  | |  ____| | \ | |     /\                                 
                | |  | |           | \  / | | |__    |  \| |    /  \                                
                | |  | |           | |\/| | |  __|   | . ` |   / /\ \                               
                | |__| |           | |  | | | |____  | |\  |  / ____ \                              
                 \____/            |_|  |_| |______| |_| \_| /_/    \_\                             
                                                                                                    
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQWWWWWWWWm##BWW#8SvawQWWQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQWZZ##ZZZZZXX22nnnnvvI?YdQQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQWmm#ZXZXXXXSnnvvvvonvli|IWQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQW##XSSSS2onnvvvvIvoovv|+++?HQWQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQWWWmWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQWWX2oooo1llli|lillvvvvi|=:-:+{3WWQQ
QQQQQQQQQQQQQQQQQQQQQQQQQW#m####XX2X22oSX#WWWQQQQQQQQQQQQQQQQDX$W#nnn1vnli||+===-:=+i||l|=:.  =||VQW
QQQQQQQQQQQQQQQQQQQQQQQW###mZXXon1vvv2XZ#ZXZZ#mQQQQQQQQQQQQQAom#Xlliilvvlli==:. ...:==|||=:.   +v%3Q
QQQQQQQQQQQQQQQQQQQQQW#ZXSXSXYIllIvnoXXX#Z##mBWQQQQQQQWWWQQ#XW##e>+=|lvvli|+=:.. . ..;====;     -<l3
QQQQQQQQQQQQQQQQQQWWXX11no1Iilvlivvnoom#mWmmmQWQQQQQW##WWQEnW#B}--.;+iIvl|+=;.     . .;===;.     =|v
QQQQQQQQQQQQQQQQBXZn1lIvIiiii%||llvvmm#m#####WWQQQQW#Z#WWDvWXW}-. ..=|llii||=; .     :=+=||%v>.  -=I
QQQQQQQQQQQQQQW#1o1vlili|i||%=|i|ivXXX#U#ZZXmWQQQWm##X#mWoXX#Z>..  :aqgwo2lisi;.    .<vviilvY*i. .|>
QQQQQQQQQQQQQWGvvll||||=||||=+|=|ioSXZXXSSomQQQQWmm#XX#BGevv3Xz;=  vWWZYY}<vIns:  ..:i|++~-  ..  :|>
QQQQQQQQQQQQQZnli||=||=|+|===+==|vo#ZXS22S#WWQQWWW#XXXmWli<i3#hii. 3X(:/   -+l|..  :||: .        =|:
QQQQQQQQQQQQ#n}||+=;====;:::===|inZZXn2oXXXWBQWWWm#X2mWZii<i3Zmvn= -I:-     :iIsa>=vov:          |+.
QQQQQQQQQQQB2I||=:::=:::.:.:::=|i2XS1oXZXoX##Q#WWW#oX@1eii|IvX#ZXc  <i=,  . _vumQmqmmXa=___;.   .=| 
QQQQQQQQQW#oi|||=:::::.:.:.:.:=|vno1vXZonvommWQWQWXoW|<1=i|iivXXXc. -+1XuwosumQQWQWWW#Xov|i=    :== 
QQQQQQQQQWWhi|=:::=;:::=:::-:=|ilvnlnXnnwXZ#$WQQW#XXk>ic+i|i|lvXo1=   =vXmm##BBWWWWm#X2l|+|=   .;=` 
WWWWWBWW##XS>=;;=;;====::;:;:+||lIlinnomWS1oQWQQW#XX2s%l|Illi||Ioov=. :{Xm##ZmmW#USX1o1vi|+=  .;==  
mmmZZ#####Xn>=;;;:=++=.::=:=+|||i|||nq##X1ld#WWQB#XnhoiiivliI|+=nXov;  =3##X##m#ol+|lvnvv|==  .===  
XX#SXXXXZXqh>=;::==:::==:; :==||+||<dXZ21sdG#mQW#Xom#Silii><i||=v3mv|  .)XSX##ZXn|=:={2oivi=. .=== .
SX#X#ZXXX$mos==.==:::===: .:-=+==|=io*llvndnmWW##2XmZXXvIi=:|:=ii3mz+   +lvXX#21l=:::=+Ivvi>   =||..
1nClv211XX#Ssi;=|===|==;  .: :;=;==i||vXoSodZm#Z2d#X2XXes|==l:=vnmmX|   .<lvmZXc==:. .. -~<|:  -|=|.
1n2vvooooXZ2s=-=====|+=.:.:: ...:;=:in11nnXX#ZXoXZ21nnnzvivi|.<vXW#e=    =ldmmX}--:. .    :Ii.  ==:|
oXZXXXXX###mz====+.||+::=;:..   ::=<vlv1ndZm#2oXXXvInlvXsnvii=|I3WX1;    <vQWWQc  - .     :i|...;=;<
211vn1vnnoXmoi===+.=||:===..   ..:<><nvo#Z#m#oXSonvivvoXo2vvvvvnd#1v;    =vWWW#X;.        =i|=.:.:=<
ilivvlsvvXmmZs>=|===+|=:+;;.. .  .=ivnXSXXXmZnn2nnvInXZXenlvvInn3Sli;    -vWWWmXv;       .||ina...:<
iivvvlvIXZQW#1:+=-+=|+i;=;:.     :=<lnvXXnd#Xnn2o2nlnXolliiIliiil1||=     3#mW#X1=-..   .:||uQQ:::=<
liiivIvnqmW#Xl<%:.==|=|;.::... ...-|{Iv#XomUXodo22nin2ol>|+l||=++|++=;.    )UXXYl|==- -:,=iwQQW.%==|
l|lvvlvdUXSSeii> ==+>=+:=::.   .:.;=<|nXSo#Z2nXX22n|nnnI|==|=|====+=|=;.     ~^--     .<nnmWQQQ=S>|+
=iii|llvI{dSv=i` -.=`==+- .   .:.::=<lnSoZSe2nXXnXo|IloI=:;+==::::==+=:. .           :=il2XS$WW(nn||
|i|<%+<%v|vol==: ..:.=-`     ....;===|InnlIiooZ2vZXil|ni==:;=-.:.:+=+> .            .-:<nmXwuvIil1==
|=|%i+|=|<nl> .- .:..:    .. :..:=-.;=Iii++vnXXnvZ2Ii|v>=; :: .: ==|+;...            .:|nQmQWWmuuaii
==|i>={*}*I{> .  : :...: =: ..::: ..;<i+`:<vo2vInZnv|iv==.    . ..==== . ..          .:<dmQQWWmmmXXX
|||||=<>=iI%` .  : :..=;.= ..::.  . =+=:._vionvvX2ii=ii::.        ..-- . .         . .=idWQQWWWmm###
|++=+|=>:=v>:;     : :== : . +;.   --:.=|vIoonvo2ii>=||..         :: ._..           ..<n#QQQWWmBm##Z
<=|i%=i|iuci|:.     ..-. . . :i;.    .ivvivoonnnn=v=|==:..       .:. =..        .   .:vmmQQWWWWBm##X
|v1vavnI11*!*+=.  . ..      .:+==:.  :<vvonn1vlli=I+|-;.:        .- .=:.         ...:<X#WWQQQWmmm##Z
. -.::;===+++|+=     ....  .:==+|+=. :<vIlvviiiisi><| =..        . ..=:.    .  :..-::i<2X##WmWmm##ZZ
.......:::::=:;=:   .. .:::;::;:==vc -===|I>=ivil<:<|.::.   .     . ::. .  .  .  ..=v,="{vvYXX###XZX
   . .  .:...-.;+ .   ..=;:+===;;={p:.;;=%=.%Ill>===i::-. . ..   .  .:. - . . .:.:.:.""ns."+<I*1no2X
     . .. .. ..;=.    :::..- ..:-=3"`  ;|:=%lll>==>.|`: : :    . .   ::  .:.-..:::;     -?a,:^<i||{l
        - :.  -=;       :=. .-:.-.     ===Iii|++=+:==.     . ..;..    -  ::  ..;::.        "4a, -~|-
      .      .  .       .-:=          .+=|>|=|=;= =: .    .   .;..        .. .-::... .     .  "1a   
           .    -.          `        .=|+=|||===.=;:         .=;;.        . ..=:. .             -?s,

Protip: use a language that has a checked runtime environment. Like, oh, just about everything but Cee and sepples.

>>21
You are suggestion I use anything but Cee and sepples for game development.

I hope you can re-evaluate your statement and realize why in the practical world you can not do this.

>>4
YOU HELPED HIM !

>>22
Do it in Scheme.

Oh so this place has just as many trolls as any other board, just people who actually know how to code too.

Can't anything on 4chan just not suck altogether.

>>25
It's the best of both worlds here.

>>25
Everything on 4chan sucks. Luckily, /prog/ is not a part of 4chan.

>>27
What's that? Do you mean /prog/?

>>22
It's been done. Stop pretending you're programming in 1979.

>>29
Yeah it's been done and it sucks. I am working on games that are processor and graphics-accelerator intensive. Why should I double up on the requirements just so I can get debug info slightly easier?

You programmers who think LISP and C# are acceptable languages to write a game in don't know shit about practical programming. When it's performance critical, C and C++ are the only languages that actually work in one's favor.

>>30
C and Lisp coder here. I've written enough CL programs by now which have very good performance according to my requirements. They were easy to write at first, but turned out sluggish (even with SBCL's compiler(generates optimized native code and can infer types, thus minimizing the need for your own type decls)), after spending less than 30 minutes profiling and optimizing code, I've managed to improve the speed of multiple orders of magnitude. I could have improved it some 20-30% more, but the performance was already well beyond my needs and I decided that the effort needed to improve speed by 20% (a few more hours of coding) would not be worth my time (as the current performance was already well beyond my requirements and expectations). This was possible because I can generate code dynamically as I see fit and I can easily change large bodies of (EFFECTIVE) code by just minor modifications to the code belonging to the DSL which is being compiled. An interpreted C solution would have been much slower than the Lisp one, even though the C interpreter would have been faster than a Lisp interpreter (by some 2-3 times tops), the fact that I'm compiling/generating the code myself gives me much faster speed than I could have hoped to achieve by using just C (of course, I could have written a compiler in C, but such things don't come free like in Lisp, not to mention I've only spent a fraction of the time it would have taken me to write it in C, I don't have to write a parser, a compiler, the testing is very easy, debugging support is excellent and so on). Lisp can be just as good for performance critical applications if you know how to wield it properly, otherwise you might as well just use C. However, best performance is of course not achieved by the means of C or Lisp-only solutions, instead I found that a combination of Lisp, assembly and C is the best suited answer to high performance needs. Pick the right tool for the job, and get as fine-grained control over performance as you need, but you don't need fine-grained control over 80-90% of the applications most of the time. ``Good enough'' speed (let's say 2-3 times slower as if it were written in hand-optimized C) is enough for most of the code, but when you need the performance, you should feel free to go as low as you need. Don't fear generating code to achieve better performance, don't fear writing program writing programs to both reduce the among of code you need to write and improve performance.

s/among of code/amount of code//

>>31
That's interesting and everything, but I'm starting to question the point of bothering to do all of that instead of just using C++. It sounds like a rather confusing mix of code to me.

Even if it worked, I'd have to convince the team it's worth it, and that seems to be the hardest job of all. The apps are developed primarily on Windows, I'm usually going to be doing the porting. Not to mention, integrating the process into our IDE... We're using NetBeans right now.

Well hmm. I'm not saying I'm not listening. I might try to do this on my own time, if nothing else.

>>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).

>>30
When it's performance critical, C and C++ are the only languages that actually work in one's favor.
They do not. C and C++ are abstractions over the hardware. You can then turn around and reimplement your preferred memory model in the language. You can even convince yourself, like so many, that this abstraction inversion is not an anti-pattern but a feature (most C++ users convince themselves that all failures of the language are features), and then run around like an idiot saying only C and C++ are usable for gaming.

But those of us who know better think you're an idiot.

>>35
it's harder than in C
Not really. Tackling specific problems is probably easier in other languages than in C. The problem is that most people know C, so if you have to work with a lot of other people, you're going to be somewhat restricted. If you look at the GOAL language Naughty Dog used, for example, you can see that the benefits were enormous but the drawbacks were basically: not enough people know lisp well. That is a very large drawback because of all that it implies (lack of tools, lack of programmers, etc). But then we're not talking about the difficulty of the task, or what the best language is for the task; instead we're talking about human resource issues.

It is really terrible that one is short-circuited in exposition to mean the other.

http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV

>>37
If you look at the GOAL language Naughty Dog used
Where can I look at this? Have they actually released it at all?

>>39
I guess I should have said, "If you take the example of GOAL..."

>>37
He does have a kind of point, in that more people can manage memory by hand shittily, than can tune a garbage collector properly.

>>41
Well, garbage collection is one way to manage memory. When you are writing a general-purpose interpreter for general-purpose interactive programming you'd probably implement garbage collection. If you were doing something different, you'd compile a subset of your language to some other representation and not use garbage collection, or only use it on certain things, etc.

Here's the simple problem: you want a language that is low enough for you to twiddle bits, but high enough so that not everything is bit twiddling. This will never happen because there's too many platforms for bit-twiddling which the higher-level stuff just doesn't give a shit about, but for which some assumptions do have to be made. One day, though, one man said to himself, "Bullshit, I am smart. I can do it." He failed, and the result of that failure is C++, in which many buggy pseudo-interpreters for shitty, underspecified languages are made every day.

<-- check em dubz

46 Name: Anonymous 2011-02-03 6:33

---

Don't change these.

Name:		Email:
Entire Thread Thread List