On 5/8/19 1:44 PM, Jan Beich wrote:
Hello.
While I am by no means at the end of this, I'll post some updates.
> "stack overflow detected" messages are part of -fstack-protector*.
> Recently, ports/ default changed to -strong in order to follow base/.
>
> https://svnweb.freebsd.org/changeset/ports/499897
Reading the description of -fstack-protector vs
-fstack-protector-strong, it shouldn't make any difference in this function.
I tried "SSP_CFLAGS?= -fstack-protector" for confirmation and the canary
is still there.
So that changeset cannot be the culprit.
I do no dare trying "SSP_UNSAFE= yes", because, in case it's really a
buffer overflow, I prefer a core to undefined behaviour on production
servers!
Perhaps it's lack of imagination on my part, but I fail to see how SSP
could give a false positive...
Besides there are other hints which make me suspect a buffer overflow is
really happening.
> If neither DEBUG port option nor WITH_DEBUG make variable provide symbols
> then file a bug.
The DEBUG option is there and works (using base GDB had me think
otherwise, but after switching to devel/gdb I can see debug info).
However, ports seem to compile with -O2, which sometimes makes it hard
to unterstand what's going on; so I added "CFLAGS=
-O0" to Makefile.
Putting that binary (with -O0) in production on one server has halted
the stream of cores, at least for now: I had about one core per minute
before; now it has been working fine for 30 minutes.
The other server which shows this problem is not dumping cores right now.
I'm not saying it's solved, however, since these dumps in the past have
stopped appearing several times, and later started happening again; so
I'll have to keep an eye on this.
(My wild guess, but I'm not sure, is that this happens when a client
needs to change its trust password: it tries again and again, and if it
eventually succeeds, then I don't get any more core until another client
needs this).
> In addition to debug symbols try building with -fsanitize=address in
> order to save time finding a place where the overflow occurs.
I wanted to try this, but ended up with an error during "make configure":
----------------------------------------
Checking simple C program
==>
#define CONFIG_H_IS_FROM_SAMBA 1
#define _SAMBA_BUILD_ 4
#define HAVE_CONFIG_H 1
#define SRCDIR "/usr/ports/net/samba48/work/samba-4.8.12"
#define HAVE_SYS_UTSNAME_H 1
/* #undef SYSTEM_UNAME_SYSNAME */
/* #undef SYSTEM_UNAME_MACHINE */
/* #undef SYSTEM_UNAME_RELEASE */
/* #undef SYSTEM_UNAME_VERSION */
#define HAVE_STDIO_H 1
#include <stdio.h>
int main(void) { printf("hello world"); return 0; }
<==
[1/2] Compiling test.c
['cc', '-O2', '-pipe', '-fsanitize=address', '-DLIBICONV_PLUG',
'-fno-color-diagnostics', '-fstack-protector-strong',
'-DLDAP_DEPRECATED', '-isystem', '/usr/local/include',
'-fno-strict-aliasing', '-fno-omit-frame-pointer',
'-I/usr/ports/net/samba48/work/samba-4.8.12/lib/replace/../../buildtools/wafsamba',
'-MD', '-Idefault', '-I..', '-Idefault', '-I..', '-DLIBICONV_PLUG',
'-isystem', '/usr/local/include', '-D_SAMBA_BUILD_=4',
'-DHAVE_CONFIG_H=1', '../test.c', '-c', '-o', 'default/test_1.o']
[2/2] Linking default/testprog
default/test_1.o: In function `asan.module_ctor':
test.c:(.text+0x22): undefined reference to `__asan_init'
test.c:(.text+0x27): undefined reference to
`__asan_version_mismatch_check_v8'
test.c:(.text+0x36): undefined reference to `__asan_register_globals'
default/test_1.o: In function `asan.module_dtor':
test.c:(.text+0x4c): undefined reference to `__asan_unregister_globals'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
['cc', 'default/test_1.o', '-o',
'/usr/ports/net/samba48/work/samba-4.8.12/bin/.conf_check_0/testbuild/default/testprog',
'-fstack-protector-strong', '-L/usr/local/lib']
bye & Thanks
av.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
