-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
concurrent map iteration and map write in debug logging #1599
Comments
We should probably not try to log a connection as a string: https://github.com/libp2p/go-libp2p-swarm/blob/2c34422a83f4f8740aafa7f37e28076f733388dd/swarm_listen.go#L103 |
@aschmahmann @guseggert Have you seen this in production? Given that concurrent map operations cause (unrecoverable) panics, I'd expect this to happen quite frequently. Is there desire on your side to cut a v0.13.x IPFS patch release? If so, we'd provide a v0.20.x patch release of libp2p. |
2022-06-20 update: This code was introduced in January 2018. We should fix this (logging something like @mrd0ll4r, do you want to send us a PR? Note that the swarm now lives in this repo, in |
I'm sorry, I don't quite have the time to work this out at the moment :( |
@marten-seemann Could you expand a bit more on the recommended fix, please?
|
@schomatis It's about this line: go-libp2p/p2p/net/swarm/swarm_listen.go Line 128 in 1fd5029
It's logging the entire connection struct (which contains a map, and therefore causes the concurrent map access). Instead, we should just log local multiaddr <-> remote multiaddr. This would literally be a one line fix. |
2022-07-01 conversation: @marten-seemann is going to do the quick fix here. |
go-ipfs v0.13.0, go-libp2p-swarm@v0.10.2
Trying go-ipfs v0.13.0 currently. Compiled from v0.13.0 sources with Go 1.18.3 on Linux x86_64. Running on Linux x86_64.
Since the repository was archived/moved, I'm opening the issue here.
(Possibly) relevant changes to the stock IPFS config:
Invocation:
LIBP2P_SWARM_FD_LIMIT=100000 IPFS_LOGGING="debug" ipfs-v0.13.0 daemon
Messages logged from that line are rather unreadable in general:
The map it logs grows over time.
This issue is reproducible for me. Just leave it running for a few minutes and it'll fail eventually.
The text was updated successfully, but these errors were encountered: