[Samba] Samba 4.4.5 exists with segmention fault on FreeBSD 10.3 during domain provision

[David STIEVENARD]

Hi Michael,

I'm facing the same problem, samba 4.4.x is apparently broken on FreeBSD 
for now.
Here's a link to the bug 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209787

For now the port maintainer seem out of ideas to fix this. You seems 
more skilled then me on freebsd, maybe you can help him on this bug :)


DS



On 07/20/2016 02:17 AM, Michael Osipov wrote:
> Hi folks,
>
> I am trying to set up a domain/forest in VirtualBox server.
> My setup:
> * # uname -a
>   FreeBSD bsd1dc.ad001.osipov.eu 10.3-RELEASE-p4 FreeBSD 
> 10.3-RELEASE-p4 64 bit
> * Samba 4.4.5 from Ports tree
>   # samba-tool -V
>   4.4.5
> * Python 2 from Ports tree
>   # python2 --version
>   Python 2.7.12
>
> Installation went smoothly but during domain provisioning Python fails 
> with a segmentation fault and leaves a core dump file.
>
> The very last output of samba-tool:
> store_acl_blob_fsp: storing blob length 356 on file 
> /var/db/samba4/sysvol/ad001.osipov.eu/Policies
> delete_windows_lock_ref_count for file 
> /var/db/samba4/sysvol/ad001.osipov.eu/Policies
> Speicherschutzverletzung(core dumped)
>
> Running the same operation again with truss:
> write(2,"store_acl_blob_fsp: storing blob"...,99) = 99 (0x63)
> extattr_set_fd(0xf,0x1,0x827447cbf,0x825859760,0x164) = 356 (0x164)
> write(2,"delete_windows_lock_ref_count fo"...,86) = 86 (0x56)
> close(15)                                        = 0 (0x0)
> umask(0x12)                                      = 0 (0x0)
> fcntl(10,F_SETLKW,0x7fffffffcba8)                = 0 (0x0)
> fcntl(10,F_SETLKW,0x7fffffffcc48)                = 0 (0x0)
> fcntl(12,F_SETLK,0x7fffffffbdf8)                 = 0 (0x0)
> fcntl(12,F_SETLKW,0x7fffffffbe78)                = 0 (0x0)
> fcntl(12,F_SETLKW,0x7fffffffbee8)                = 0 (0x0)
> fcntl(11,F_SETLK,0x7fffffffcd28)                 = 0 (0x0)
> fcntl(11,F_SETLKW,0x7fffffffcda8)                = 0 (0x0)
> fcntl(11,F_SETLKW,0x7fffffffce18)                = 0 (0x0)
> SIGNAL 11 (SIGSEGV)
> process killed, signal = 11 (core dumped)
>
> Loading the core dump in GDB (command 'where') gives me:
> #0  0x0000000806e5ba6e in ndr_pull_uint8 (ndr=0x833ce82e0, ndr_flags=256,
>     v=0x7fffffffcc5f "") at ../librpc/ndr/ndr_basic.c:82
> #1  0x0000000806e5f133 in ndr_pull_enum_uint8 (ndr=0x833ce82e0, 
> ndr_flags=256,
>     v=0x7fffffffcc5f "") at ../librpc/ndr/ndr_basic.c:346
> #2  0x000000080708bf95 in ndr_pull_security_descriptor_revision (
>     ndr=0x833ce82e0, ndr_flags=256, r=0x832200480)
>     at default/librpc/gen_ndr/ndr_security.c:657
> #3  0x000000080708ccb7 in ndr_pull_security_descriptor (ndr=0x833ce82e0,
>     ndr_flags=768, r=0x832200480) at 
> default/librpc/gen_ndr/ndr_security.c:768
> #4  0x0000000806e692f6 in ndr_pull_struct_blob_all (blob=0x7fffffffce08,
>     mem_ctx=0x8021fb100, p=0x832200480,
>     fn=0x80708cbb0 <ndr_pull_security_descriptor>) at 
> ../librpc/ndr/ndr.c:1133
> #5  0x0000000811761084 in py_security_descriptor_ndr_unpack (
>     py_obj=0x82607bf50, args=0x817a7aa10, kwargs=0x82607d398)
>     at default/librpc/gen_ndr/py_security.c:1518
> ..
>
> Both, truss output and core dump can be provided.
>
> What can I do about this crash? Downgrade Python?
>
> Help is pretty much appreciated.
>
> Michael
>