- 06 Sep, 2020 2 commits
- 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 2 commits
- 04 Oct, 2011 1 commit
-
-
antirez authored
Redis test ports selection made more robust. This prevents the test from hanging if an already bound port is selected but the TCP server listening to it does not cause a protocol error with a Redis client PING. Also base port moved away from the range near to the Redis Cluster gossip ports.
-
- 11 Jul, 2011 1 commit
-
-
antirez authored
-
- 09 Jul, 2011 1 commit
-
-
antirez authored
The test now gives some more time for Redis to start before of exiting with an error, since starting with valgrind can take a significant amount of time.
-
- 06 Jul, 2011 1 commit
-
-
antirez authored
-
- 15 Apr, 2011 1 commit
-
-
antirez authored
-
- 09 Jan, 2011 1 commit
-
-
antirez authored
-
- 03 Jan, 2011 1 commit
-
-
antirez authored
-