Repository navigation
Making base64 cctest deterministic makes it fail #13636
Description
The following patch makes the base64 cctest fail for me:
diff --git a/test/cctest/test_base64.cc b/test/cctest/test_base64.cc
index fbdb969b4cbe..ecb61aa84cea 100644
--- a/test/cctest/test_base64.cc
+++ b/test/cctest/test_base64.cc
@@ -12,7 +12,7 @@ TEST(Base64Test, Encode) {
auto test = [](const char* string, const char* base64_string) {
const size_t len = strlen(base64_string);
char* const buffer = new char[len + 1];
- buffer[len] = 0;
+ memset(buffer, 0, len+1);
base64_encode(string, strlen(string), buffer, len);
EXPECT_STREQ(base64_string, buffer);
delete[] buffer;
@@ -48,7 +48,7 @@ TEST(Base64Test, Decode) {
auto test = [](const char* base64_string, const char* string) {
const size_t len = strlen(string);
char* const buffer = new char[len + 1];
- buffer[len] = 0;
+ memset(buffer, 0, len+1);
base64_decode(buffer, len, base64_string, strlen(base64_string));
EXPECT_STREQ(string, buffer);
delete[] buffer;That shouldn’t be happening, because buffer might be 0-initialized anyway. Without this patch, valgrind complains that we use uninitialized parts of buffer (rightfully so, I assume).
I don’t have the time to look into this right now, but I assume either the test is just asserting the wrong values, or something’s off with our base64 decoder implementation.
Activity
seishun commentedon Jun 12, 2017
Not familiar with cctest. How do I run (or preferably, debug) them?
addaleax commentedon Jun 12, 2017
@seishun You can run them with
./out/Release/cctestor./out/Debug/cctest, depending on whether you have a debug build or not; for debugging, I’m not really sure how to answer that question beyond “use your favourite C++ debugger” or “addfprintf(stderr, …);in lots of places”…seishun commentedon Jun 13, 2017
Great, so you can just debug
cctestas usual. Things are more complicated with libuv tests due to subprocesses.In theory, yes. In practice,
bufferis pretty much guaranteed to contain the result of the previous test. Sincebase64_decodedoesn't null-terminate the result string, then the test will incorrectly succeed if the new result is just shorter. By the way, I can reproduce the test failure in a debug build even without your patch.I'll try to look into what's going on in
base64_decode, but I'm sure someone can figure it out faster than me.addaleax commentedon Jun 13, 2017
You could try to filter using
cctest --gtest_filter='*Decode*'to only get the failing test, maybe that helps?Makes sense… :/