Hello Lucas,

On Tuesday 01 December 2009 18:40:52 Lucas B. Cohen wrote:
> Hi,
>
> In the process of documenting the 'btraceback' scripts in the form of a
> manpage so as to comply with the Debian guidelines, I'm wondering how
> safe it is in practice to attach a debugger like gdb or dbx to a running
> process to get a stacktrace.

As far as I know it is perfectly safe.  I have done so *many* times, and after 
debugging detached with no harm to running programs.  It is not something I 
would normally attempt on a "production" program.

>
> Searching lists archives for 'btraceback' and reading the Problem
> Resolution Guide can give one the feeling that it is a perfectly safe
> thing to do, perhaps repeatedly, during normal operations.
>
> However, common search engines turned up hits that seemed to show that
> some (admitedly faulty) - programs may be striken with sudden death when
> such attempts are made by a debugger to attach to them. (Excluding of
> course binaries packed/protected to prevent debugging analysis by design).
>
> Have there been incidents known to have been caused by the use of
> btraceback/gdb/dbx during normal operations ?

No, not to my knowledge, and as noted below, Bacula never calls 
btraceback/gdb/dbx during normal operations.

>
> It is well understood that this risk applies to any program, and can
> involve the quality of the debugging software as much as the quality of
> the compilation; are there neverless specific things in the Bacula code
> or its build system that would have a known specific effect as a risk
> factor for live debugging ?

We do not do live debugging on Bacula.  Bacula will only call the debugger on 
itself *AFTER* it has received a fatal signal and printed a preliminary 
message.  At that point, Bacula is technically dead or 100% guaranteed to 
stop running in one way or another.  

Bacula code never calls the debugger on itself in normal running conditions.  
In any case, every user can easily turn off the debugging by either not 
making the debugger available or just not including the script that calls it.  
Bacula does not *directly* call the debuger but works through a script that 
the user can modify.

What Bacula does is not much different than most Open Source GUI window 
systems such as GNOME or KDE where when they die, they do a backtrace (often 
with their own code) before quiting.  In the case of most of these programs, 
the traceback is compiled into the program (and thus to a certain extent 
hidden), while Bacula uses standard system tools that the user can configure.

Regards,

Kern

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users