Mailinglist Archive: opensuse-factory (661 mails)

< Previous Next >
Re: [opensuse-factory] The Future of SaX2
  • From: Jeff Mahoney <jeffm@xxxxxxxx>
  • Date: Mon, 07 Dec 2009 10:19:24 -0500
  • Message-id: <4B1D1CFC.1040508@xxxxxxxx>
Hash: SHA1

On 12/07/2009 05:39 AM, Rob OpenSuSE wrote:
2009/12/6 Jeff Mahoney <jeffm@xxxxxxxx>:
On 12/06/2009 06:22 PM, Rajko M. wrote:

It often requires just ability to set break point with a message, to locate
code that makes trouble. No much need to understand the code.

This is a really good point. Personally, I learned C after I was messing
around with code. In a previous life, I ran a bunch of DEC Ultrix
systems. No shared libraries, ancient X implementation, etc. I ended up
building a *lot* of things for these systems and it didn't always go

I had some MIPS based DECstations, I remember the "advance" getting
gcc installed and how it eased porting.

Not sure if it's always easier to read code, than write. As touched
on very many coders seem unable to see things from point of view of
other ppl, comment the obvious and leave the whacky & bizarre to speak
for itself.

2009/12/7 Karsten König <remur@xxxxxxx>:

It is coming back to think how we can use better smolt and hardware
detection tools, make information upload lesser labor intensive, from
prospectives of user, developer and/or helper in forums.

This is something that we've discussed informally for a while. I would
love to have a tool that automatically sends backtraces of every
crashing program that we ship back to a server so that we can has something like this, the "new" Dr. Konqui makes a stacktrace etc
what might be important and asks the user how to reproduce it etc, basicly
same as a bugzilla interface, just right after the program crashed and with
all the infos at hand (if you have the -debug packages installed that is).

Problem with bugreports like these is people often don't respond to

The problem I have had, is the stack trace doesn't have the symbolic
information to make it "useful" and as one is very likely to be punted
upstream, there's not much incentive to spend much time on KDE bug

Is including symbolics a performance hit, or just a disk space issue?

It's a disk space issue. The symbol tables are in a different ELF
section and don't actually get loaded at runtime. The thing is that it
is a *huge* disk space issue. The kernel packages, for example, grow to
over 1 GB in size if they include debuginfo. I do a lot of testing
without building RPMs and I have to remember to strip the debuginfo when
installing the modules or I very quickly run out of disk space on my
root filesystem.

I haven't ever actually tried it, but it should be possible to translate
the backtrace on a different machine, if the matching debuginfo is
available. The down side is that you don't end up getting symbolic
information for things in the stack frame (like current variables).

- -Jeff

- --
Jeff Mahoney
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread