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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
