a potential data race occurs in the httpConfig field in rpcstack.go

[ririli]

Hi, I found out by static analysis that: In the rpcstack.go file, there is a potential data race risk related to the h.ttpConfig field. Specifically:The h.httpConfig field is read/written 6 times.5 of these accesses are properly synchronized using h.mutex.RLock() or Lock().1 read operation L212 is not locked.So I think whether to add a lock to it for mutual exclusion. Please could you help me to confirm this issue?

[stevenegoavil]

Hello there, I’d like to get a crack at solving this issue. I read through your post and I believe I can help. My plan is to wrap the unsynchronized read in an RLock(), confirm thread safety with testing, and make sure the fix follows the repo’s concurrency conventions. I think I can handle this quickly, let me know if you'd like me to take a look.

[ririli]

Ok，i think so，thanks

[stevenegoavil]

Just a quick followup, I submitted a PR to address this issue here: (https://github.com/ethereum/go-ethereum/pull/32035). The fix wraps the unsynchronized read in RLock(), includes a race test, and follows the repo's concurrency style. Let me know if there’s anything I should revise, happy to improve it further!

[ririli]

I read your PR and it is exactly what I thought. Thank you for your reply.

[stevenegoavil]

I submitted PR #32035 to fix the data race in rpcstack.go. An alternative fix has been merged successfully into the repo. Please let me know if there are any other concurrency or Go-related issues you’d like help with. Could you also confirm my involvement on OnlyDust when you have a chance? Thank you!