- 11 Dec, 2020 1 commit
-
-
Yossi Gottlieb authored
This adds a new `tls-client-cert-file` and `tls-client-key-file` configuration directives which make it possible to use different certificates for the TLS-server and TLS-client functions of Redis. This is an optional directive. If it is not specified the `tls-cert-file` and `tls-key-file` directives are used for TLS client functions as well. Also, `utils/gen-test-certs.sh` now creates additional server-only and client-only certs and will skip intensive operations if target files already exist.
-
- 06 Dec, 2020 1 commit
-
-
Oran Agra authored
The test creates keys with various encodings, DUMP them, corrupt the payload and RESTORES it. It utilizes the recently added use-exit-on-panic config to distinguish between asserts and segfaults. If the restore succeeds, it runs random commands on the key to attempt to trigger a crash. It runs in two modes, one with deep sanitation enabled and one without. In the first one we don't expect any assertions or segfaults, in the second one we expect assertions, but no segfaults. We also check for leaks and invalid reads using valgrind, and if we find them we print the commands that lead to that issue. Changes in the code (other than the test): - Replace a few NPD (null pointer deference) flows and division by zero with an assertion, so that it doesn't fail the test. (since we set the server to use `exit` rather than `abort` on assertion). - Fix quite a lot of flows in rdb.c that could have lead to memory leaks in RESTORE command (since it now responds with an error rather than panic) - Add a DEBUG flag for SET-SKIP-CHECKSUM-VALIDATION so that the test don't need to bother with faking a valid checksum - Remove a pile of code in serverLogObjectDebugInfo which is actually unsafe to run in the crash report (see comments in the code) - fix a missing boundary check in lzf_decompress test suite infra improvements: - be able to run valgrind checks before the process terminates - rotate log files when restarting servers
-
- 18 Oct, 2020 1 commit
-
-
Yossi Gottlieb authored
-
- 07 Sep, 2020 1 commit
-
-
Yossi Gottlieb authored
There is an inherent race condition in port allocation for spawned servers. If a server fails to start because a port is taken, a new port is allocated. This fixes a problem where the logs are not truncated and as a result a large number of unmonitored servers are started.
-
- 06 Sep, 2020 6 commits
-
-
Oran Agra authored
- redirect valgrind reports to a dedicated file rather than console - try to avoid killing instances with SIGKILL so that we get the memory leak report (killing with SIGTERM before resorting to SIGKILL) - search for valgrind reports when done, print them and fail the tests - add --dont-clean option to keep the logs on exit - fix exit error code when crash is found (would have exited with 0) changes that affect the normal redis test suite: - refactor check_valgrind_errors into two functions one to search and one to report - move the search half into util.tcl to serve the cluster tests too - ignore "address range perms" valgrind warnings which seem non relevant.
-
Oran Agra authored
in some cases a command that returns an error possibly due to a timing issue causes the tcl code to crash and thus prevents the rest of the tests from running. this adds an option to make the test proceed despite the crash. maybe it should be the default mode some day.
-
Oran Agra authored
-
Oran Agra authored
- skip full units - skip a single test (not just a list of tests) - when skipping tag, skip spinning up servers, not just the tests - skip tags when running against an external server too - allow using multiple tags (split them)
-
Oran Agra authored
this is important when running a test with --loop
-
Oran Agra authored
-
- 21 Jul, 2020 1 commit
-
-
Oran Agra authored
in cases where you have test name { start_server { start_server { assert } } } the exception will be thrown to the test proc, and the servers are supposed to be killed on the way out. but it seems there was always a bug of not cleaning the server stack, and recently (#7404) we started relying on that stack in order to kill them, so with that bug sometimes we would have tried to kill the same server twice, and leave one alive. luckly, in most cases the pattern is: start_server { test name { } }
-
- 10 Jul, 2020 1 commit
-
-
Oran Agra authored
* tests/valgrind: don't use debug restart DEBUG REATART causes two issues: 1. it uses execve which replaces the original process and valgrind doesn't have a chance to check for errors, so leaks go unreported. 2. valgrind report invalid calls to close() which we're unable to resolve. So now the tests use restart_server mechanism in the tests, that terminates the old server and starts a new one, new PID, but same stdout, stderr. since the stderr can contain two or more valgrind report, it is not enough to just check for the absence of leaks, we also need to check for some known errors, we do both, and fail if we either find an error, or can't find a report saying there are no leaks. other changes: - when killing a server that was already terminated we check for leaks too. - adding DEBUG LEAK which was used to test it. - adding --trace-children to valgrind, although no longer needed. - since the stdout contains two or more runs, we need slightly different way of checking if the new process is up (explicitly looking for the new PID) - move the code that handles --wait-server to happen earlier (before watching the startup message in the log), and serve the restarted server too. * squashme - CR fixes
-
- 26 May, 2020 1 commit
-
-
Oran Agra authored
apparently when running tests in parallel (the default of --clients 16), there's a chance for two tests to use the same port. specifically, one test might shutdown a master and still have the replica up, and then another test will re-use the port number of master for another master, and then that replica will connect to the master of the other test. this can cause a master to count too many full syncs and fail a test if we run the tests with --single integration/psync2 --loop --stop see Probmem 2 in #7314
-
- 06 Apr, 2020 1 commit
-
-
Oran Agra authored
-
- 11 Mar, 2020 1 commit
-
-
bodong.ybd authored
-
- 24 Feb, 2020 1 commit
-
-
antirez authored
-
- 21 Feb, 2020 2 commits
- 07 Oct, 2019 1 commit
-
-
Yossi Gottlieb authored
* Introduce a connection abstraction layer for all socket operations and integrate it across the code base. * Provide an optional TLS connections implementation based on OpenSSL. * Pull a newer version of hiredis with TLS support. * Tests, redis-cli updates for TLS support.
-
- 04 Sep, 2018 1 commit
-
-
maya-rv authored
-
- 26 Jun, 2018 1 commit
-
-
Oran Agra authored
* fail the test (exit code) in case of timeout. * add --wait-server to allow attaching a debugger * add --dont-clean to keep log files when tests are done
-
- 19 Dec, 2016 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 1 commit
-
-
antirez authored
-
- 31 Mar, 2015 1 commit
-
-
antirez authored
This should likely fix a false positive when running with the --valgrind option.
-
- 21 Jan, 2015 1 commit
-
-
Matt Stancliff authored
-
- 28 Nov, 2014 2 commits
-
-
antirez authored
start_server now uses return value from Tcl exec to get the server pid, however this introduces errors that depend from timing: a lot of the testing code base assumed the server to be actually up and running when server_start returns. So the old code that waits to see the pid in the log file was restored.
-
antirez authored
It's hard to run the Redis test continuously if it leaks processes on exceptions / errors.
-
- 29 Sep, 2014 1 commit
-
-
Matt Stancliff authored
-
- 23 May, 2014 1 commit
-
-
Matt Stancliff authored
Previously the PID format was: [PID] Timestamp But it recently changed to: PID:X Timestamp The tcl testing framework was grabbing the PID from \[\d+\], but that's not valid anymore. Now we grab the pid from "PID: <PID>" in the part of Redis startup output to the right of the ASCII logo.
-
- 07 May, 2014 1 commit
-
-
antirez authored
Sometimes the process is still there but no longer in a state that can be checked (after being killed). This used to happen after a call to SHUTDOWN NOSAVE in the scripting unit, causing a false positive.
-
- 25 Mar, 2014 1 commit
-
-
antirez authored
-
- 17 Feb, 2014 1 commit
-
-
antirez authored
Some inline test moved into server_is_up procedure. Also find_available_port was moved into util since it is going to be used for the Sentinel test as well.
-
- 12 Feb, 2013 1 commit
-
-
antirez authored
-
- 03 Dec, 2012 1 commit
-
-
antirez authored
Due to changes in recent releases of osx leaks utility, the osx leak detection no longer worked. Now it is fixed in a way that should be backward compatible.
-
- 24 Oct, 2012 1 commit
-
-
YAMAMOTO Takashi authored
-
- 17 Apr, 2012 1 commit
-
-
Michael Schlenker authored
Tcl's exec can send data to stdout itself, no need to call cat/echo for that usually.
-
- 03 Apr, 2012 1 commit
-
-
Premysl Hruby authored
-
- 28 Mar, 2012 1 commit
-
-
antirez authored
Redis test: regexp to check if valgrind reported errors modified. Now we no longer look at the total count because this includes "possibly lost" bytes that are not interesting for Redis (tons of false positives because of how sds.c works).
-
- 24 Mar, 2012 1 commit
-
-
antirez authored
When running the test in valgrind mode, pass the right flags to show memory leaks stack traces but only including the "definitely lost" items.
-
- 07 Dec, 2011 1 commit
-
-
antirez authored
-