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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
in run_opentest()
While fixing this, also convert to using talloc_asprintf instead.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Christian Ambach <ambi@samba.org>
running smbtorture test base.bench-holdopen.bench-holdopen yields the
following valgrind trace.
==29953== Conditional jump or move depends on uninitialised value(s)
==29953== at 0xF4634F0: _talloc_zero_array (in /usr/lib64/libtalloc.so.2.1.5)
==29953== by 0x5AE257E: smbcli_request_setup_transport (rawrequest.c:101)
==29953== by 0x5AE04AF: smb_raw_echo_send (clitransport.c:554)
==29953== by 0x5AE0774: smb_raw_echo (clitransport.c:609)
==29953== by 0x4183D3: torture_holdopen (misc.c:288)
==29953== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==29953== by 0x955368F: internal_torture_run_test (torture.c:442)
==29953== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==29953== by 0x2600A4: run_matching (smbtorture.c:110)
==29953== by 0x25FF66: run_matching (smbtorture.c:95)
==29953== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==29953== by 0x261E44: main (smbtorture.c:665)
==29953==
==29953== Conditional jump or move depends on uninitialised value(s)
==29953== at 0xF4630E3: _talloc_zero (in /usr/lib64/libtalloc.so.2.1.5)
==29953== by 0x5AE257E: smbcli_request_setup_transport (rawrequest.c:101)
==29953== by 0x5AE04AF: smb_raw_echo_send (clitransport.c:554)
==29953== by 0x5AE0774: smb_raw_echo (clitransport.c:609)
==29953== by 0x4183D3: torture_holdopen (misc.c:288)
==29953== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==29953== by 0x955368F: internal_torture_run_test (torture.c:442)
==29953== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==29953== by 0x2600A4: run_matching (smbtorture.c:110)
==29953== by 0x25FF66: run_matching (smbtorture.c:95)
==29953== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==29953== by 0x261E44: main (smbtorture.c:665)
==29953==
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
smbtorture test base.winattr.winattr yields the following trace
==25514== Syscall param writev(vector[...]) points to uninitialised byte(s)
==25514== at 0xFBA2C87: writev (in /lib64/libc-2.19.so)
==25514== by 0x106CB033: writev_handler (async_sock.c:340)
==25514== by 0xF67812A: ??? (in /usr/lib64/libtevent.so.0.9.26)
==25514== by 0xF6765F6: ??? (in /usr/lib64/libtevent.so.0.9.26)
==25514== by 0xF6727FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.26)
==25514== by 0x5AE3400: smbcli_request_receive (rawrequest.c:416)
==25514== by 0x5AEEC7E: smb_raw_nttrans_recv (rawtrans.c:408)
==25514== by 0x5AF6543: smb_raw_query_secdesc_recv (rawacl.c:67)
==25514== by 0x5AF580F: smb_raw_fileinfo_recv (rawfileinfo.c:699)
==25514== by 0x5AF58BE: smb_raw_fileinfo (rawfileinfo.c:721)
==25514== by 0x454AC3: torture_winattrtest (attr.c:217)
==25514== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==25514== by 0x955368F: internal_torture_run_test (torture.c:442)
==25514== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==25514== by 0x2600A4: run_matching (smbtorture.c:110)
==25514== by 0x25FF66: run_matching (smbtorture.c:95)
==25514== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==25514== by 0x261E44: main (smbtorture.c:665)
==25514== Address 0x187d69c6 is 598 bytes inside a block of size 1,325 alloc'd
==25514== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25514== by 0xF464A73: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.5)
==25514== by 0xF67366D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.26)
==25514== by 0xB0D49FF: smb1cli_req_create (smbXcli_base.c:1322)
==25514== by 0xB0E1E6D: smb1cli_trans_send (smb1cli_trans.c:512)
==25514== by 0x5AEE9B2: smb_raw_nttrans_send (rawtrans.c:310)
==25514== by 0x5AF64F0: smb_raw_query_secdesc_send (rawacl.c:51)
==25514== by 0x5AF56E5: smb_raw_fileinfo_send (rawfileinfo.c:658)
==25514== by 0x5AF58A3: smb_raw_fileinfo (rawfileinfo.c:720)
==25514== by 0x454AC3: torture_winattrtest (attr.c:217)
==25514== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==25514== by 0x955368F: internal_torture_run_test (torture.c:442)
==25514== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==25514== by 0x2600A4: run_matching (smbtorture.c:110)
==25514== by 0x25FF66: run_matching (smbtorture.c:95)
==25514== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==25514== by 0x261E44: main (smbtorture.c:665)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
smbtorture test base.aliases.setpathinfo_aliases.setpathinfo_aliases
results in the following valgrind trace
==23067== Syscall param writev(vector[...]) points to uninitialised byte(s)
==23067== at 0xFBA2C87: writev (in /lib64/libc-2.19.so)
==23067== by 0x106CB033: writev_handler (async_sock.c:340)
==23067== by 0xF67812A: ??? (in /usr/lib64/libtevent.so.0.9.26)
==23067== by 0xF6765F6: ??? (in /usr/lib64/libtevent.so.0.9.26)
==23067== by 0xF6727FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.26)
==23067== by 0x5AE3400: smbcli_request_receive (rawrequest.c:416)
==23067== by 0x5AE6019: smb_raw_write_recv (rawreadwrite.c:303)
==23067== by 0x5AE63FD: smb_raw_write (rawreadwrite.c:344)
==23067== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==23067== by 0x423EB4: setpathinfo_aliases (aliases.c:367)
==23067== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==23067== by 0x955368F: internal_torture_run_test (torture.c:442)
==23067== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==23067== by 0x2600A4: run_matching (smbtorture.c:110)
==23067== by 0x25FF66: run_matching (smbtorture.c:95)
==23067== by 0x25FF66: run_matching (smbtorture.c:95)
==23067== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==23067== by 0x261E44: main (smbtorture.c:665)
==23067== Address 0x187e0096 is 598 bytes inside a block of size 1,325 alloc'd
==23067== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23067== by 0xF464A73: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.5)
==23067== by 0xF67366D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.26)
==23067== by 0xB0D49FF: smb1cli_req_create (smbXcli_base.c:1322)
==23067== by 0x5ADFAB7: smbcli_transport_setup_subreq (clitransport.c:254)
==23067== by 0x5ADFC37: smbcli_transport_send (clitransport.c:326)
==23067== by 0x5AE33C3: smbcli_request_send (rawrequest.c:400)
==23067== by 0x5AE5FDD: smb_raw_write_send (rawreadwrite.c:289)
==23067== by 0x5AE63E6: smb_raw_write (rawreadwrite.c:343)
==23067== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==23067== by 0x423EB4: setpathinfo_aliases (aliases.c:367)
==23067== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==23067== by 0x955368F: internal_torture_run_test (torture.c:442)
==23067== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==23067== by 0x2600A4: run_matching (smbtorture.c:110)
==23067== by 0x25FF66: run_matching (smbtorture.c:95)
==23067== by 0x25FF66: run_matching (smbtorture.c:95)
==23067== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==23067== by 0x261E44: main (smbtorture.c:665)
==23067==
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
smbtorture test base.aliases.setfileinfo_aliases.setfileinfo_aliases
results in the following valgrind trace
==22757== Syscall param writev(vector[...]) points to uninitialised byte(s)
==22757== at 0xFBA2C87: writev (in /lib64/libc-2.19.so)
==22757== by 0x106CB033: writev_handler (async_sock.c:340)
==22757== by 0xF67812A: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22757== by 0xF6765F6: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22757== by 0xF6727FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.26)
==22757== by 0x5AE3400: smbcli_request_receive (rawrequest.c:416)
==22757== by 0x5AE6019: smb_raw_write_recv (rawreadwrite.c:303)
==22757== by 0x5AE63FD: smb_raw_write (rawreadwrite.c:344)
==22757== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22757== by 0x423C91: setfileinfo_aliases (aliases.c:327)
==22757== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22757== by 0x955368F: internal_torture_run_test (torture.c:442)
==22757== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22757== by 0x2600A4: run_matching (smbtorture.c:110)
==22757== by 0x25FF66: run_matching (smbtorture.c:95)
==22757== by 0x25FF66: run_matching (smbtorture.c:95)
==22757== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22757== by 0x261E44: main (smbtorture.c:665)
==22757== Address 0x187dfee6 is 598 bytes inside a block of size 1,325 alloc'd
==22757== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22757== by 0xF464A73: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.5)
==22757== by 0xF67366D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.26)
==22757== by 0xB0D49FF: smb1cli_req_create (smbXcli_base.c:1322)
==22757== by 0x5ADFAB7: smbcli_transport_setup_subreq (clitransport.c:254)
==22757== by 0x5ADFC37: smbcli_transport_send (clitransport.c:326)
==22757== by 0x5AE33C3: smbcli_request_send (rawrequest.c:400)
==22757== by 0x5AE5FDD: smb_raw_write_send (rawreadwrite.c:289)
==22757== by 0x5AE63E6: smb_raw_write (rawreadwrite.c:343)
==22757== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22757== by 0x423C91: setfileinfo_aliases (aliases.c:327)
==22757== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22757== by 0x955368F: internal_torture_run_test (torture.c:442)
==22757== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22757== by 0x2600A4: run_matching (smbtorture.c:110)
==22757== by 0x25FF66: run_matching (smbtorture.c:95)
==22757== by 0x25FF66: run_matching (smbtorture.c:95)
==22757== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22757== by 0x261E44: main (smbtorture.c:665)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
running smbtorture test base.aliases.FINDFIRST aliases.FINDFIRST aliases
results in the following valgrind trace
==22639== Syscall param writev(vector[...]) points to uninitialised byte(s)
==22639== at 0xFBA2C87: writev (in /lib64/libc-2.19.so)
==22639== by 0x106CB033: writev_handler (async_sock.c:340)
==22639== by 0xF67812A: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22639== by 0xF6765F6: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22639== by 0xF6727FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.26)
==22639== by 0x5AE3400: smbcli_request_receive (rawrequest.c:416)
==22639== by 0x5AE6019: smb_raw_write_recv (rawreadwrite.c:303)
==22639== by 0x5AE63FD: smb_raw_write (rawreadwrite.c:344)
==22639== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22639== by 0x423672: findfirst_aliases (aliases.c:213)
==22639== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22639== by 0x955368F: internal_torture_run_test (torture.c:442)
==22639== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22639== by 0x2600A4: run_matching (smbtorture.c:110)
==22639== by 0x25FF66: run_matching (smbtorture.c:95)
==22639== by 0x25FF66: run_matching (smbtorture.c:95)
==22639== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22639== by 0x261E44: main (smbtorture.c:665)
==22639== Address 0x187dfd26 is 598 bytes inside a block of size 1,325 alloc'd
==22639== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22639== by 0xF464A73: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.5)
==22639== by 0xF67366D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.26)
==22639== by 0xB0D49FF: smb1cli_req_create (smbXcli_base.c:1322)
==22639== by 0x5ADFAB7: smbcli_transport_setup_subreq (clitransport.c:254)
==22639== by 0x5ADFC37: smbcli_transport_send (clitransport.c:326)
==22639== by 0x5AE33C3: smbcli_request_send (rawrequest.c:400)
==22639== by 0x5AE5FDD: smb_raw_write_send (rawreadwrite.c:289)
==22639== by 0x5AE63E6: smb_raw_write (rawreadwrite.c:343)
==22639== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22639== by 0x423672: findfirst_aliases (aliases.c:213)
==22639== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22639== by 0x955368F: internal_torture_run_test (torture.c:442)
==22639== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22639== by 0x2600A4: run_matching (smbtorture.c:110)
==22639== by 0x25FF66: run_matching (smbtorture.c:95)
==22639== by 0x25FF66: run_matching (smbtorture.c:95)
==22639== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22639== by 0x261E44: main (smbtorture.c:665)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
smbtorture 'base.aliases.QPATHINFO aliases.QPATHINFO aliases' results in
following valgrind trace
==22469== Syscall param writev(vector[...]) points to uninitialised byte(s)
==22469== at 0xFBA2C87: writev (in /lib64/libc-2.19.so)
==22469== by 0x106CB033: writev_handler (async_sock.c:340)
==22469== by 0xF67812A: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22469== by 0xF6765F6: ??? (in /usr/lib64/libtevent.so.0.9.26)
==22469== by 0xF6727FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.26)
==22469== by 0x5AE3400: smbcli_request_receive (rawrequest.c:416)
==22469== by 0x5AE6019: smb_raw_write_recv (rawreadwrite.c:303)
==22469== by 0x5AE63FD: smb_raw_write (rawreadwrite.c:344)
==22469== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22469== by 0x423431: qpathinfo_aliases (aliases.c:171)
==22469== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22469== by 0x955368F: internal_torture_run_test (torture.c:442)
==22469== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22469== by 0x2600A4: run_matching (smbtorture.c:110)
==22469== by 0x25FF66: run_matching (smbtorture.c:95)
==22469== by 0x25FF66: run_matching (smbtorture.c:95)
==22469== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22469== by 0x261E44: main (smbtorture.c:665)
==22469== Address 0x187dfb86 is 598 bytes inside a block of size 1,325 alloc'd
==22469== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22469== by 0xF464A73: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.5)
==22469== by 0xF67366D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.26)
==22469== by 0xB0D49FF: smb1cli_req_create (smbXcli_base.c:1322)
==22469== by 0x5ADFAB7: smbcli_transport_setup_subreq (clitransport.c:254)
==22469== by 0x5ADFC37: smbcli_transport_send (clitransport.c:326)
==22469== by 0x5AE33C3: smbcli_request_send (rawrequest.c:400)
==22469== by 0x5AE5FDD: smb_raw_write_send (rawreadwrite.c:289)
==22469== by 0x5AE63E6: smb_raw_write (rawreadwrite.c:343)
==22469== by 0x9BE50CA: smbcli_write (clireadwrite.c:118)
==22469== by 0x423431: qpathinfo_aliases (aliases.c:171)
==22469== by 0x16B21D: wrap_simple_1smb_test (util_smb.c:856)
==22469== by 0x955368F: internal_torture_run_test (torture.c:442)
==22469== by 0x9553A6B: torture_run_test_restricted (torture.c:542)
==22469== by 0x2600A4: run_matching (smbtorture.c:110)
==22469== by 0x25FF66: run_matching (smbtorture.c:95)
==22469== by 0x25FF66: run_matching (smbtorture.c:95)
==22469== by 0x2601C5: torture_run_named_tests (smbtorture.c:143)
==22469== by 0x261E44: main (smbtorture.c:665)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Aurelien Aptel <aaptel@suse.com>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: David Disseldorf <ddis@suse.de>
Autobuild-User(master): Alexander Bokovoy <ab@samba.org>
Autobuild-Date(master): Fri Mar 4 21:23:45 CET 2016 on sn-devel-144
Previously, "QFILEINFO aliases" was running qfsinfo_aliases and
"QFSINFO aliases" was running qfileinfo_aliases. This change
is to make sure that each of them point towards correct test cases.
Signed-off-by: Anoop C S <anoopcs@redhat.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Tue Dec 1 20:44:54 CET 2015 on sn-devel-104
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Nov 6 13:43:45 CET 2015 on sn-devel-104
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Thu Oct 29 00:42:49 CET 2015 on sn-devel-104
We want to test that the write did update the write time immediately.
We check this by getting the file info in a loop for a few seconds.
There are several result cases:
- the server updated the write time immediately - success
- the server updated the write time, but not immediately - failure
- the server did not update the write time - failure
The loop is only there to be able to discern between the two
failure cases. The check for success is whether the first
getinfo has reportet the updated write time.
The potential for false failures was the additional timing check.
So if the first fileinfo call just took too long (e.g. due to a
busy system), this was reported as failure.
This patch should eliminate interemittent autobuild failures.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can hence replace the assert after the loop by a success torture_comment.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This does not change the logic except for adding early
returns in failure cases.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We want to test that the write did update the write time immediately.
We check this by getting the file info in a loop for a few seconds.
There are several result cases:
- the server updated the write time immediately - success
- the server updated the write time, but not immediately - failure
- the server did not update the write time - failure
The loop is only there to be able to discern between the two
failure cases. The check for success is whether the first
getinfo has reportet the updated write time.
The potential for false failures was the additional timing check.
So if the first fileinfo call just took too long (e.g. due to a
busy system), this was reported as failure.
This patch should eliminate interemittent autobuild failures.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can hence replace the assert after the loop by a success torture_comment.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This does not change the logic except for adding early
returns in failure cases.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We want to test that the write did update the write time immediately.
We check this by getting the file info in a loop for a few seconds.
There are several result cases:
- the server updated the write time immediately - success
- the server updated the write time, but not immediately - failure
- the server did not update the write time - failure
The loop is only there to be able to discern between the two
failure cases. The check for success is whether the first
getinfo has reportet the updated write time.
The potential for false failures was the additional timing check.
So if the first fileinfo call just took too long (e.g. due to a
busy system), this was reported as failure.
This patch should eliminate interemittent autobuild failures.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can hence replace the assert after the loop by a success torture_comment.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This does not change the logic except for adding early
returns in failure cases.
But it makes the code more compact and obvious.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We want to test that the write did update the write time immediately.
We check this by getting the file info in a loop for a few seconds.
There are several result cases:
- the server updated the write time immediately - success
- the server updated the write time, but not immediately - failure
- the server did not update the write time - failure
The loop is only there to be able to discern between the two
failure cases. The check for success is whether the first
getinfo has reportet the updated write time.
The potential for false failures was the additional timing check.
So if the first fileinfo call just took too long (e.g. due to a
busy system), this was reported as failure.
This patch should eliminate interemittent autobuild failures.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can hence replace the assert after the loop by a success torture_comment.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This copes with cases where the server is very busy and
can't provide tortures more tight time scaling..
This is an attepmt to remove the flapping character of this test.
Signed-off-by: Michael Adam <obnox@samba.org>
Revieed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Sep 10 21:51:42 CEST 2014 on sn-devel-104
This is to be able to better tell what went wrong if something
went wrong. This is currently one of the main flapping tests.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is where it belongs, and it prepares
subsequent patches.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The fix missed one instance, as autobuild has just told me...
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Mon Aug 18 17:42:00 CEST 2014 on sn-devel-104
The write should never update the time, so the fraction of the write
time delay we use is not important.
Andrew Bartlett
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Jun 24 01:44:06 CEST 2014 on sn-devel-104
This removes the hardcoded TIMEDELAY_SECS that was then made variable
by the confusing "secs" variable
Andrew Bartlett
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The previous test was far, far too tight, it was in seconds 1/4 of the
fraction of the normal delay we had configured Samba to use so (1/4) *
(500 000 / 2000 000) = 1/16 (sec). This margin appears to just be too
tight for our loaded test server.
Andrew Bartlett
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
In particular, this avoids a comparison with
double diff = timeval_elapsed() being promoted to an integer.
Andrew Bartlett
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This only changes instances directly before a return false, ret =
false or goto fail statement.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Thu Jun 12 10:39:38 CEST 2014 on sn-devel-104
This only changes instances directly before a return false, ret =
false or goto fail statement.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Both offer the same functionality, sec_ace_equal() will be removed.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This causes flakey autobuilds from time to time.
The reduction in the time window to 30% was added in:
commit c2df97f57c
Author: Jeremy Allison <jra@samba.org>
Date: Thu Nov 5 15:37:26 2009 -0800
Fix up some of the timing constants for DELAYWRITE. Add some extra tests up test_delayed_write_update6
to investigate what happens to a sticky write handle after a second handle close.
Jeremy.
The original reduction to 75% was set in the new code
commit 0d0fddf8ae
Author: Jeremy Allison <jra@samba.org>
Date: Fri Sep 5 14:24:36 2008 -0700
Added tests that show that write time update is immediate
when changing file size using SMBwrite of size zero,
SET_END_OF_FILE, or SET_ALLOCATION_SIZE - no 2 second
delay in these cases.
Jeremy.
(This used to be commit 3aa7523d77)
and in:
commit edb3a83a06
Author: Stefan Metzmacher <metze@samba.org>
Date: Tue Apr 8 10:25:51 2008 +0200
BASE-DELAYWRITE: use timeval_* and make it possible to spefic the writetime update delay
metze
(This used to be commit 751ab2992a)
Change-Id: I8ff9fb8a8b66308f6d784351a0f43b5b234889d1
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Not fetching the latest modification time on a folder if we have read locks on it.
Prove we should just rely on the mtime value from the underlying
filesystem, even with an open handle.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=9870
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Dec 5 10:05:06 CET 2013 on sn-devel-104
Signed-off-by: Richard Sharpe <realrichardsharpe@gmail.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Feb 15 07:09:59 CET 2013 on sn-devel-104
There seems to be a difference if the initial delete_on_close flag
was set on a handle that created the file or if the handle if was
for a file that already existed.
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Aug 17 21:44:24 CEST 2012 on sn-devel-104
This ensures that if this fails, it is reported as a subunit error correctly.
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Fri May 18 09:35:13 CEST 2012 on sn-devel-104
Currently there are a lot of duplicate ioctl function field definitions
between source3 and source4.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
It's possible that the test runs on a full hour, e.g. Tue Sep 6 03:00:00 2011.
So better check that the a_time is different from the current time.
metze
This is a helper for the common case of opening a tdb with a logging
function, but it doesn't do all the work, since TDB1 and TDB2's log
functions are different types.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We change all the headers and wscript files to use tdb_compat; this
means we have one place to decide whether to use TDB1 or TDB2.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Makes these interfaces much harder to misuse and easier to ensure error
checking.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Mar 30 23:59:37 CEST 2011 on sn-devel-104
we shouldn't accept bad multi-byte strings, it just hides problems
Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Thu Mar 24 01:47:26 CET 2011 on sn-devel-104
This is consistent with the test names used by selftest, should
make the names less confusing and easier to integrate with other tools.
Autobuild-User: Jelmer Vernooij <jelmer@samba.org>
Autobuild-Date: Sat Dec 11 04:16:13 CET 2010 on sn-devel-104
There are a number of cases in BASE-OPEN where an initial failure cascades
into multiple failures due to lack of cleanup between test phases. Fix
all these so that they close open file handles correctly. Replace
torture_comment with torture_result where appropriate so that the results
output contains a useful diagnostic.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Sat Dec 11 03:19:39 CET 2010 on sn-devel-104
This partially reverts commit 54a5c398aa.
As tridge pointed out I've overseen the nested loop in "run_iometer".
Therefore we end in a infinite loop. Obviously it wasn't run by "make
test" since then I would have detected it.
Autobuild-User: Matthias Dieter Wallnöfer <mdw@samba.org>
Autobuild-Date: Tue Nov 30 09:23:00 CET 2010 on sn-devel-104
