Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix getting stuck with a full buffer without a valid frame #41

Merged
merged 2 commits into from
May 7, 2024

Conversation

Emil-Juhl
Copy link
Contributor

See the commits for details.

Tl;dr if one is to fill the entire read-buffer with data, which doesn't contain an entire valid hdlc frame, the library would get completely stuck. Rather than only erasing from the read-buffer upon successful decoding, clear the buffer entirely if it is full and decoding fails.

Only allowing `erase` up to, not including, the tail pointer means that
an entire buffer clearing can never really happen unless the tail is
actually past-the-end of the underlying memory area.

Allow erases to cover the entire span from head to tail inclusively.

On a side note, there doesn't seem to be a good reason to dissallow even
erase where `last` is past the tail pointer. So no extra sanitization
logic is added for such cases.
Copy link
Collaborator

@hansbinderup hansbinderup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch 👍
Only have one concern - otherwise it looks alright

include/Hdlcpp.hpp Show resolved Hide resolved
include/Hdlcpp.hpp Outdated Show resolved Hide resolved
If for some reason the read buffer got filled with data, but no complete
hdlc frame was present, the library would get stuck. This is because the
buffer is only ever erased from in the good case scenario.

As a very simple workaround, albeit not a great one, just drop the
entire buffer if it is not possible to deframe the data it contains
_and_ it doesn't have room left for more data.

Ideally, the recovery mechanism would only drop bytes until a start byte
is spotted to make it more graceful on a buffer containing a partial
frame.
This is, however, already an edge case (otherwise users of the library
should be experiencing these lockups at the moment), and thus it seems
reasonable to just go for a harsh but simple workaround.
@Emil-Juhl Emil-Juhl force-pushed the emdj/clear-buffer-when-full branch from a1dc3a7 to a42d459 Compare May 3, 2024 08:54
@Emil-Juhl Emil-Juhl merged commit 5117edf into master May 7, 2024
1 check passed
@Emil-Juhl Emil-Juhl deleted the emdj/clear-buffer-when-full branch May 7, 2024 10:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants