On 7/17/22 06:10, Andrea Venturoli wrote:
On 7/16/22 19:07, Larry Rosenman wrote:
msg=0x88ac6d34f "stack overflow detected; terminated")
at /usr/src/lib/libc/secure/stack_protector.c:130
#2 0x000000088ad66010 in __stack_chk_fail ()
at /usr/src/lib/libc/secure/stack_protector.c:137
#3 0x0000000000252e69 in send_include_list(JCR*) ()
#4 0x000000000024241e in do_backup(JCR*) ()
#5 0x0000000000257307 in job_thread(void*) ()
#6 0x000000000025d124 in jobq_server ()
#7 0x0000000886269d08 in lmgr_thread_launcher ()
from /usr/local/lib/libbac-13.0.0.so
#8 0x00000008869a496a in thread_start (curthread=0x89c8a7000)
at /usr/src/lib/libthr/thread/thr_create.c:292
#9 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x89d7fa000
(gdb)
Ideas?
Yes... just speculation, though...
I guess Bacula is compiled with -fstack-protector, so canaries are
inserted to make it crash, if the stack is overwritten.
I think this is the default in FreeBSD, in order to prevent security
issues,
Bacula has had false-positive issues with similar buffer overrun
protections before, in particular -DNOTIFY_SOURCE. I'm not sure about
fstack-protector, nor am I sure that is true for version 13.x, but
Bacula uses its own memory handling functions, so can easily confuse
those compiler/glibc protections. It would also explain why the debug
version works without issues, since the debug version will have those
protections (and many optimizations) disabled. Does Bacula's configure
script generate a fstack-protector flag? If not, then I would try it
without fstack-protector or even try with -fno-stack-protector. If that
works, then I would think it a false positive. If there truly is a stack
overflow in the code, then it should be showing up on other platforms as
well. The fstack-protector flag is not unique to freebsd, but it might
be implemented differently than other platforms.
Basically, at the point when you have the core, the damage is already
done and you'll have to investigate what happens before: somewhere
there must be an out-of-bound write (possibly in bacula code, in
FreeBSD's code or in a library in between).
Normally I'd try valgrind, but running Bacula on it would probably
take eons (and given it's a network based thing, some timeout will
probably get in the way).
Compiling with -fsanitize=address might be a better option, but I
admit I never used it, so I'm speaking by hearsay.
Otherwise you'll have to pinpoint this the hard way, with gdb,
breakpoints, etc...
just to make life more annoying, I rebuilt bacula13-server with
DEBUG, and now it works without aborting.
:-(
bye
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
