On 7/17/22 15:34, Josh Fisher wrote:
Bacula has had false-positive issues with similar buffer overrun
protections before,
Hmm... -fstack-protector just put canaries around the stack and verifies
they are still there and intact.
If the stack canary is corrupt, then IMO an overrun has definitely happened.
(I know there are exceptions, but they should be "rare circumstances").
Bacula uses its own memory handling functions,
For the stack???
Maybe for the heap?
without issues, since the debug version will have those
protections (and many optimizations) disabled.
I'm not sure.
Maybe Larry can check the build log, but I believe -fstack-protector
would be there even when compiling with debug symbols and without
optimizations.
Can you check, Larry?
Does Bacula's configure script generate a fstack-protector flag?
Usually it's the FreeBSD ports system that adds that (unless a port
defines SSP_UNSAFE).
If there truly is a stack
overflow in the code, then it should be showing up on other platforms as
well.
Not necessarily.
As I said it needn't be Bacula itself that has a bug.
(I once had this problem with Samba and it turned down it was a FreeBSD
system library that had an off-by-one bug, so the crash couldn't
possibly be reproduced on other platforms).
bye
av.
P.S. Personally, rather than disabling stack protections, I'd run a
DEBUG binary if that works. I don't think the lack of optimizations will
be that relevant, given network and disks will still be the bottlenecks.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
