Bug 11848 - 4.4.x port on FreeBSD
Summary: 4.4.x port on FreeBSD
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.4.2
Hardware: x64 FreeBSD
: P5 major (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2016-04-18 06:54 UTC by Dron
Modified: 2017-06-28 09:51 UTC (History)
4 users (show)

See Also:

Log of provision output (1.06 KB, text/plain)
2016-04-18 06:59 UTC, Dron
no flags Details
full gdb output (40.79 KB, text/plain)
2016-04-18 07:00 UTC, Dron
no flags Details
full gdb output with bt full (44.81 KB, text/plain)
2016-06-16 06:39 UTC, Dron
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dron 2016-04-18 06:54:11 UTC
Hello all.
I am trying to create port for 4.4.x branch at FreeBSD 10.3 x64, based on Timur's 4.3.x port.
I tried 4.4.0 and after badlock - 4.4.2 but got this error while trying domain provision:

#0  0x0000000806c5ba6e in ndr_pull_uint8 (ndr=0x82a098ce0, ndr_flags=256, v=0x7fffffffcc2f "")
    at ../librpc/ndr/ndr_basic.c:82
82              *v = CVAL(ndr->data, ndr->offset);
[New Thread 801c06400 (LWP 100086/<unknown>)]
(gdb) bt
#0  0x0000000806c5ba6e in ndr_pull_uint8 (ndr=0x82a098ce0, ndr_flags=256, v=0x7fffffffcc2f "")
    at ../librpc/ndr/ndr_basic.c:82
#1  0x0000000806c5f133 in ndr_pull_enum_uint8 (ndr=0x82a098ce0, ndr_flags=256, v=0x7fffffffcc2f "")
    at ../librpc/ndr/ndr_basic.c:346
#2  0x0000000806e8bec5 in ndr_pull_security_descriptor_revision (ndr=0x82a098ce0, ndr_flags=256,
    r=0x8264f18e0) at default/librpc/gen_ndr/ndr_security.c:657
#3  0x0000000806e8cbe7 in ndr_pull_security_descriptor (ndr=0x82a098ce0, ndr_flags=768, r=0x8264f18e0)
    at default/librpc/gen_ndr/ndr_security.c:768
#4  0x0000000806c692f6 in ndr_pull_struct_blob_all (blob=0x7fffffffcdd8, mem_ctx=0x801e11340,
    p=0x8264f18e0, fn=0x806e8cae0 <ndr_pull_security_descriptor>) at ../librpc/ndr/ndr.c:1133
#5  0x0000000811c11084 in py_security_descriptor_ndr_unpack (py_obj=0x81cc86050, args=0x812f66350,
    kwargs=0x81ccd0050) at default/librpc/gen_ndr/py_security.c:1518
#6  0x0000000800b2dd0d in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so.1
#7  0x0000000800b266a4 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.7.so.1
#8  0x0000000800b32f99 in _PyEval_SliceIndex () from /usr/local/lib/libpython2.7.so.1

I am tried to compile samba from sources and in this case domain provision completes without this error.
ldb, tdb, talloc and tevent are independent ports in FreeBSD, but they are latest versions.
Comment 1 Dron 2016-04-18 06:59:51 UTC
Created attachment 12003 [details]
Log of provision output
Comment 2 Dron 2016-04-18 07:00:39 UTC
Created attachment 12004 [details]
full gdb output
Comment 3 Dron 2016-04-20 06:43:03 UTC
ldb, tdb, talloc and tevent are independent ports in FreeBSD, but they are latest versions.

I mean, that ports were updated to the lastest versions from corresponding sites.
Comment 4 Dron 2016-06-15 10:42:14 UTC
While I take some pause, Timur created Samba 4.4 port on FreeBSD.
I compiled it and got same situation with domain provision.
Comment 5 Dron 2016-06-16 06:39:45 UTC
Created attachment 12182 [details]
full gdb output with bt full
Comment 6 Andreas Schneider 2016-06-16 07:17:15 UTC
In frame 5:

(gdb) p blob
$2 = {data = 0x800000000 <Address 0x800000000 out of bounds>, length = 432}

py_security_descriptor_ndr_unpack() calls PyArg_ParseTupleAndKeywords() which succeeds but produces a broken pointer.
Comment 7 Dron 2016-06-29 13:07:51 UTC
Hello. Any updates?
I can provide access to VM with FreeBSD and Samba port if this can help.
Comment 8 Michael Osipov 2016-07-21 13:33:18 UTC
I can also confirm this issue. Reported to the mailing list:

Copying information:

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)
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.
Comment 9 Dron 2016-12-06 11:45:51 UTC
Any news about this situation?
Comment 10 Andrew Bartlett 2017-01-03 09:00:09 UTC
(In reply to Dron from comment #9)
We think the the issue is with Python (why are we being handed garbage pointers), but it is hard to understand what is going on.
Comment 11 Dron 2017-03-28 10:39:45 UTC
Issue was with PIDL. In FreeBSD it was as separate port for it and PIDL was used from 4.3 branch. Switching to PIDL bundled with samba resolved issue.
4.5 and 4.6 ports are using bundled version of PIDL.
Comment 12 Andrew Bartlett 2017-06-28 09:51:10 UTC
Given comment #11, I'm closing as invalid.  There have been genuine issues with FreeBSD and PIDL, but this one isn't it if the branches are being mixed up.

Samba must build with the in-tree PIDL.