Comments on: backtraces and prelink http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/ babblings! Thu, 27 Oct 2011 12:28:47 +0100 hourly 1 http://wordpress.org/?v=3.1.4 By: inquisitive http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/comment-page-1/#comment-117247 inquisitive Tue, 21 Oct 2008 18:58:21 +0000 http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/#comment-117247 If you have the answer to this question, that would be awesome: http://stackoverflow.com/questions/219800/convert-memory-address-range-in-running-linux-process-to-symbols-in-object-file If you have the answer to this question, that would be awesome:

http://stackoverflow.com/questions/219800/convert-memory-address-range-in-running-linux-process-to-symbols-in-object-file

]]> By: Anonymous debugger http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/comment-page-1/#comment-57562 Anonymous debugger Tue, 20 Nov 2007 09:55:01 +0000 http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/#comment-57562 > So, for something like openoffice.org the debuginfo is about 400Megs in size Include only .debug_frame section, that's much smaller (it contains only info on all function names and number of their args) and have full debug symbols in separate package. For an example how to do this, see glibc debian package. > So, for something like openoffice.org the debuginfo is about 400Megs in size

Include only .debug_frame section, that’s much smaller (it contains only info on all function names and number of their args) and have full debug symbols in separate package. For an example how to do this, see glibc debian package.

]]> By: caolan http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/comment-page-1/#comment-24414 caolan Thu, 19 Apr 2007 06:54:09 +0000 http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/#comment-24414 It is a point that the "vanilla" openoffice.org rpms don't make a matching "debuginfo" rpm available which would enable the user that has it installed to run their office inside gdb which would give a pre-mapped to symbol names call-stack <b>with</b> function parameters and ability to examine what went wrong directly. So there is an argument for making a debuginfo rpm for the vanilla OOo so that the oooqa team members could keep that installed and use gdb on reproducible crashes to get better stacktraces for devs It is a point that the “vanilla” openoffice.org rpms don’t make a matching “debuginfo” rpm available which would enable the user that has it installed to run their office inside gdb which would give a pre-mapped to symbol names call-stack with function parameters and ability to examine what went wrong directly. So there is an argument for making a debuginfo rpm for the vanilla OOo so that the oooqa team members could keep that installed and use gdb on reproducible crashes to get better stacktraces for devs

]]> By: qa interested ooo user http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/comment-page-1/#comment-24274 qa interested ooo user Wed, 18 Apr 2007 19:39:11 +0000 http://blogs.linux.ie/caolan/2007/04/16/backtraces-and-prelink/#comment-24274 >> So, for something like openoffice.org the debuginfo is >> about 400Megs in size which is sort of large to ask >> someone to download. For some (more and more) people 400Megs is no problem anymore. >> Anyway, crashes happen when the user isn’t prepared, so >> they never have a debugging OOo to hand and if they do >> install the debuginfo they won’t be able to reproduce the >> problem. Members of oooqa team would have experience to reproduce the crash. So take the number of oooqa members who have broadband. Imagine those would submit crash reports from the debug version of ooo. Would that signifcantly help core devels to save time for mixing more bugs? I dont know the answer, just want to ask a good question ;-) >> So, for something like openoffice.org the debuginfo is
>> about 400Megs in size which is sort of large to ask
>> someone to download.

For some (more and more) people 400Megs is no problem anymore.

>> Anyway, crashes happen when the user isn’t prepared, so
>> they never have a debugging OOo to hand and if they do
>> install the debuginfo they won’t be able to reproduce the >> problem.

Members of oooqa team would have experience to reproduce the crash. So take the number of oooqa members who have broadband. Imagine those would submit crash reports from the debug version of ooo. Would that signifcantly help core devels to save time for mixing more bugs?
I dont know the answer, just want to ask a good question ;-)

]]>