Ubuntu's new Linux sports debugging tool (ZDNet)

Posted Apr 12, 2007 18:18 UTC (Thu) by ken (subscriber, #625) [Link]

Also I had a BIG problem trying to get back to see if anyone had done anything. I really do not see what they have that the debian bug tracking system dose not and that one is really easy to interact with.

Posted Apr 12, 2007 22:09 UTC (Thu) by cpeterso (guest, #305) [Link]

And I agree with Ken: why require registration? Perhaps to acknowledge the user has opted-out of their privacy and to prevent fake crash reports?

Posted Apr 12, 2007 23:59 UTC (Thu) by yarikoptic (subscriber, #36795) [Link]

Before Share the pain button comes to Linux OS I don't feel myself comfortable! ;-) So far I found existing Ubuntu's bug reporting a joke -- most of bug reports didn't provide any essential information on the system -- release codename at best... Debian's reportbug is simple and really handy in the way it templates the report for you.

Posted Apr 16, 2007 3:21 UTC (Mon) by ringerc (subscriber, #3071) [Link]

So ... does this mean they'll finally stop stripping their binaries by default?

Getting a backtrace from a Debian/Ubuntu user has been a source of pain for some time, because the packaging system strips binaries.

For those not familiar with the four common levels of binary debuggability on *nix, here's a quick rundown with some examples that should show why stripped binaries are a PITA.

Normally, with full debug info like you'd have in a program you compiled yourself with debugging turned on, you get a backtrace like this from a simple crash:

Program received signal SIGSEGV, Segmentation fault.
0x0804832a in crash (x=0x0) at test.c:3
3               (*x) = 1;
(gdb) bt
#0  0x0804832a in crash (x=0x0) at test.c:3
#1  0x0804834f in main () at test.c:8

It shows line numbers, function arguments, lets you explore the stack and the contents of memory using the program's symbolic names for variables, etc. It also lets you set breakpoints and step through execution. It's also very, very large - typically at least twice the size, sometimes ten or more times especially for C++ code. It can also be slower. Distributors and users do not want to deal with programs that've been built this way for obvious reasons.

The next step down is the approach used by Red Hat and many other RPM based distros now. They tell the compiler to generate debugging information in a separate file, rather than embedding it into the executable. The user can install the debug info package if they need it, without having to recompile the program, but don't have to waste the space otherwise. Additionally, there's no performance penalty (though AFAIK at the cost of little or no ability to step through the program's execution). This approach is great if you´re trying to get useful debug info from a user. To learn more about it, see the --only-keep-debug option to `strip'.

Another step down again is building completely without debugging information. You lose the ability to step through the program or set breakpoints (mostly), and you lose line numbers, function arguments, etc. However, the call stack is still available within some limits, so you get a backtrace somewhat like this:

Program received signal SIGSEGV, Segmentation fault.
0x0804832a in crash ()
(gdb) bt
#0  0x08048334 in crash ()
#1  0x0804834f in main ()

That often tells you enough to at least get started tracking down an issue. There's no performance penalty, and not overly much difference in file size for the vast majority of executables. However, if a binary is stripped, here's the backtrace you get:

Program received signal SIGSEGV, Segmentation fault.
0x0804832a in ?? ()
(gdb) bt
#0  0x0804832a in ?? ()
#1  0xbfcee498 in ?? ()
#2  0x0804834f in ?? ()
#3  0x00000000 in ?? ()

Less than useful, eh?

Anybody know if Debian and/or Ubuntu intend to support external debug info soon?