Date: Mon, 04 May 2015 09:50:53 +0200 From: Stefan Esser <se@freebsd.org> To: Ports FreeBSD <freebsd-ports@FreeBSD.org> Subject: Problem with Samba-4.1 on -CURRENT Message-ID: <554724DD.7090709@freebsd.org>
next in thread | raw e-mail | index | archive | help
I've recently tried Samba-4.1 as a replacement for 3.6, but cannot get
it to work. I'm seeing SIGABRT being triggered, probably due to a
problem in MD5Final().
I'm seeing the same kind of abort in
- smbd
- smbclient
- smbclient4
E.g.:
# smbclient4 -U guest -L localhost
Password for [WORKGROUP\guest]:
Abort trap (core dumped)
The following error messages are logged when I try to access a Samba
share from a windows system:
May 4 08:37:23 dummy smbd[26018]: stack overflow detected; terminated
pid 26019 (smbd), uid 0: exited on signal 6
May 4 08:37:23 dummy smbd[26019]: stack overflow detected; terminated
pid 26020 (smbd), uid 0: exited on signal 6
May 4 08:37:23 dummy smbd[26020]: stack overflow detected; terminated
pid 26021 (smbd), uid 0: exited on signal 6
May 4 08:37:23 dummy smbd[26021]: stack overflow detected; terminated
pid 26022 (smbd), uid 0: exited on signal 6
...
Execution of smbclient in a debugger leads to:
(lldb) bt
* thread #1: tid = 101459, 0x000000080437a3aa libc.so.7`kill + 10, stop
reason = signal SIGABRT
* frame #0: 0x000000080437a3aa libc.so.7`kill + 10
frame #1: 0x000000080437a360 libc.so.7`??? + 144
frame #2: 0x000000080437a2d0 libc.so.7`__stack_chk_fail + 16
frame #3: 0x000000080169d66d libsamba-util.so.0`hmac_md5_final
(digest=0x00007fffffffd4a0, ctx=0x00007fffffffd2e8) + 141 at hmacmd5.c:102
(Running under control of system GDB and GDB-7.9 behave the same as
under LLDB.)
This happens on a -CURRENT amd64 system with a port compiled with
default options. Both GCC-4.8 and system CLANG have been used to
build the port - with identical results.
The Samba-4.1 port uses -fstack-protector, and it seems that the stack
is really corrupted, when execution stops. But I did not have time to
check why this happens.
Does anybody have an idea what's going wrong?
(One thought is that there might be several implementations of MD5Final
with different definitions of "struct ctx" ...)
I'll create a PR with all information I'm able to gather, if this is
a real problem (and not one that only exists in my environment).
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?554724DD.7090709>