Convert sds test to GTEST by asagege · Pull Request #1 · harrylin98/valkey_forked

asagege · 2026-02-04T01:25:24Z

Change headers: #include "generated_wrappers.hpp" and remove all header files already in "generated_wrappers.hpp"
ustime is included in util.h
SetUp() and TearDown() are empty for this test
Keep all original comments from test_sds.c
In TestSds, allocate 1MB buffer on heap instead of stack to avoid exceeding the frame size limit, because the compiler flag -Wframe-larger-than=32768 enforces a 32KB limit per stack frame, and this 1MB allocation would trigger a compilation error if allocated on the stack.
TestSdsnsplitargsBenchmark is disabled by default because it takes a long time to run. Also update README in gtest to state this condition.

This PR fixes the issue where changes to src files did not trigger a rebuild of libvalkey.a when rerunning `make test-gtest`. It also resolves the problem where unchanged .cpp test files were unnecessarily recompiled during make test-gtest. Now: If nothing changed: - Nothing rebuilds, no relinking occurs. If only C++ test files changed: - Both libvalkey.a and C++ test files recompile (because release.o changes) - Test executable relinks If only src code changed: - Only libvalkey.a rebuilds - C++ test files do not recompile - Test executable relinks If both changed: - Both libvalkey.a and C++ test files rebuild - Test executable relinks Signed-off-by: Harry Lin <harrylhl@amazon.com> Co-authored-by: Harry Lin <harrylhl@amazon.com>

src/gtest/test_sds.cpp

src/unit/test_sds.cpp

src/gtest/test_sds.cpp

src/unit/test_sds.cpp

src/gtest/test_sds.cpp

src/gtest/README.md

src/gtest/test_dict.cpp

src/gtest/test_entry.cpp

src/gtest/test_hashtable.cpp

JimB123 · 2026-02-06T22:18:47Z

src/gtest/test_networking.cpp

+        listRelease(server.repl_buffer_blocks);
+        listRelease(c->reply);
+        freeClientReplicationData(c);
+        zfree(c);


also c = nullptr;

The original C code doesn't do it

JimB123 · 2026-02-06T22:19:20Z

src/gtest/test_networking.cpp

