IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Print the talloc full report into a FILE*. talloc itself provides a
very similar function, talloc_report_full(). However, that has a
slightly different output, in particular it does not print the
contents of strings, which is very handy for debugging.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
These date back to 3a9beef2b7b25427ee4611cfc375e05cc82a1150 in 2003 and
829e72fe9c97feaa3d45b768984a4c47b906a23a in 1998 and appear to be related
to smbwrapper.
More of these should be removed but the getdirents() test caused a timeout
on an ARM builder in Debian. It might just be a fluke but the tests are
pointless regardless.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Tue Sep 17 13:48:18 UTC 2019 on sn-devel-184
clang is not happy when it sees another main nested inside the main
function and fails the test for prctl syscall, therefore avoid adding
implicit main() here
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Fri Sep 13 12:33:32 UTC 2019 on sn-devel-184
Originally this parameter only set two other parameters, but never set
the original string. By setting the string as well, we can make it be
emitted by testparm -v correctly (instead of ''), and set it back as the
value for the parameter.
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Probably not required, but looks safer and gives static checkers less
reason to complain about potentially uninitialized variable reads
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
At least as of 2ac9d0afa66 ctdb does not care about db prios anymore
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This hopefully fixes a lot of coverity defects like:
Control flow issues (DEADCODE)
Execution cannot reach this statement: ";".
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
* Update waf to version 2.0.17 in order to
fix the build with python 3.8.
* Other minor build fixes.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Wed Sep 4 11:47:04 UTC 2019 on sn-devel-184
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Björn Jacke <bjacke@samba.org>
Autobuild-Date(master): Thu Aug 29 17:10:32 UTC 2019 on sn-devel-184
AIX requires the flags to be 0, we need to do those checks manually.
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
FreeBSD and AIX already set errno to ENAMETOOLONG, this is what we should map
other platforms also to to finally map to the correct NT error code also.
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The print functions used in Samba NULL terminate, but do not assume they will
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14049
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
This is beyond the normal level of clarity we expect in Samba, and is of course
rudundent, but this is a complex routine that has confusing tests, some of
pointers and some of boolean state values.
This tries to make the code as clear as possible pending a more comprehensive
rewrite.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14049
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14049
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14049
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Tue Aug 27 01:16:33 UTC 2019 on sn-devel-184
This is a macro that sets the pointer to NULL after the talloc_free()
and is part of our standard coding practices.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Thankfully this only fails if the DB is corrupt and has a duplicate record.
The test was at the wrong end of the loop, and was for the
wrong boundary condition. A write after the end of the array would
occour before the condition was hit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13695
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Fix the lmdb size test which ensures that databases > 4GiB can be
written by the lmdb backend. This test is not run as part of the normal
CI run as it exhausts the available disk on the test runners.
It was broken by changes to LDB allowing the lmdb map size to be
specified, and requiring GUID indexing by default.
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Commit e45d33e9 removed the sync fallback path for the case that no
thread could be created. Remove the comment for that fallback as it does
not make sense anymore.
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
Autobuild-User(master): Christof Schmitt <cs@samba.org>
Autobuild-Date(master): Fri Aug 23 23:09:12 UTC 2019 on sn-devel-184
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Aug 22 21:24:00 UTC 2019 on sn-devel-184
If done with popt context it should be free'd.
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Aug 22 01:41:37 UTC 2019 on sn-devel-184
This requires GnuTLS >= 3.6.5.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Wed Aug 21 11:14:11 UTC 2019 on sn-devel-184
Samba will soon require GnuTLS >= 3.4.7.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Adjusted by Andrew Bartlett from an earlier more comprehensive patch by Andreas
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Direct leak of 1152 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392cfd59 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392cfd59 in _talloc_pool ../../talloc.c:837
#3 0x7f06392cfd59 in talloc_pool ../../talloc.c:859
#4 0x40b83c in test_magic_protection ../../testsuite.c:1960
#5 0x40b83c in torture_local_talloc ../../testsuite.c:2164
#6 0x402603 in main ../../testsuite_main.c:32
#7 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 100 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392d1af3 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392d1af3 in __talloc ../../talloc.c:824
#3 0x7f06392d1af3 in __talloc_strlendup ../../talloc.c:2455
#4 0x7f06392d1af3 in talloc_strdup ../../talloc.c:2471
#5 0x40b4f0 in test_rusty ../../testsuite.c:1543
#6 0x40b4f0 in torture_local_talloc ../../testsuite.c:2146
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392d0c45 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392d0c45 in __talloc ../../talloc.c:824
#3 0x7f06392d0c45 in _talloc_named_const ../../talloc.c:981
#4 0x7f06392d0c45 in talloc_named_const ../../talloc.c:1748
#5 0x40901e in test_pool_nest ../../testsuite.c:1451
#6 0x40901e in torture_local_talloc ../../testsuite.c:2096
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fd52c00dc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7fd52befec45 in __talloc_with_prefix ../../talloc.c:782
#2 0x7fd52befec45 in __talloc ../../talloc.c:824
#3 0x7fd52befec45 in _talloc_named_const ../../talloc.c:981
#4 0x7fd52befec45 in talloc_named_const ../../talloc.c:1748
#5 0x4099bd in test_realloc_on_destructor_parent ../../testsuite.c:1000
#6 0x4099bd in torture_local_talloc ../../testsuite.c:2129
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7fd52bcb8412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
* Build fixes
* Improve the performance by inlining the tdb_oob() checks
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Tue Aug 20 14:45:41 UTC 2019 on sn-devel-184
The msg for each database record is allocated on the module context, but
never freed. The module seems like it could be a long-running context (as
the database would normally get repacked by the samba executable).
Even if it's not a proper leak, it shouldn't hurt to cleanup the memory.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14059
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Autobuild-User(master): Garming Sam <garming@samba.org>
Autobuild-Date(master): Tue Aug 20 04:57:10 UTC 2019 on sn-devel-184
Firstly, with Samba AD this looks a little weird because we log the same
message 5 times (once for every partition). If we log that we're doing
this to records in different partitions, hopefully someone with a little
Samba knowledge can figure out what's going on.
Secondly, the info about what partitions are actually changing might be
useful. E.g. if we hit a fatal error repacking the 3rd partition, and
the transaction doesn't abort properly, then it would be useful to know
what partitions were repacked and which ones weren't.
There doesn't appear to be a useful name for the partition
(ldb_kv->kv_ops->name() doesn't seem any more intelligible to a user),
so just log the first record that we update. We can use that to infer
the partition database).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14059
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The "format 0x26011968" log confused me (and I'm a developer).
We can subtract the base offset from the pack format to get a more
user-friendly number, e.g. v0 (not actually used), v1, v2, etc.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14059
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The main reason is so that any future pack formats will continue
incrementing this number in a sequential fashion.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14059
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
