On Saturday 24 January 2009 23:18:44 Silver Salonen wrote:
> Anyway, I compiled bacula-sd with --enable-smartalloc and ran in the
> correct way. Is the attached traceback more usable?
Yes, you are making good progress. The dump is much better but still lacks
important information. I suggest two things:
1. Make sure you compile with the -g option. You might check to
ensure that:
#define DEVELOPER 1
is defined in <bacula-source>/src/version.h
Then completely rebuild the code:
make clean
make
make install
Then instead of sending a signal to the SD, when you are *sure* it is hung,
while running it under the debugger, simply enter a ctl-c in the debugger
shell window and then the rest of the commands.
Hopefully, that will get a complete traceback.
Finally, you should use -d 100 on the execution line and direct the output of
Bacula to a file so that in addition to the traceback we have a debug
listing.
Regards,
Kern
>
> --
> Silver
>
> On Sat, January 24, 2009 21:19, Silver Salonen wrote:
> > OK, I'll try.. but what does "built with debug information turned on and
> > not stripped of debugging symbols" mean? The only thing I found about
> > debugging in configure script was --enable-smartalloc - that's it?
> >
> > --
> > Silver
> >
> > On Sat, January 24, 2009 19:29, Kern Sibbald wrote:
> >> Hello,
> >>
> >>
> >>
> >> Sorry, but the backtrace is not usable. Please make sure you have
> >> build the SD with the debug symbols left in (i.e. do not strip it). I
> >> suggest you read the Kaboom chapter of the manual that explains how to
> >> get a backtrace.
> >>
> >> Kern
> >>
> >> On Saturday 24 January 2009 17:54:05 Silver Salonen wrote:
> >>> Hi.
> >>>
> >>>
> >>>
> >>> It seems I'm experiencing the same problem on FreeBSD 6.3. I ran
> >>> bacula-sd in gdb and when the backups started running, a few of them
> >>> ran and completed successfully, but stayed in "terminated" status
> >>> afterwards. Other jobs just didn't start running. When I sent just
> >>> ordinary kill to the process, gdb said the program terminated. The
> >>> output of gdb:
> >>>
> >>> (gdb) run -f -c /usr/local/etc/bacula-sd.conf
> >>> Starting program: /usr/local/sbin/bacula-sd -f -c
> >>> /usr/local/etc/bacula-
> >>> sd.conf (no debugging symbols found)...(no debugging symbols
> >>> found)...warning:
> >>> Unable to get location for thread creation breakpoint: generic error
> >>> [New LWP 100405]
> >>> (no debugging symbols found)...(no debugging symbols found)...(no
> >>> debugging symbols found)...(no debugging symbols found)...(no
> >>> debugging symbols found)...(no debugging symbols found)...(no
> >>> debugging symbols found)...(no debugging symbols found)...(no
> >>> debugging symbols found)...[New Thread 0x80c0200 (LWP 100057)]
> >>>
> >>>
> >>> Program received signal SIGTERM, Terminated.
> >>> [Switching to Thread 0x80c0200 (LWP 100057)]
> >>> 0x281075db in pthread_testcancel () from /lib/libpthread.so.2
> >>> (gdb) backtrace
> >>> #0 0x281075db in pthread_testcancel () from /lib/libpthread.so.2
> >>> #1 0x280f4c25 in sigaction () from /lib/libpthread.so.2
> >>> #2 0x280f4f11 in sigaction () from /lib/libpthread.so.2
> >>> #3 0x280f56f0 in sigaction () from /lib/libpthread.so.2
> >>> #4 0x280f589c in sigaction () from /lib/libpthread.so.2
> >>> #5 0x280ffeec in pthread_mutexattr_init () from /lib/libpthread.so.2
> >>> #6 0x280d8450 in ?? ()
> >>> (gdb) quit
> >>> The program is running. Exit anyway? (y or n) y
> >>>
> >>>
> >>>
> >>> PS. Sorry if I used gdb incorrectly, I'm not very experienced with
> >>> it.. let me know what to do better next time ;)
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|