resolves issue #3262 #3268
resolves issue #3262 #3268
Conversation
It appears that the slice size of `n.Links` is being modified after the destination capacity of `pbn.Links` is set, thereby causing a panic when attempting to access an index out of range on the new slice. By using append, we can avoid using mutexes and retain most of the original performance.
|
Hrm... I think that the issue in 3262 is likely a race condition. In that event, this change won't fix the problem |
|
You are correct that it appears to be a race condition, but why do you say this fix won't solve the problem? |
|
Because this fix appends an empty node to the end of an already allocated array. With no race condition involved, it would just append entries to the end of the existing array, resulting in us having a links array of twice the length we expect. And since this doesnt fix the actual race condition, when the race condition actually happens, we're going to have an array of undefined length as the appends will be interspersed between calling goroutines. |
|
Oh, I forgot to change the make statement. I'll do that and then it'll be correct. Let me know if you need a playground proof. |
|
Fixed. Let me know if you need a playground proof. |
|
@kf6nux you need to fix your commit messages, please see the above message from GitCop. Since you have two commits you will need to do a |
It appears that the slice size of
n.Linksis being modified after the destination capacity ofpbn.Linksis set, thereby causing a panic when attempting to access an index out of range on the new slice. By using append, we can avoid using mutexes and retain most of the original performance.