Handle RDB version differences

[AlRodriguezGar14]

I followed the documentation from Redis to build the .rdb file parser. In versions 10 and 7 it works, but when I test against the app, it’s using the version 3 and it doesn’t work anymore.

The challenge states:

The header contains the magic string REDIS , followed by a four-character RDB version number. In this challenge, the test RDB files all use version 7. So, the header is always REDIS0007 .

But this information is wrong.

Any advice on how to deal with this? I’m really stuck.

[andy1li]

Thanks for highlighting this!

This information is indeed in conflict with the tester, which is currently using a RDB file labelled as REDIS0003.

Let me check with the team, and I’ll get back to you before tomorrow.

[andy1li]

We’ve just updated both the stage instructions and the tester, upgrading both to RDB version 11.

[AlRodriguezGar14]

You guys are amazing

Would it be possible for the tester to share the file binary content for debugging or at least to “reverse engineer” it? I still can’t figure out what’s wrong, as reading the tests it feels as if the metadata separators 0xFA, 0xFE, and 0xFB were missing, or at least as if the file didn’t have the documentation’s structure. I don’t know how to proceed at this point without the file.

If it’s not possible no worries, it’s understandable and probably it’s just me missing something.

What I mean with my request (this is the dump.rdb file my computer is generating and what my program reads):

[andy1li]

Here you are. Use this sample file while we work out a more permanent solution.

raspberry.rdb (111 Bytes)

[AlRodriguezGar14]

Thank you! Well, something weird seems to be happening. When reading the file locally, it just works. When testing on the other hand, crashes.

Local:

vs Test:

[andy1li]

Looks like the tester (client) received an unexpected empty array while expecting an array of length one.

To investigate, consider logging:

1. What the master has read from the RDB file.
2. Whether the response corresponds to what the master has read.

[AlRodriguezGar14]

The problem is that my program is not delivering anything because there’s no separator (according to the documentationn 0xFA, 0xFE, 0xFE) from the entries.

So basically, when executing the program locally, it runs correctly and retrieves the data. The same program against the tester is not working.

[AlRodriguezGar14]

I tested in different computers and docker containers and it works everywhere but the tests. Is it possible to know where the OS they run on so that I can try to emulate the same error locally?

Thank you

[andy1li]

Let me check with the team, and I’ll get back to you within 24 hours.

Meant to take a look at your code today, but have to do that tomorrow too.

[AlRodriguezGar14]

No rush at all. At this point this is just about personal pride vs the tester. Thank you for your diligent help.

[andy1li]

Our tests for Redis in cpp run on Debian GNU/Linux 12 (bookworm) [Dockerfile].

I did a bunch of logs, and could confirm that:

1. The file was not corrupted.
2. The parsing went well, until after the magic string and the RDB version.
3. Everything from this point was ignored till the end of the file.

So a crucial question is:

Can the code read the next byte 0xFA correctly, and match opcode == 0xFA?

The result is no and no.

The reason is that char is signed by default on most platforms, meaning char opcode interprets 0xFA as -6, thus ignoring opcode (-6) == 0xFA (250)

---

Do you by any chance use an ARM-based machine, where char could be unsigned by default? @AlRodriguezGar14

You can do this to find out:

char opcode = 0xFA;

std::cout << "opcode as int: " << int(opcode) << std::endl;

if (std::is_signed<decltype(opcode)>::value)
{
  std::cout << "opcode is signed." << std::endl;
}
else
{
  std::cout << "opcode is unsigned." << std::endl;
}

[AlRodriguezGar14]

OMG, this was the source of the issue

Yes, I’ve always been using ARM, so I didn’t even think about this possibility (honestly I had no idea). You guys are amazing.