You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem lies in the fact that dicard_all_messages contained two paths that could lead to head.block being read but only one of them would swap the value. This meant that dicard_all_messages could end up observing a non-null block pointer (and therefore attempting to free it) without setting head.block to null. This would then lead to Channel::drop making a second attempt at dropping the same pointer.
The bug was introduced while fixing a memory leak, in
upstream MR #1084,
first published in 0.5.12.
The fix is in
upstream MR #1187
and has been published in 0.5.15
The text was updated successfully, but these errors were encountered:
crossbeam-channel
0.5.13
The internal
Channel
type'sDrop
method has a racewhich could, in some circumstances, lead to a double-free.
This could result in memory corruption.
Quoting from the
upstream description in merge request #1187:
The bug was introduced while fixing a memory leak, in
upstream MR #1084,
first published in 0.5.12.
The fix is in
upstream MR #1187
and has been published in 0.5.15
The text was updated successfully, but these errors were encountered: