Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
> On Mon, 18 Jul 2022 10:06:50 -0500, Larry Rosenman said: > > I'll just keep using the DEBUG build for now, but sounds like this > should be picked up > upstream. I've reported it here: https://bugs.bacula.org/view.php?id=2655 __Martin ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
> On Mon, 18 Jul 2022 10:06:50 -0500, Larry Rosenman said:
>
> On 07/18/2022 10:00 am, Martin Simmons wrote:
> >> On Mon, 18 Jul 2022 09:18:17 -0500, Larry Rosenman said:
> >>
> >> On 07/18/2022 8:22 am, Martin Simmons wrote:
> >> >> On Sat, 16 Jul 2022 17:00:33 -0500, Larry Rosenman said:
> >> >>
> >> >> (gdb) bt full
> >> >> #0 kill () at kill.S:4
> >> >> No locals.
> >> >> #1 0x00088ad660a0 in __fail (
> >> >> msg=0x88ac6d34f "stack overflow detected; terminated")
> >> >> at /usr/src/lib/libc/secure/stack_protector.c:130
> >> >> sa = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction =
> >> >> 0x0},
> >> >>sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
> >> >> mask = {__bits = {4294967263, 4294967295, 4294967295,
> >> >> 4294967295}}
> >> >> #2 0x00088ad66010 in __stack_chk_fail ()
> >> >> at /usr/src/lib/libc/secure/stack_protector.c:137
> >> >> No locals.
> >> >> #3 0x00252e69 in send_include_list(JCR*) ()
> >> >> No symbol table info available.
> >> >> #4 0x0024241e in do_backup(JCR*) ()
> >> >> No symbol table info available.
> >> >> #5 0x00257307 in job_thread(void*) ()
> >> >> No symbol table info available.
> >> >> #6 0x0025d124 in jobq_server ()
> >> >> No symbol table info available.
> >> >> #7 0x000886269d08 in lmgr_thread_launcher ()
> >> >> from /usr/local/lib/libbac-13.0.0.so
> >> >> No symbol table info available.
> >> >> #8 0x0008869a496a in thread_start (curthread=0x89c8a7000)
> >> >> at /usr/src/lib/libthr/thread/thr_create.c:292
> >> >
> >> > It might be useful to also post the output of these three gdb commands
> >> > from
> >> > the core file:
> >> >
> >> > disass send_include_list
> >> > p __stack_chk_guard
> >> > x/256xg $sp
> >> >
> >> > __Martin
> >>
> >> https://www.lerctr.org/~ler/bacula-dir.gdb.txt
> >>
> >> too big for the list :)
> >
> > Ok, that shows the problem. The function send_fileset in
> > src/dird/fd_cmds.c
> > has an array called newopts on the stack, but it is too small so it
> > overflows.
> > It is too small because fd_cmds.c includes findlib/find.h, which
> > redefines
> > MAX_FOPTS with a value that is too small for this use. I don't see why
> > findlib/find.h needs to be included, so you could try the patch below:
> >
> > --
> > --- src/dird/fd_cmds.c~ 2022-05-17 17:13:42.541093000 +0100
> > +++ src/dird/fd_cmds.c 2022-07-18 15:45:10.357144000 +0100
> > @@ -32,7 +32,7 @@
> >
> > #include "bacula.h"
> > #include "dird.h"
> > -#include "findlib/find.h"
> > +#include "findlib/bfile.h"
> >
> > const int dbglvl = 400;
> >
> > --
> >
> > The overflow is triggered by your change to the fileset, which
> > increases the
> > size of the options list sent to the client.
> >
> > __Martin
> I'm just surprised the DEBUG build works then.
It probably just corrupts the stack in some way that is not detected.
__Martin
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
On 07/18/2022 10:00 am, Martin Simmons wrote:
On Mon, 18 Jul 2022 09:18:17 -0500, Larry Rosenman said:
On 07/18/2022 8:22 am, Martin Simmons wrote:
>> On Sat, 16 Jul 2022 17:00:33 -0500, Larry Rosenman said:
>>
>> (gdb) bt full
>> #0 kill () at kill.S:4
>> No locals.
>> #1 0x00088ad660a0 in __fail (
>> msg=0x88ac6d34f "stack overflow detected; terminated")
>> at /usr/src/lib/libc/secure/stack_protector.c:130
>> sa = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction =
>> 0x0},
>>sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
>> mask = {__bits = {4294967263, 4294967295, 4294967295,
>> 4294967295}}
>> #2 0x00088ad66010 in __stack_chk_fail ()
>> at /usr/src/lib/libc/secure/stack_protector.c:137
>> No locals.
>> #3 0x00252e69 in send_include_list(JCR*) ()
>> No symbol table info available.
>> #4 0x0024241e in do_backup(JCR*) ()
>> No symbol table info available.
>> #5 0x00257307 in job_thread(void*) ()
>> No symbol table info available.
>> #6 0x0025d124 in jobq_server ()
>> No symbol table info available.
>> #7 0x000886269d08 in lmgr_thread_launcher ()
>> from /usr/local/lib/libbac-13.0.0.so
>> No symbol table info available.
>> #8 0x0008869a496a in thread_start (curthread=0x89c8a7000)
>> at /usr/src/lib/libthr/thread/thr_create.c:292
>
> It might be useful to also post the output of these three gdb commands
> from
> the core file:
>
> disass send_include_list
> p __stack_chk_guard
> x/256xg $sp
>
> __Martin
https://www.lerctr.org/~ler/bacula-dir.gdb.txt
too big for the list :)
Ok, that shows the problem. The function send_fileset in
src/dird/fd_cmds.c
has an array called newopts on the stack, but it is too small so it
overflows.
It is too small because fd_cmds.c includes findlib/find.h, which
redefines
MAX_FOPTS with a value that is too small for this use. I don't see why
findlib/find.h needs to be included, so you could try the patch below:
--
--- src/dird/fd_cmds.c~ 2022-05-17 17:13:42.541093000 +0100
+++ src/dird/fd_cmds.c 2022-07-18 15:45:10.357144000 +0100
@@ -32,7 +32,7 @@
#include "bacula.h"
#include "dird.h"
-#include "findlib/find.h"
+#include "findlib/bfile.h"
const int dbglvl = 400;
--
The overflow is triggered by your change to the fileset, which
increases the
size of the options list sent to the client.
__Martin
I'm just surprised the DEBUG build works then.
I'll just keep using the DEBUG build for now, but sounds like this
should be picked up
upstream.
And/Or @dvl@FreeBSD can pick it up for the FreeBSD port.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
> On Mon, 18 Jul 2022 09:18:17 -0500, Larry Rosenman said:
>
> On 07/18/2022 8:22 am, Martin Simmons wrote:
> >> On Sat, 16 Jul 2022 17:00:33 -0500, Larry Rosenman said:
> >>
> >> (gdb) bt full
> >> #0 kill () at kill.S:4
> >> No locals.
> >> #1 0x00088ad660a0 in __fail (
> >> msg=0x88ac6d34f "stack overflow detected; terminated")
> >> at /usr/src/lib/libc/secure/stack_protector.c:130
> >> sa = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction =
> >> 0x0},
> >>sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
> >> mask = {__bits = {4294967263, 4294967295, 4294967295,
> >> 4294967295}}
> >> #2 0x00088ad66010 in __stack_chk_fail ()
> >> at /usr/src/lib/libc/secure/stack_protector.c:137
> >> No locals.
> >> #3 0x00252e69 in send_include_list(JCR*) ()
> >> No symbol table info available.
> >> #4 0x0024241e in do_backup(JCR*) ()
> >> No symbol table info available.
> >> #5 0x00257307 in job_thread(void*) ()
> >> No symbol table info available.
> >> #6 0x0025d124 in jobq_server ()
> >> No symbol table info available.
> >> #7 0x000886269d08 in lmgr_thread_launcher ()
> >> from /usr/local/lib/libbac-13.0.0.so
> >> No symbol table info available.
> >> #8 0x0008869a496a in thread_start (curthread=0x89c8a7000)
> >> at /usr/src/lib/libthr/thread/thr_create.c:292
> >
> > It might be useful to also post the output of these three gdb commands
> > from
> > the core file:
> >
> > disass send_include_list
> > p __stack_chk_guard
> > x/256xg $sp
> >
> > __Martin
>
> https://www.lerctr.org/~ler/bacula-dir.gdb.txt
>
> too big for the list :)
Ok, that shows the problem. The function send_fileset in src/dird/fd_cmds.c
has an array called newopts on the stack, but it is too small so it overflows.
It is too small because fd_cmds.c includes findlib/find.h, which redefines
MAX_FOPTS with a value that is too small for this use. I don't see why
findlib/find.h needs to be included, so you could try the patch below:
--
--- src/dird/fd_cmds.c~ 2022-05-17 17:13:42.541093000 +0100
+++ src/dird/fd_cmds.c 2022-07-18 15:45:10.357144000 +0100
@@ -32,7 +32,7 @@
#include "bacula.h"
#include "dird.h"
-#include "findlib/find.h"
+#include "findlib/bfile.h"
const int dbglvl = 400;
--
The overflow is triggered by your change to the fileset, which increases the
size of the options list sent to the client.
__Martin
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Backups Won't Run, No Error Message
Hello, I'm having a strange problem. I have a bacula setup with a tape library and 3 drives. Backups on one of the drives are not working. No error message, the jobs just queue up and then don't run. They don't seem to select a volume. The problem is with my tape labelled LTO-5-1. Here is the status output: tape-lib-sd Version: 9.6.6 (20 September 2020) x86_64-pc-linux-gnu ubuntu 20.04 Daemon started 06-Jul-22 11:54. Jobs: run=73, running=11. Heap: heap=237,568 smbytes=2,637,125 max_bytes=5,625,790 bufs=671 max_bufs=1,694 Sizes: boffset_t=8 size_t=8 int32_t=4 int64_t=8 mode=0,0 newbsr=0 Res: ndevices=3 nautochgr=1 Running Jobs: Writing: Incremental Backup job webc-T JobId=22099 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=22 Writing: Incremental Backup job easyredmine JobId=22101 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=11 Writing: Incremental Backup job webc9 JobId=22100 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=12 Writing: Incremental Backup job gitea JobId=22103 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Writing: Incremental Backup job webc7 JobId=22102 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=24 Writing: Incremental Backup job webc6 JobId=22104 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=17 Writing: Incremental Backup job webc5 JobId=22105 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=23 Writing: Incremental Backup job webc4 JobId=22106 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=19 Writing: Incremental Backup job webc3 JobId=22107 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=21 Writing: Incremental Backup job webc2 JobId=22108 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=25 Writing: Incremental Backup job postgres114 JobId=22109 Volume="" pool="Inc-Pool-Tape" device="LTO-5-1" (/dev/nst1) spooling=0 despooling=0 despool_wait=0 Files=0 Bytes=0 AveBytes/sec=0 LastBytes/sec=0 FDReadSeqNo=6 in_msg=6 out_msg=5 fd=27 Jobs waiting to reserve a drive: Terminated Jobs: JobId Level Files Bytes Status Finished Name === 21924 Incr 0 0 Cancel 17-Jul-22 16:41 x 21927 Incr 0 0 Cancel 17-Jul-22 16:41 x 21920 Incr 0 0 Cancel 17-Jul-22 16:41 x 21930 Incr 0 0 Cancel 17-Jul-22 16:41 x 21931 Incr 0 0 Cancel 17-Jul-22 16:41 x 21926 Incr 0 0 Cancel 17-Jul-22 16:41 x 21928 Incr 0 0 Cancel 17-Jul-22 16:41 x 22096 Incr 0 0 Cancel 17-Jul-22 17:03 x 22097 Incr 0 0 Cancel 17-Jul-22 17:17 x 22098 Incr 0 0 Cancel 17-Jul-22 17:17 x Device status: Autochanger "Autochanger" with devices: "LTO-5-1" (/dev/nst1) "LTO-6-1" (/dev/nst0) "LTO-6-2" (/dev/nst2) Device Tape: "LTO-5-1" (/dev/nst1) is not open. Device is being initialized. Drive 0 is not loaded. == Device Tape is "LTO-6-1" (/dev/nst0) mounted with: Volume: 27L6 Pool: Full-Pool-Tape-LTO6 Media type: LTO-6 Total Bytes=1,131,097,734,144 Blocks=17,533,136 Bytes/block=64,512 Positioned at File=1,138 Block=0 Slot 24 is loaded in drive 1. == Device Tape: "LTO-6-2" (/dev/nst2) is not open. Drive 2 is not loaded. == === Used Volume status: Reserved volume: 02L5 on Tape device "LTO-5-1" (/dev/nst1) Reader=0 writers=0 reserves=11 volinuse=1 worm=0 Reserved volume: 27L6 on Tape device "LTO-6-1" (/dev/nst0) Reader=0 writers=0 reserves
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
OK. I just saw that dird/fd_cmds.c includes findlib/find.h and that findlib/find_one.c was significantly changed in 13.0. It is one of the few places alloca() is used. It might not even be related to alloca(), but that is a likely candidate for a stack-protector overflow detection. The detection is while already in do_backup(), so it wouldn't be in linb/parse_conf.c or tools/bsmtp.c and can't be any of the win32 stuff. findlib/mkpath.c is unchanged from 9.x. If it isn't in findlib, then that only leaves lib/bnet_server.c. Or else it isn't related to an alloca() call at all, An actual write out of bounds to a local variable would show up in all OSs, and I'm not sure what else would cause a stack-protector overflow detection. It just seems likely related to one of the alloca() calls. On 7/18/22 09:20, Martin Simmons wrote: I don't see how it can be related to find_one_file. The crash is happening in the director, but find_one_file is called in the client. __Martin On Mon, 18 Jul 2022 08:33:30 -0400, Josh Fisher said: So, v. 13.0 calls alloca() in the following source files: findlib/mkpath.c findlib/find_one.c lib/bnet_server.c lib/parse_conf.c tools/bsmtp.c tools/bsmtp.c win32/compat/compat.h win32/compat/compat.cpp win32/compat/compat.cpp win32/libwin32/statusDialog.cpp and that list is unchanged from the 9.x tree. The function that is blowing up appears to be called from send_include_list(), which is found in src/dird/fd_cmds.c. That file includes src/findlib/find.h. Checking the two source files in findlib, the mkpath.c code is unchanged from 9.x. However, the find_one.c file is significantly changed. Assuming that Bacula 9.x compiles and works on this same release of FreeBSD, (and is compiled with fstack-protector-strong), the most likely culprit is a change to src/findlib/find_one.c. I would first try putting some debug output around the find_one_file() function in find_one.c to see if it is blowing up there. The way alloca() works is that it increases the stack pointer and uses memory at the top (higher address) of the stack. then when the function exits, it automatically "frees" the stack-allocated memory by simply decreasing the stack pointer right before the normal function return code. So, it will also be necessary to put debug output around wherever find_one_file() is called, since the fault is likely occurring within one of the return statements in the find_one_file() function. On 7/17/22 13:29, Andrea Venturoli wrote: On 7/17/22 18:25, Larry Rosenman wrote: full build log for the DEBUG version: https://home.lerctr.org:/data/live-host-ports/2022-07-16_17h45m44s/logs/bacula13-server-13.0.0.log full build log for the NON-DEBUG version: https://home.lerctr.org:/data/live-host-ports/2022-07-15_12h19m17s/logs/bacula13-client-13.0.0.log So -fstack-protector-strong in both. bye & Thanks av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
On 07/18/2022 8:22 am, Martin Simmons wrote:
On Sat, 16 Jul 2022 17:00:33 -0500, Larry Rosenman said:
(gdb) bt full
#0 kill () at kill.S:4
No locals.
#1 0x00088ad660a0 in __fail (
msg=0x88ac6d34f "stack overflow detected; terminated")
at /usr/src/lib/libc/secure/stack_protector.c:130
sa = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction =
0x0},
sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
mask = {__bits = {4294967263, 4294967295, 4294967295,
4294967295}}
#2 0x00088ad66010 in __stack_chk_fail ()
at /usr/src/lib/libc/secure/stack_protector.c:137
No locals.
#3 0x00252e69 in send_include_list(JCR*) ()
No symbol table info available.
#4 0x0024241e in do_backup(JCR*) ()
No symbol table info available.
#5 0x00257307 in job_thread(void*) ()
No symbol table info available.
#6 0x0025d124 in jobq_server ()
No symbol table info available.
#7 0x000886269d08 in lmgr_thread_launcher ()
from /usr/local/lib/libbac-13.0.0.so
No symbol table info available.
#8 0x0008869a496a in thread_start (curthread=0x89c8a7000)
at /usr/src/lib/libthr/thread/thr_create.c:292
It might be useful to also post the output of these three gdb commands
from
the core file:
disass send_include_list
p __stack_chk_guard
x/256xg $sp
__Martin
https://www.lerctr.org/~ler/bacula-dir.gdb.txt
too big for the list :)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
> On Sat, 16 Jul 2022 17:00:33 -0500, Larry Rosenman said:
>
> (gdb) bt full
> #0 kill () at kill.S:4
> No locals.
> #1 0x00088ad660a0 in __fail (
> msg=0x88ac6d34f "stack overflow detected; terminated")
> at /usr/src/lib/libc/secure/stack_protector.c:130
> sa = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction =
> 0x0},
>sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
> mask = {__bits = {4294967263, 4294967295, 4294967295,
> 4294967295}}
> #2 0x00088ad66010 in __stack_chk_fail ()
> at /usr/src/lib/libc/secure/stack_protector.c:137
> No locals.
> #3 0x00252e69 in send_include_list(JCR*) ()
> No symbol table info available.
> #4 0x0024241e in do_backup(JCR*) ()
> No symbol table info available.
> #5 0x00257307 in job_thread(void*) ()
> No symbol table info available.
> #6 0x0025d124 in jobq_server ()
> No symbol table info available.
> #7 0x000886269d08 in lmgr_thread_launcher ()
> from /usr/local/lib/libbac-13.0.0.so
> No symbol table info available.
> #8 0x0008869a496a in thread_start (curthread=0x89c8a7000)
> at /usr/src/lib/libthr/thread/thr_create.c:292
It might be useful to also post the output of these three gdb commands from
the core file:
disass send_include_list
p __stack_chk_guard
x/256xg $sp
__Martin
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
I don't see how it can be related to find_one_file. The crash is happening in the director, but find_one_file is called in the client. __Martin > On Mon, 18 Jul 2022 08:33:30 -0400, Josh Fisher said: > > So, v. 13.0 calls alloca() in the following source files: > > findlib/mkpath.c > findlib/find_one.c > lib/bnet_server.c > lib/parse_conf.c > tools/bsmtp.c > tools/bsmtp.c > win32/compat/compat.h > win32/compat/compat.cpp > win32/compat/compat.cpp > win32/libwin32/statusDialog.cpp > > and that list is unchanged from the 9.x tree. > > The function that is blowing up appears to be called from > send_include_list(), which is found in src/dird/fd_cmds.c. That file > includes src/findlib/find.h. Checking the two source files in findlib, > the mkpath.c code is unchanged from 9.x. However, the find_one.c file is > significantly changed. > > Assuming that Bacula 9.x compiles and works on this same release of > FreeBSD, (and is compiled with fstack-protector-strong), the most likely > culprit is a change to src/findlib/find_one.c. I would first try putting > some debug output around the find_one_file() function in find_one.c to > see if it is blowing up there. > > The way alloca() works is that it increases the stack pointer and uses > memory at the top (higher address) of the stack. then when the function > exits, it automatically "frees" the stack-allocated memory by simply > decreasing the stack pointer right before the normal function return > code. So, it will also be necessary to put debug output around wherever > find_one_file() is called, since the fault is likely occurring within > one of the return statements in the find_one_file() function. > > > On 7/17/22 13:29, Andrea Venturoli wrote: > > > > On 7/17/22 18:25, Larry Rosenman wrote: > > > full build log for the DEBUG version: > > > > > https://home.lerctr.org:/data/live-host-ports/2022-07-16_17h45m44s/logs/bacula13-server-13.0.0.log > > > > > > full build log for the NON-DEBUG version: > > > > > https://home.lerctr.org:/data/live-host-ports/2022-07-15_12h19m17s/logs/bacula13-client-13.0.0.log > > > > > > > > So -fstack-protector-strong in both. > > > > bye & Thanks > > av. > > > > > > ___ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-dir: 13, crash on stackoverflow (FreeBSD)
So, v. 13.0 calls alloca() in the following source files: findlib/mkpath.c findlib/find_one.c lib/bnet_server.c lib/parse_conf.c tools/bsmtp.c tools/bsmtp.c win32/compat/compat.h win32/compat/compat.cpp win32/compat/compat.cpp win32/libwin32/statusDialog.cpp and that list is unchanged from the 9.x tree. The function that is blowing up appears to be called from send_include_list(), which is found in src/dird/fd_cmds.c. That file includes src/findlib/find.h. Checking the two source files in findlib, the mkpath.c code is unchanged from 9.x. However, the find_one.c file is significantly changed. Assuming that Bacula 9.x compiles and works on this same release of FreeBSD, (and is compiled with fstack-protector-strong), the most likely culprit is a change to src/findlib/find_one.c. I would first try putting some debug output around the find_one_file() function in find_one.c to see if it is blowing up there. The way alloca() works is that it increases the stack pointer and uses memory at the top (higher address) of the stack. then when the function exits, it automatically "frees" the stack-allocated memory by simply decreasing the stack pointer right before the normal function return code. So, it will also be necessary to put debug output around wherever find_one_file() is called, since the fault is likely occurring within one of the return statements in the find_one_file() function. On 7/17/22 13:29, Andrea Venturoli wrote: On 7/17/22 18:25, Larry Rosenman wrote: > full build log for the DEBUG version: > https://home.lerctr.org:/data/live-host-ports/2022-07-16_17h45m44s/logs/bacula13-server-13.0.0.log > > full build log for the NON-DEBUG version: > https://home.lerctr.org:/data/live-host-ports/2022-07-15_12h19m17s/logs/bacula13-client-13.0.0.log So -fstack-protector-strong in both. bye & Thanks av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
