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:8888/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:8888/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
