Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/183#discussion_r216510493
--- Diff: src/libguac/parser.c ---
@@ -222,7 +222,11 @@ int guac_parser_read(guac_parser* parser, guac_socket*
socket, int usec_timeout)
retval = guac_socket_select(socket, usec_timeout);
if (retval <= 0)
return -1;
-
+
+ /* Reset pointers if instruction buf len is less than max
instruction len */
+ if (buffer_end - unparsed_end < GUAC_INSTRUCTION_MAX_LENGTH)
+ unparsed_end = unparsed_start = parser->__instructionbuf;
--- End diff --
> First, all TCP traffic contains full instruction.
What matters when considering the validity of these changes and the
underlying cause of what you're seeing are the specific results of each call to
`read()`. Each call to `read()` will populate the buffer with an unknown
portion of that stream. The size of each chunk in the sequence matters.
If it's been established that the TCP stream is correct in itself, that's
good, but that's not the whole picture.
> ... somehow (no idea with system calls behavior),
`guac_socket_fd_read_handler` lost part of the instruction, and then reads next
instruction.
That isn't possible. Each call to `read()` is not guaranteed to return all
data written to the socket - it may only return part of that data, but the next
call to `read()` should return yet more of the data, and so on. It's not
possible for data to appear to just vanish between reads unless:
1. Multiple threads are both consuming the data from the same file
descriptor.
2. `__write_all()` is not actually writing everything.
You are testing against unmodified guacamole-server master, correct? You're
not including your changes from #179?
---
