go-ipfs version: 0.6.0-dev
Repo version: 9
System version: amd64/linux
Golang version: go1.14.3
Commit 44df41cb08bd2d1cbce72584010926d68d6864a9
I tried to pin /ipfs/QmXQ9wz4VYCRpdXMiHQA6smzBJtoQAPwDe8bt9AeKLXeQc which is the folder with the binaries for go-ipfs 0.5.1.
It stalled twice on the same machine.
The "OverrideSecurityTransports" is on with "noise", "tls", "secio" priority. All other experimental options are deactivated. Routing type is dhtclient to conserve some memory on the 2GB machine.
I killed the IPFS daemon with sigabrt, here's the stack trace:
kill_ipfs_daemon_on_pin_stall.txt
@Stebalien we discussed this shorty on the chat.
Unfortunately, stalled isn't enough information to diagnose this. I'm not even sure if this is a regression or an older bug.
I've recently fixed https://github.com/libp2p/go-libp2p-peerstore/pull/155 (regression since 0.5.0) which may have caused this by preventing reconnects from working properly in some cases.
We've also fixed https://github.com/ipfs/go-bitswap/pull/405 which could have maybe triggered this? But we haven't dug into that enough.
Ok, we've reproduced it.
The problem appeared to go away when using the latest bitswap release (only present in the release-v0.6.0 branch, not on master). That included https://github.com/ipfs/go-bitswap/pull/405. Any chance you could try to confirm?
I can confirm that 9467986a1d50f1387d64a3f95c2af1712dd47e88 is not affected. :)
@Stebalien I did a git bisect, to find the exact commit which fixed this issue. It appears to be a2cd58edf19f04c9554c271124462db701035a3a which is in line with your assumption. The log is attached. :)
Should I open a PR to update the master, or will you do this? :)
We'll merge the release branch back into master when we cut the final release. That will include the fix.
@RubenKelevra can you verify this is fixed in master? The release branch was merged into master so this should no longer be an issue.
Yes, that's fixed since the 0.6 release.
I thought the ticket would autoclose on release :)
Most helpful comment
I can confirm that 9467986a1d50f1387d64a3f95c2af1712dd47e88 is not affected. :)