Anyway, I compiled bacula-sd with --enable-smartalloc and ran in the
correct way. Is the attached traceback more usable?
--
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 ;)
bacula-traceback.txt
Description: Text document
------------------------------------------------------------------------------
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
|
