Ryan Novosielski schrieb:
The other machine, which has been producing that error intermittently almost from the beginning, says: *version xenon-dir Version: 2.2.5 (09 October 2007) i686-suse-linux-gnu suse 10.2 That one was compiled by myself and is using SQLite.Example message from that one:16-Feb 14:09 xenon-dir: Fatal Error at sql_get.c:580 because: rwl_writelock failure. stat=22: ERR=Invalid argument 16-Feb 14:09 xenon-dir: ERROR in mem_pool.c:163 Failed ASSERT: obuf 16-Feb 14:09 xenon-dir: Fatal Error because: Bacula interrupted by signal 11: Segmentation violationThe "Failed ASSERT" line is not always present, though. Sometimes I see02-Feb 15:28 xenon-dir: ABORTING due to ERROR in smartall.c:194 double free from smartall.c:328in its place, sometimes it's just the "rwl_writelock" and "signal 11" lines like on vm-backup.If your binaries are not stripped, I'd do a backtrace. Usually that is helpful for a bug report.
My self-compiled binaries aren't stripped (and if they were I could of course easily recreate them unstripped) but I'm not sure how I would backtrace that crash. It doesn't look as if it left a core dump anywhere. Are you suggesting that I run bacula-dir in gdb? Do I need any command line options for that, for example to prevent it from forking? Should I set any breakpoints or is it enough to wait for the SIGSEGV and then type `where'? Thx T. -- Tilman Schmidt Phoenix Software GmbH www.phoenixsoftware.de 53227 Bonn, Germany Amtsgericht Bonn HRB 2934
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
