-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/07/2009 05:39 AM, Rob OpenSuSE wrote:
2009/12/6 Jeff Mahoney
: 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 smoothly.
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
: 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
KDE.org 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 the 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 questions,
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 reports.
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 SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksdHPsACgkQLPWxlyuTD7LU3gCggR6wwISiwyEscva8GM85bYEH +jwAoJh0R2d+ie0o604R0A0I+GFvQc3l =ogq2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org