Menu
▾
▴
[Bacula-bugs] [bacula 0001047]: bacula-fd crash with strippath > 0 in fileset
|
From: <bac...@li...> - 2008-01-29 20:03:57
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=1047 ====================================================================== Reported By: jgoerzen Assigned To: ====================================================================== Project: bacula Issue ID: 1047 Category: File Daemon Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 01-29-2008 15:35 UTC Last Modified: 01-29-2008 20:03 UTC ====================================================================== Summary: bacula-fd crash with strippath > 0 in fileset Description: Received this bug report from Bastian Blank <wa...@de...> at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452195: This was reported on Bacula 2.2.5, but the changelog doesn't seem to show a relevant change between that and 2.2.8. bacula-fd crashs if strippath is set in the fileset. | *** glibc detected *** /usr/sbin/bacula-fd: free(): invalid next size (normal): 0x00000000006ba9e0 *** | ======= Backtrace: ========= | /lib/libc.so.6[0x2b357fed9a4a] | /lib/libc.so.6(cfree+0x8c)[0x2b357fedd63c] | /usr/sbin/bacula-fd[0x406d5a] | /usr/sbin/bacula-fd[0x412f65] | /usr/sbin/bacula-fd[0x413e4b] | /usr/sbin/bacula-fd[0x41460b] | /usr/sbin/bacula-fd[0x41460b] | /usr/sbin/bacula-fd[0x4136eb] | /usr/sbin/bacula-fd[0x4066bb] | /usr/sbin/bacula-fd[0x40b211] | /usr/sbin/bacula-fd[0x40bc49] | /usr/sbin/bacula-fd[0x4336ab] | /lib/libpthread.so.0[0x2b357f0ad317] | /lib/libc.so.6(clone+0x6d)[0x2b357ff3bc7d] gdb on an unstripped binary show: | Starting program: /root/bacula-2.2.5/debian/tmp-build-sqlite/src/filed/bacula-fd -c /etc/bacula/bacula-fd.conf -s -f -d6 | [Thread debugging using libthread_db enabled] | [New Thread 0x2ba795946160 (LWP 1246)] | [New Thread 0x40800950 (LWP 1253)] | [New Thread 0x41001950 (LWP 1256)] | 20-Nov 21:01 test.backup.jura.uni-tuebinge: ABORTING due to ERROR in smartall.c:202 | qp->qnext->qprev != qp called from find_one.c:115 | | Program received signal SIGSEGV, Segmentation fault. | [Switching to Thread 0x40800950 (LWP 1253)] | e_msg (file=0x4429ac "smartall.c", line=202, type=1, level=<value optimized out>, | fmt=0x4428d0 "qp->qnext->qprev != qp called from %s:%d\n") at message.c:1060 | 1060 p[0] = 0; /* generate segmentation violation */ | Current language: auto; currently c++ | (gdb) bt | http://bugs.bacula.org/view.php?id=0 e_msg (file=0x4429ac "smartall.c", line=202, type=1, level=<value optimized out>, | fmt=0x4428d0 "qp->qnext->qprev != qp called from %s:%d\n") at message.c:1060 | http://bugs.bacula.org/view.php?id=1 0x00000000004315b8 in sm_free (file=0x43d509 "find_one.c", line=115, fp=0x6bb738) at smartall.c:202 | http://bugs.bacula.org/view.php?id=2 0x000000000041399a in free_dir_ff_pkt (dir_ff_pkt=0x6bb448) at find_one.c:115 | http://bugs.bacula.org/view.php?id=3 0x0000000000414756 in find_one_file (jcr=0x651f28, ff_pkt=0x6525c8, handle_file=0x412cc0 <our_callback>, pkt=0x651f28, | fname=0x6b9808 "/mnt/backup/root", parent_device=65024, top_level=false) at find_one.c:659 | http://bugs.bacula.org/view.php?id=4 0x000000000041460b in find_one_file (jcr=0x651f28, ff_pkt=0x6525c8, handle_file=0x412cc0 <our_callback>, pkt=0x651f28, | fname=0x6b7d28 "/mnt/backup", parent_device=65024, top_level=false) at find_one.c:638 | http://bugs.bacula.org/view.php?id=5 0x000000000041460b in find_one_file (jcr=0x651f28, ff_pkt=0x6525c8, handle_file=0x412cc0 <our_callback>, pkt=0x651f28, | fname=0x6b6248 "/mnt", parent_device=65024, top_level=false) at find_one.c:638 | http://bugs.bacula.org/view.php?id=6 0x000000000041460b in find_one_file (jcr=0x651f28, ff_pkt=0x6525c8, handle_file=0x412cc0 <our_callback>, pkt=0x651f28, | fname=0x6533d8 "/", parent_device=18446744073709551615, top_level=true) at find_one.c:638 | http://bugs.bacula.org/view.php?id=7 0x00000000004136eb in find_files (jcr=0x651f28, ff=0x6525c8, callback=<value optimized out>, his_pkt=0x651f28) | at find.c:200 | http://bugs.bacula.org/view.php?id=8 0x00000000004066bb in blast_data_to_storage_daemon (jcr=0x651f28, addr=<value optimized out>) at backup.c:158 | http://bugs.bacula.org/view.php?id=9 0x000000000040b211 in backup_cmd (jcr=0x651f28) at job.c:1437 | http://bugs.bacula.org/view.php?id=10 0x000000000040bc49 in handle_client_request (dirp=<value optimized out>) at job.c:250 | http://bugs.bacula.org/view.php?id=11 0x00000000004336ab in workq_server (arg=<value optimized out>) at workq.c:357 | http://bugs.bacula.org/view.php?id=12 0x00002ba794415317 in start_thread (arg=<value optimized out>) at pthread_create.c:296 | http://bugs.bacula.org/view.php?id=13 0x00002ba7952a3c7d in clone () from /usr/lib/debug/libc.so.6 | http://bugs.bacula.org/view.php?id=14 0x0000000000000000 in ?? () bacula does some weird own memory tracking stuff their, but it looks like calling free on a not malloced address. ====================================================================== ---------------------------------------------------------------------- kern - 01-29-08 18:13 ---------------------------------------------------------------------- It is a buffer overrun, which Bacula's smartalloc is detecting and not a free of a non-malloced buffer. Could you please upload your bacula-dir.conf file? I would like to see what directives you are using. Concerning: "Can someone please explain why bacula needs its own memory check stuff which don't gain many but breaks external debuggers like valgrind?" Bacula's smart memory code is superior to anything built into glibc. It detects many problems dynamically with low overhead, and this case clearly shows that it detected a heap corruption apparently caused by a buffer overrun. I have run valgrind many times on Bacula with smartalloc turned on with absolutely no problem so I am not sure what problems you are referring to or why you had to disable it, which is done by a ./configure option. ---------------------------------------------------------------------- jgoerzen - 01-29-08 18:30 ---------------------------------------------------------------------- Thanks, Kern. I have forwarded this on to the bug submitter. ---------------------------------------------------------------------- jgoerzen - 01-29-08 20:03 ---------------------------------------------------------------------- From: Bastian Blank <wa...@de...> On Tue, Jan 29, 2008 at 12:29:59PM -0600, John Goerzen wrote: > From Kern Sibbald, Bacula author: > It is a buffer overrun, which Bacula's smartalloc is detecting and not a free > of a non-malloced buffer. It did _not_ detect it. The glibc aborted the program because it trashed the internal malloc data. > Could you please upload your bacula-dir.conf file? I would like to see what > directives you are using. Similar to | File = /test | strippath = 1 > I have run valgrind many times on Bacula with smartalloc turned on > with absolutely no problem so I am not sure what problems you are referring > to or why you had to disable it, which is done by a ./configure option. Because valgrind never sees the broken allocations. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4 Issue History Date Modified Username Field Change ====================================================================== 01-29-08 15:35 jgoerzen New Issue 01-29-08 18:04 kern Note Added: 0003110 01-29-08 18:12 kern Note Deleted: 0003110 01-29-08 18:13 kern Note Added: 0003112 01-29-08 18:13 kern Status new => feedback 01-29-08 18:30 jgoerzen Note Added: 0003114 01-29-08 20:03 jgoerzen Note Added: 0003118 ====================================================================== |