Fix hardened_malloc error #10
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
From logs, the crash happens at the first loop, which is fairly strange. |
JingMatrix
force-pushed
the
divest_os
branch
2 times, most recently
from
c4cef3d to
e7b0d47
Compare
DivestOS users reported that vector::resize might trigger `hardened_malloc fatal error: detected write after free`. From the error message, this can only happen when the for loop is executed for multiple times. Note that the for loop is effective only when data to read still exist in the socket queue, which is the case when we call `recv` with flag MSG_PEEK. Hence, after we call `recv` with zero flags, which consume data in the socket queue, we should break the for loop. Note: previously, we break the for loop according to errno == EAGAIN. As a simplification, we also move the resize call to the initialization of buf.
It is strange in the crash log that no logs recorded when a new loop starts.
In case that the hardened_malloc error is a c++ problem, we choose to do the memory management manually.
Since we call free after the status are updated, it might cause problem when status struct are destroyed. Print buf addr to see if it is duplicated.
From the log, we see that malloc always returns the same address from the heap. Hence, we simply keep this buf for SocketHandler. This might solve the issue of `write after free` since we don't free it while handling events.
DivestOS users reported that vector::resize might trigger `hardened_malloc fatal error: detected write after free`. From the error message, this can only happen when the memory allocator is called for multiple times. From the log, we see that malloc always returns the same address from the heap. Hence, we can simply keep the buffer during the lifetime of SocketHandler.
JingMatrix
added a commit
that referenced
this pull request
Jan 10, 2025
DivestOS users reported that vector::resize might trigger `hardened_malloc fatal error: detected write after free`. From the error message, this can only happen when the buffer is freed for multiple times. Hence, we can simply keep the buffer during the lifetime of SocketHandler. Note: from the log, we see that malloc always returns the same address from the heap.
JingMatrix
added a commit
that referenced
this pull request
Jan 10, 2025
DivestOS users reported that vector::resize might trigger `hardened_malloc fatal error: detected write after free`. From the error message, this can only happen when the buffer is freed for multiple times. Hence, we can simply keep the buffer during the lifetime of SocketHandler. Note: from the log, we see that malloc always returns the same address from the heap.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DivestOS users reported that vector::resize might trigger
hardened_malloc fatal error: detected write after free.From the error message, this can only happen when the for loop is executed for multiple times.
Note that the for loop is effective only when data to read still exist in the socket queue, which is the case when we call
recvwith flag MSG_PEEK.Hence, after we call
recvwith zero flags, which consume data in the socket queue, we should break the for loop.Note: previously, we break the for loop according to errno == EAGAIN.
As a simplification, we also move the resize call to the initialization of buf.