No, I’m not talking about blog’s trackbacks but about the stack traces that are so much useful when trying to debug crashes and aborts in complex programs.
Lately it happened quite often to me to ask people to get backtraces when reporting crashes, as they makes my work way less difficult, as I don’t have to try two hunderd of thousand combinations while trying to reproduce a crash that happens only on the user’s system and with a given file. The reason I’m asking this now and I wasn’t before is that using Portage’s splitdebug feature makes quite cheap to ask users to enable debug information, they just have to rebuild the packages once, and then get rid of the whole /usr/lib/debug directory.
This helped me not only to fix the mad problem with xine-lib, but also alsaplayer’s crash and other things.
But repeating every time the whole stuff again (disable -O3, add -ggdb, bla bla bla). So I thought already in the last days to simply write a guide to tell the users how to do that, and then just point them to the page without having to repeat the whole thing. Today I asked solar if there was already a similar guide, and it seemed it wasn’t the case, so I’ve started drafting something up, and thanks (many many thanks) to Kevin Quinn I’ve been able to come up with a backtraces guide that should explain most of the tips and tricks needed to get backtraces.
Okay so today I spent it mostly on this and for my job, tonight I’ll try to fix a bug or two before going to sleep, but I’m quite tired already 😐 this job, and waiting for news of the new job, is stressing me.
Nice article. I’ll be pointing people at that a lot.Gnome also has a crash handler, called “Bug Buddy” (gnome-extra/bug-buddy, in gnome-base/gnome); you have to click “Inform Developers” in the crash handler dialog and “Show Debugging Details” in the next window.
Yep I know there’s an equivalent for Gnome, but I don’t know much if it, it’s stated in the TODO list of the guide (look at the raw xml with viewcvs).If you can suggest me something to write in the guide about that, I can do that tomorrow :)Feel free to mail me directly.
IIRC, i’ve read in some previous blog post that you are using -ggdb with splitdebug. I myself am currently using -g, but i’m considering switching to -ggdb too, if the space overhead is not to big (or maybe i will switch anyway, but after bind mounting /usr/lib/debug to some other partition).So, just to get an idea of how much bigger -ggdb can be, i would be very interested if you could run the following script on your system:http://tdegreni.free.fr/gen…FYI, here the “debug size / binary size” ratio is ~200% (with CFLAGS=”-march=pentium-m -O2 -g”).
Thanks for that script TGL, is quite interesting to see :)I’ve just run it and the ratio here is 300.5%.
Thanks for the answer Diego. That’s good news, going from 200% to 300% is okay: it will make an ~1GB increase on my system, which i have room for, so i will change my flag.