Solved Samba41 segfault after 10.1-RELEASE upgrade

[Hanky-panky]

I read a lot about this issue, before someone ask.

Samba41 from ports build pretty fine. No problem at all. It used to work before the upgrade from 10-RELEASE to 10.1-RELEASE, now it wont.

I had problem upgrading because of the freebsd-update(8) broken problem.

To be sure to have a consistent system I had also rebuilt all this system from scratch, starting from a subversion clean source and building and installing kernel and world.

My actual system level is:

FreeBSD freebsd101 10.1-RELEASE FreeBSD 10.1-RELEASE #3 r281227: Wed Apr  8 09:59:13 CEST 2015     root@freebsd101:/usr/obj/usr/src/sys/GENERIC  i386

Everything went perfectly fine. I then rebuilt all the ports and everything went fine again but Samba41

Samba41 build and install perfectly fine too, then it wont start because it fails testparm sanity check. Testparm segfault (signal 11) and so many of the others Samba41 utility like smbclient, smbpasswd, smbstatus and so on.

I deleted everything Samba related from the disk and reinstalled from scratch: same results, install went fine, every Samba41 segfaults (always signal 11).

If I do delete Samba41 and I do install Samba36, Samba36 doesn't have this problem: it works perfectly with the same smb.conf on the same system.

I try to rebuild smb.conf with a minimal one: no joy: Samba41 still and always segfaults.

I read a lot about the subject, then nothing of the known cure seems to fix this system.

Someone said it could be a Python27 problem so I deleted my Python27 (perfectly working with any other program in this system) and rebuild it from scratch too: still no joy.

I try to use gdb to debug the problem, then it seems there is nothing useful (or I can understand) on that code:

gdb testparm
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) core testparm.core
Core was generated by `testparm'.
Program terminated with signal 11, Segmentation fault.
#0  0x21d731b5 in ?? ()
(gdb) backtrace
#0  0x21d731b5 in ?? ()
#1  0x21f129d0 in ?? ()
#2  0x00000000 in ?? ()
(gdb)

I'm out of ideas. Can someone help me?

I have to say I do not have this same problem on similar other 10.1-RELEASE machines upgraded via subversion after a broken freebsd-update(8), so there is something wrong with this failing machine related with Samba41, then It seems I'm unable to find and fix the problem.

 

[talsamon]

/usr/ports/UPDATING

20100206:
AFFECTS: users of net/samba4-devel
AUTHOR: timur@FreeBSD.org

Default configuration file was moved to ${LOCALBASE}/etc/smb4.conf to
avoid conflicts with the installed net/samba3?. Also, userland utils
are not installed by default, which should also help with the parallel
setup of Samba3 and Samba4.

Maybe it could be this => smb4.conf?

 

[Hanky-panky]

/usr/ports/UPDATING


Maybe it could be this => smb4.conf?

No. It wasn't. I've been able to trace the problem using gdb(1) and is related with Python2.7 and Openssl.

Here what I found using gdb(1) against the command:

samba-tool testparm

gdb python2.7
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
(gdb) core python2.7.core
Core was generated by `python2.7'.
Program terminated with signal 11, Segmentation fault.

(snip of some loading data because the message board complain about message too big)

Loaded symbols for /libexec/ld-elf.so.1
#0  0x28f5a1b5 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8
[New Thread 28803080 (LWP 101377/python2.7)]
(gdb) backtrace
#0  0x28f5a1b5 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8
#1  0x2a7e7c6b in OPENSSL_cpuid_setup () from /lib/libcrypto.so.7
#2  0x2a6e2f09 in _init () from /lib/libcrypto.so.7
#3  0x00000000 in ?? ()
(gdb)

If I do delete external Openssl installed port, it segfaults then it complain about missing libssl.so. If I do reinstall all the ports involved (including Python2.7), it segfaults again.

Backtrace said also something about ia32_cpuid and cpuid_setup then I do have no idea about how to fix all this. I hope someone can help.

 

[Hanky-panky]

Fixed. I had a moment to read everything I could find about the last lines of my backtrace of Samba41 segfault and it turned to be this:

From FreeBSD list:

On Apr 10 17:07, Dewayne Geraghty wrote:
>part of the base system. If your system is crashing due to /usr/bin/vi
>which is part of the base system, then something is very wrong with the>system. I'm guessing but is it possible that you've installed 32 libs>onto a 64 base system, or the other way around?>>I can't see how vi needs anything under /usr/local, as its from the>"base" system - so I guess others may need to step up to assist.
See the comments in the PR at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788

It appears that on certain hardware compiling openssl 1.0.2 with the ASM
optimisations turned on, which is the default, can cause all sorts of
strange issues. I had the same issues with vi, bash, and all sorts of
things both in the base system and the ports system. I have no idea why
or how. But disabling ASM and recompiling it works around the issue.

It seems to completely corrupt the environment.

Matt

I can't believe that FreeBSD-10.1-RELEASE was such a problematic and buggy release, incorporating so much incompatibility problems with external programs and options. And I won't even talk about the freebsd-update(8) nasty bug. It is simply incredible they do not put a clear statement about the problem of this software on them site home page or turning it off the service because it is buggy and it create headache and problems to people using it for good.