+    }
+
+    void TearDown() override {
+        listRelease(server.repl_buffer_blocks);


and server.repl_buffer_blocks = nullptr;

The original C code doesn't do it

src/gtest/test_networking.cpp

src/gtest/test_quicklist.cpp

src/gtest/wrappers.h

Address valkey-io#2683 For the test, I found two problems. ### 1. Test Assumes Winner Has Rank #0 In my test run, in the failing case: - Replica -3 (rank 0) won epoch 10 first - Replica -6 (rank 1) won epoch 11 second - Replica -3 saw higher epoch and stepped down - Final result: rank 1 became master Rank #0 doesn't guarantee being the final master. ### 2. Pattern Matching Bug The pattern `*Start of election*rank #0*` incorrectly matches "primary rank #0": Log: `Start of election delayed for 350 milliseconds (rank #1, primary rank #0, offset 2172)` This line has rank `#1`, but the pattern matches because of "primary rank `#0`" at the end. ## Solution - Fixed the format problem by checking if `(rank #0` or `(rank #1` so that we won't accidentally match the primary rank - Only check to make sure replica 3 and replica 6 have different ranks without assuming the replica with rank 0 will become the master. Signed-off-by: Hanxi Zhang <hanxizh@amazon.com>

…lkey-io#3174) I was working on ASAN large memory tests when I countered this issue. The issue was that the hardcoded `999` key could land in an early bucket. Then shrink rehash could finish early, and later inserts could trigger a new expansion rehash, resetting rehash_idx low. The test now picks the survivor key dynamically as the key mapped to the highest bucket index. ``` [test_hashtable.c] Memory leak detected of 336 bytes ================================================================= ==3901==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x563bfdf4c47d in ztrymalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:156 valkey-io#2 0x563bfdf4c47d in valkey_malloc /home/runner/work/valkey/valkey/src/zmalloc.c:185 valkey-io#3 0x563bfdd42eaf in hashtableCreate /home/runner/work/valkey/valkey/src/hashtable.c:1217 valkey-io#4 0x563bfdaa1cbf in test_empty_buckets_rehashing unit/test_hashtable.c:232 valkey-io#5 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#6 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#7 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#8 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#9 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 128 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd40967 in resize /home/runner/work/valkey/valkey/src/hashtable.c:741 valkey-io#4 0x563bfdd45eb1 in hashtableExpandIfNeeded /home/runner/work/valkey/valkey/src/hashtable.c:1446 valkey-io#5 0x563bfdd45eb1 in hashtableExpandIfNeeded /home/runner/work/valkey/valkey/src/hashtable.c:1433 valkey-io#6 0x563bfdd45eb1 in insert /home/runner/work/valkey/valkey/src/hashtable.c:1041 valkey-io#7 0x563bfdd45eb1 in hashtableAddOrFind /home/runner/work/valkey/valkey/src/hashtable.c:1554 valkey-io#8 0x563bfdd45eb1 in hashtableAdd /home/runner/work/valkey/valkey/src/hashtable.c:1539 valkey-io#9 0x563bfdaa1e3b in test_empty_buckets_rehashing unit/test_hashtable.c:254 valkey-io#10 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#11 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#12 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#13 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#14 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd3f553 in bucketConvertToChained /home/runner/work/valkey/valkey/src/hashtable.c:908 valkey-io#4 0x563bfdd3f553 in findBucketForInsert /home/runner/work/valkey/valkey/src/hashtable.c:1021 valkey-io#5 0x563bfdd45d9e in insert /home/runner/work/valkey/valkey/src/hashtable.c:1045 valkey-io#6 0x563bfdd45d9e in hashtableAddOrFind /home/runner/work/valkey/valkey/src/hashtable.c:1554 valkey-io#7 0x563bfdd45d9e in hashtableAdd /home/runner/work/valkey/valkey/src/hashtable.c:1539 valkey-io#8 0x563bfdaa1e3b in test_empty_buckets_rehashing unit/test_hashtable.c:254 valkey-io#9 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#10 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#11 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#12 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#13 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd40967 in resize /home/runner/work/valkey/valkey/src/hashtable.c:741 valkey-io#4 0x563bfdaa1df8 in test_empty_buckets_rehashing unit/test_hashtable.c:248 valkey-io#5 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#6 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#7 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#8 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#9 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) SUMMARY: AddressSanitizer: 336 byte(s) leaked in 4 allocation(s). ``` Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

…io#3135) There should be a way for people to monitor the amount of output buffer data accumulating at the source node during the migration process. This PR also do a change in slotExportTryDoPause, previously, we used `getClientOutputBufferMemoryUsage` to determine if the offset was sufficient to trigger the pause, it also adding the listNode overhead. Now we use client->bytes. Signed-off-by: Binbin <binloveplay1314@qq.com>

valkey-io#3180)

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Signed-off-by: Harry Lin <harrylhl@amazon.com>

Signed-off-by: Harry Lin <49881386+harrylin98@users.noreply.github.com>

Remove C unit test framework

…urn type (valkey-io#3184) This fixes a regression where PFADD returned 1 instead of INVALIDOBJ for corrupted sparse HLL payloads. In small strings refactor (valkey-io#2516) we incorrectly changed the datatype from int to bool. That function still uses -1 as its error signal. Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

We have been seeing github actions runners being OOM when large memory tests are run with ASan. The operation eventually is being canceled during the test. This change moves the large-memory tests with ASan and UBSan to separate jobs, so we get a dedicated runner with its own timeout. We can tweak the number of simultaneous test clients for these tests without affecting the other test jobs. Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

I think a lot of new contributors are not aware how they can run the extended list of tests in their forked repo branch with other test arguments. This change could be helpful to some people. --------- Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

Replace the implementation of byte-reverse functions. The new implementation compiles to a single bswap instruction. The old implementation didn't. The new implementation is small and all in the .h file. The .c file is deleted. On little-endian systems, this affects streams, module timers and cluster code and a few more things, where `htonu64()` is used for storing stream-id or timestamps in a rax in big-endian order. --------- Signed-off-by: Viktor Söderqvist <viktor.soderqvist@est.tech>

…sue (valkey-io#1840) It's worth mentioning that enabling `maxmemory-clients` will affect the performance so people can perform its own benchmark before enabling it. Signed-off-by: Binbin <binloveplay1314@qq.com>

At one point in development there was assumption that intset of database IDs would have IDs only in `[0, server.dbnum-1]` range, but [here](valkey-io#2309 (comment)) we decided to change upper bound to `INT32_MAX` for ACL compatibility reasons between nodes. Because of that change, assumption is not true anymore and we should explicitly check each database list to contain access to full `[0, server.dbnum-1]` range. Also added test for that. Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com>

…alkey-io#3202) We made some changes to the workflow where the label was getting removed every time we ran it. This changes handles it, removes `pull_request_target` and doesn't re-trigger on adding another label. I tried it here: sarthakaggarwal97#65 The code is already merged in my unstable. Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

This PR enables `USE_LIBBACKTRACE=yes` across all CI builds and builds upon the changes introduced in valkey-io#3034. Alpine-based jobs previously attempted to install `libbacktrace-dev`, which does not exist in Alpine’s apk repositories. This caused these two errors in the daily tests below: - https://github.com/valkey-io/valkey/actions/runs/22045858351/job/63694456995 - https://github.com/valkey-io/valkey/actions/runs/22045858351/job/63694457018 To resolve this, Alpine jobs now build GNU libbacktrace from source inside the container before compiling Valkey. This aligns Alpine behavior with other environments (Ubuntu jobs) and now avoids utilizing non-existent Alpine packages. An alternative approach we can consider is to disable `USE_LIBBACKTRACE` for Alpine-based tests. Signed-off-by: Nikhil Manglore <nmanglor@amazon.com>

) If there is a crash between the time the job is popped and freed, we technically leak memory. This change allows us to peek, and pop just before we are about to free the job. Fixes valgrind errors: https://github.com/valkey-io/valkey/actions/runs/21969557125/job/63467641572#step:6:8648 --------- Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

The test somehow is slow and due to the short cluster-node-timeout, an automatic failover may fail to trigger due to cluster-replica-validity-factor: ``` *** [err]: Automatic failover vote is not limited by two times the node timeout - mixed failover in tests/unit/cluster/manual-failover.tcl The third failover does not happen xxx # Cluster state changed: fail xxx # Cluster is currently down: At least one hash slot is not served by any available node. Please check the 'cluster-require-full-coverage' configuration. ``` Closes valkey-io#3203. Signed-off-by: Binbin <binloveplay1314@qq.com>

in valkey-io#2807 we added safe-iterator invalidation when a hashtable is deleted. When we create a safeIterator we initialize it to it->table=0 and it-index=-1. HOWEVER say someone creates a safe iterator never progress it and later on just delete the iterator using `hashtableReleaseIterator`. the iterator will NOT be untracked since, `hashtableCleanupIterator` will skip the untrack: ```c if (!(iter->index == -1 && iter->table == 0)) { if (isSafe(iter)) { hashtableResumeRehashing(iter->hashtable); untrackSafeIterator(iter); } else { assert(iter->fingerprint == hashtableFingerprint(iter->hashtable)); } } ``` and then when the hashtable is freed the iterator will be referenced leading to a use-after-free. For example: ```c it = hashtableCreateIterator(ht, HASHTABLE_ITER_SAFE); hashtableReleaseIterator(it); hashtableRelease(ht); ``` This PR fix it by ALWAYS untrack safe iterators which have a valid hashtable when they are being cleaned up. Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

…ommands (valkey-io#3160) Summary: Prevent MODULE UNLOAD when ACL rules reference a module subcommand. Avoids crash during ACL recompute after module removal. Adds coverage for subcommand ACL rules. Tests: make test Fixes valkey-io#2797 --------- Signed-off-by: sachinvmurthy <sachin.murthy97@gmail.com> Signed-off-by: Sachin Venkatesha Murthy <sachin.murthy97@gmail.com>

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Large-memory tests were failing with "I/O error reading reply" after the first test `EVAL - JSON string encoding a string larger than 2GB`. Three tests that shared a single server instance led to cascading failures when the first test's 3GB allocation left the server in a memory-stressed state. This PR isolates each test by starting its own server. Additionally, I've reduced the JSON encoding test size from 3GB to 2.25GB. This included changing the allocated 1GB string (concatenated 3x) to a 750MB string to avoid memory exhaustion while still testing strings greater than 2GB like we intended. --------- Signed-off-by: Nikhil Manglore <nmanglor@amazon.com>

Resolved conflicts by merging both gtest and libbacktrace features: - ci.yml: Combined gtest dependencies with libbacktrace support - Makefile: Added libbacktrace configuration alongside gtest-parallel - daily.yml: Merged g++-multilib with libbacktrace build steps All build configurations now support both USE_LIBBACKTRACE and gtest unit tests.

Signed-off-by: Harry Lin <harrylhl@amazon.com>

Signed-off-by: Alina Liu <alinalq@dev-dsk-alinalq-2b-2db84246.us-west-2.amazon.com> Signed-off-by: Harry Lin <harrylhl@amazon.com>

Signed-off-by: Harry Lin <harrylhl@amazon.com>

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Address valkey-io#2683 For the test, I found two problems. ### 1. Test Assumes Winner Has Rank #0 In my test run, in the failing case: - Replica -3 (rank 0) won epoch 10 first - Replica -6 (rank 1) won epoch 11 second - Replica -3 saw higher epoch and stepped down - Final result: rank 1 became master Rank #0 doesn't guarantee being the final master. ### 2. Pattern Matching Bug The pattern `*Start of election*rank #0*` incorrectly matches "primary rank #0": Log: `Start of election delayed for 350 milliseconds (rank #1, primary rank #0, offset 2172)` This line has rank `#1`, but the pattern matches because of "primary rank `#0`" at the end. ## Solution - Fixed the format problem by checking if `(rank #0` or `(rank #1` so that we won't accidentally match the primary rank - Only check to make sure replica 3 and replica 6 have different ranks without assuming the replica with rank 0 will become the master. Signed-off-by: Hanxi Zhang <hanxizh@amazon.com>

…lkey-io#3174) I was working on ASAN large memory tests when I countered this issue. The issue was that the hardcoded `999` key could land in an early bucket. Then shrink rehash could finish early, and later inserts could trigger a new expansion rehash, resetting rehash_idx low. The test now picks the survivor key dynamically as the key mapped to the highest bucket index. ``` [test_hashtable.c] Memory leak detected of 336 bytes ================================================================= ==3901==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x563bfdf4c47d in ztrymalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:156 valkey-io#2 0x563bfdf4c47d in valkey_malloc /home/runner/work/valkey/valkey/src/zmalloc.c:185 valkey-io#3 0x563bfdd42eaf in hashtableCreate /home/runner/work/valkey/valkey/src/hashtable.c:1217 valkey-io#4 0x563bfdaa1cbf in test_empty_buckets_rehashing unit/test_hashtable.c:232 valkey-io#5 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#6 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#7 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#8 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#9 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 128 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd40967 in resize /home/runner/work/valkey/valkey/src/hashtable.c:741 valkey-io#4 0x563bfdd45eb1 in hashtableExpandIfNeeded /home/runner/work/valkey/valkey/src/hashtable.c:1446 valkey-io#5 0x563bfdd45eb1 in hashtableExpandIfNeeded /home/runner/work/valkey/valkey/src/hashtable.c:1433 valkey-io#6 0x563bfdd45eb1 in insert /home/runner/work/valkey/valkey/src/hashtable.c:1041 valkey-io#7 0x563bfdd45eb1 in hashtableAddOrFind /home/runner/work/valkey/valkey/src/hashtable.c:1554 valkey-io#8 0x563bfdd45eb1 in hashtableAdd /home/runner/work/valkey/valkey/src/hashtable.c:1539 valkey-io#9 0x563bfdaa1e3b in test_empty_buckets_rehashing unit/test_hashtable.c:254 valkey-io#10 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#11 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#12 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#13 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#14 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd3f553 in bucketConvertToChained /home/runner/work/valkey/valkey/src/hashtable.c:908 valkey-io#4 0x563bfdd3f553 in findBucketForInsert /home/runner/work/valkey/valkey/src/hashtable.c:1021 valkey-io#5 0x563bfdd45d9e in insert /home/runner/work/valkey/valkey/src/hashtable.c:1045 valkey-io#6 0x563bfdd45d9e in hashtableAddOrFind /home/runner/work/valkey/valkey/src/hashtable.c:1554 valkey-io#7 0x563bfdd45d9e in hashtableAdd /home/runner/work/valkey/valkey/src/hashtable.c:1539 valkey-io#8 0x563bfdaa1e3b in test_empty_buckets_rehashing unit/test_hashtable.c:254 valkey-io#9 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#10 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#11 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#12 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#13 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fb0556fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x563bfdf4c922 in ztrycalloc_usable_internal /home/runner/work/valkey/valkey/src/zmalloc.c:214 valkey-io#2 0x563bfdf4c922 in valkey_calloc /home/runner/work/valkey/valkey/src/zmalloc.c:257 valkey-io#3 0x563bfdd40967 in resize /home/runner/work/valkey/valkey/src/hashtable.c:741 valkey-io#4 0x563bfdaa1df8 in test_empty_buckets_rehashing unit/test_hashtable.c:248 valkey-io#5 0x563bfdae772b in runTestSuite unit/test_main.c:36 valkey-io#6 0x563bfda86b20 in main unit/test_main.c:108 valkey-io#7 0x7fb05522a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#8 0x7fb05522a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e) valkey-io#9 0x563bfda8a5c4 in _start (/home/runner/work/valkey/valkey/src/valkey-unit-tests+0x17c5c4) (BuildId: 44cfc183e6e82e499bcc9f6adc094d7f774ee9d2) SUMMARY: AddressSanitizer: 336 byte(s) leaked in 4 allocation(s). ``` Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

github-actions bot assigned asagege Feb 4, 2026

harrylin98 reviewed Feb 4, 2026

View reviewed changes

src/gtest/test_sds.cpp Outdated Show resolved Hide resolved

harrylin98 reviewed Feb 4, 2026

View reviewed changes

src/gtest/test_sds.cpp Outdated Show resolved Hide resolved

harrylin98 reviewed Feb 4, 2026

View reviewed changes

src/gtest/test_sds.cpp Outdated Show resolved Hide resolved

harrylin98 reviewed Feb 4, 2026

View reviewed changes

src/gtest/test_sds.cpp Outdated Show resolved Hide resolved

asagege force-pushed the gtest_unittesting branch from c8aa810 to 06f90d3 Compare February 4, 2026 20:21

JimB123 suggested changes Feb 4, 2026

View reviewed changes

JimB123 suggested changes Feb 6, 2026

View reviewed changes

madolson and others added 7 commits February 9, 2026 11:30

Merge remote-tracking branch 'origin/unstable' into feature-gtest

30ef060

Fix remaining_repl_size should be in CLUSTER GETSLOTMIGRATIONS in conf (

06ccdf9

valkey-io#3180)

Convert C unit tests to GTEST

3410878

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Add test flags

f8d479f

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Delete previous C unit tests

6d0440b

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

Remove C unit test framework

0b2adec

Signed-off-by: Harry Lin <harrylhl@amazon.com>

asagege force-pushed the gtest_unittesting branch from ce5379b to 6d0440b Compare February 10, 2026 18:43

harrylin98 and others added 5 commits February 10, 2026 10:49

Merge branch 'gtest_unittesting' into feature-gtest-remove-CTEST

4ecc298

Signed-off-by: Harry Lin <49881386+harrylin98@users.noreply.github.com>

Merge pull request #2 from harrylin98/feature-gtest-remove-CTEST

223aabf

Remove C unit test framework

asagege force-pushed the gtest_unittesting branch 6 times, most recently from 2f8c97d to 61e879a Compare February 11, 2026 01:27

zuiderkwast and others added 2 commits February 15, 2026 23:54

asagege force-pushed the gtest_unittesting branch from 81b8320 to c021b57 Compare February 16, 2026 07:48

asagege force-pushed the gtest_unittesting branch 2 times, most recently from 67861bc to 15c1823 Compare February 16, 2026 10:22

sarthakaggarwal97 and others added 3 commits February 16, 2026 19:21

asagege force-pushed the gtest_unittesting branch from 15c1823 to bf2eee5 Compare February 17, 2026 00:03

enjoy-binbin and others added 2 commits February 17, 2026 09:56

asagege force-pushed the gtest_unittesting branch from bf2eee5 to decce6e Compare February 17, 2026 23:01

sachinvmurthy and others added 2 commits February 17, 2026 15:09

Formatting cast

c06e762

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

asagege force-pushed the gtest_unittesting branch from decce6e to c06e762 Compare February 17, 2026 23:25

Nikhil-Manglore and others added 2 commits February 18, 2026 00:47

asagege force-pushed the gtest_unittesting branch from dc5e43b to 7da1b44 Compare February 18, 2026 21:04

harrylin98 force-pushed the gtest_unittesting branch from 7da1b44 to c06e762 Compare February 18, 2026 21:48

harrylhl and others added 4 commits February 18, 2026 14:09

Merge branch 'unstable' into gtest_unittesting

1d5e0c3

Signed-off-by: Harry Lin <harrylhl@amazon.com>

Merge branch 'feature-gtest' into gtest_unittesting

f38e38b

Signed-off-by: Harry Lin <harrylhl@amazon.com>

Modify GTEST based on C Test changes

3638cd0

Signed-off-by: Alina Liu <alinalq@dev-dsk-alinalq-2b-2db84246.us-west-2.amazon.com> Signed-off-by: Harry Lin <harrylhl@amazon.com>

Make google test support USE_LIBBACKTRACE

25a1bfb

Signed-off-by: Harry Lin <harrylhl@amazon.com>

harrylin98 force-pushed the gtest_unittesting branch from ee80b9d to 25a1bfb Compare February 19, 2026 00:39

asagege force-pushed the gtest_unittesting branch from eda673f to 6de37f5 Compare February 19, 2026 05:13

Fix Crc64CombineBenchmark test

eb538c8

Signed-off-by: Alina Liu <liusalisa6363@gmail.com>

asagege force-pushed the gtest_unittesting branch from 6de37f5 to eb538c8 Compare February 19, 2026 05:13

Comments

Conversation

asagege commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JimB123 Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

asagege Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

JimB123 Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

asagege Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

16 participants

asagege commented Feb 4, 2026 •

edited

Loading