This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Backtrace extraction ONLY gdb


Hey Tom,

Thanks for your reply.
The suid trick may do it... Though isn't there some story about suid scripts not being allowed?

>> You can make them on the production machine and then analyze them elsewhere.
Well if analyze them elsewhere is 'looking at the backtrace', yes.
If analyze them elsewhere is fully browsing the core file, it requires the exact same exe/libs versions as on the production system.
HP's gdb adds a great feature called packcore to ease the packing of everything needed for offline browsing with one command.

++Cyrille

 

-----Original Message-----
From: Tom Tromey [mailto:tromey@redhat.com] 
Sent: Tuesday, March 22, 2011 5:47 PM
To: Maucci, Cyrille
Cc: gdb@sourceware.org
Subject: Re: Backtrace extraction ONLY gdb

>>>>> "Cyrille" == Maucci, Cyrille <cyrille.maucci@hp.com> writes:

Cyrille> Is there any possibility to 'recompile' gdb where only the 'bt'
Cyrille> (or 'threads apply all bt') feature would be enabled?

Maybe with a lot of hacking.

If the process you need to attach to is always owned by a particular user, you can play games with suid to restrict gdb to doing backtraces.
(Install gdb so that it is only executable by that user.  Then, make a suid wrapper owned by that user that invokes `gdb -batch -p PID -ex "thread apply all bt full"'.)

Alternatively, core files are good for this kind of use.  You can make them on the production machine and then analyze them elsewhere.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]