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,
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
