#GT1 Error receiving data: Label length exceeds buffer size

[ptrhcpang]

I’m stuck on Stage #GT1

A number of “stuck on #GT1” posts have mentioned that functions for previous steps stop working. I seem to be having a like problem (but more severe) in that the line:

            buf, source = udp_socket.recvfrom(BUFFER_SIZE)

which worked to get DNS messages from the client in previous stages, now seem to be triggering a buffer overflow error (it is not coming from the resolver). I do not understand why this is the case.
I have tried increasing the size of the buffer substantially but it is triggering the same error. Also, the smaller buffer size was fine for previous stages.

Thank you in advance if anyone has insight as to what might be happening!

[andy1li]

Hey @ptrhcpang, I added a couple of logs here:

It dose not look like the issue was caused by the length of res_resp_buf:

Let me know if you’d like help debugging the parse_answers function.

[ptrhcpang]

Hi @andy1li, thank you so much for having a look at this!! I agree that the problem does not seem to be the length of the res_resp_buf buffer for the response from the resolver. In particular, the except seems to be triggered by the outer try-except pair receiving the initial message from the tester:

try:
            buf, source = udp_socket.recvfrom(BUFFER_SIZE)

What confuses me is that this line was basically unchanged from previous stages. Would really appreciate help with figuring out where the bug is because I’m still pretty stumped… Thank you in advance!

[andy1li]

What confuses me is that this line was basically unchanged from previous stages.

There are actually a few factors at play here. If you ignore --resolver, always set decompFlag = False, and run codecrafters test --previous, you’ll see that the current code no longer passes the earlier stages.

But let’s focus on the current issue first:

In particular, the except seems to be triggered by the outer try-except pair receiving the initial message from the tester: buf, source = udp_socket.recvfrom(BUFFER_SIZE)

If you add this log, you’ll notice that the error is actually coming from labelseq_parser.

Let me know if you’d like help debugging labelseq_parser.

[ptrhcpang]

Hi @andy1li — thank you so much for spotting where the error message was coming from. It seems like the error was (again!) comparing the buffer length by a number that is one more or less than it should be compared with (i.e., a problem of counting from 0 or 1)…

There are still a few unrelated confusing things in #GT1, even though I passed the stage. But probably best to start a new thread. Thank you again!