github-vet / rangeloop-pointer-findings

Issue tracker collects instances of Go code on GitHub that make use of references to range loop variables.
0 stars 0 forks source link

mit-dci/lit: qln/multihop.go; 82 LoC #3890

Open githubvet opened 3 years ago

githubvet commented 3 years ago

Found a possible issue in mit-dci/lit at qln/multihop.go

Below is the message reported by the analyzer for this snippet of code. Beware that the analyzer only reports the first issue it finds, so please do not limit your consideration to the contents of the below message.

range-loop variable mh used in defer or goroutine at line 157

Click here to see the code in its original context.

Click here to show the 82 line(s) of Go which triggered the analyzer. ```go for idx, mh := range nd.InProgMultihop { var nullHash [32]byte if !mh.Succeeded && bytes.Equal(nullHash[:], mh.HHash[:]) { targetNode := mh.Path[len(mh.Path)-1] targetIdx, err := nd.FindPeerIndexByAddress(bech32.Encode("ln", targetNode.Node[:])) if err != nil { return fmt.Errorf("not connected to destination peer") } if msg.Peer() == targetIdx { logging.Debugf("Found the right pending multihop. Sending setup msg to first hop\n") // found the right one. Set this up firstHop := mh.Path[1] ourHop := mh.Path[0] firstHopIdx, err := nd.FindPeerIndexByAddress(bech32.Encode("ln", firstHop.Node[:])) if err != nil { return fmt.Errorf("not connected to first hop in route") } nd.RemoteMtx.Lock() var qc *Qchan for _, ch := range nd.RemoteCons[firstHopIdx].QCs { if ch.Coin() == ourHop.CoinType && ch.State.MyAmt-consts.MinOutput-ch.State.Fee >= mh.Amt && !ch.CloseData.Closed && !ch.State.Failed { qc = ch break } } if qc == nil { nd.RemoteMtx.Unlock() return fmt.Errorf("could not find suitable channel to route payment") } nd.RemoteMtx.Unlock() nd.InProgMultihop[idx].HHash = msg.HHash err = nd.SaveMultihopPayment(nd.InProgMultihop[idx]) if err != nil { return err } // Calculate what initial locktime we need wal, ok := nd.SubWallet[ourHop.CoinType] if !ok { return fmt.Errorf("not connected to wallet for cointype %d", ourHop.CoinType) } height := wal.CurrentHeight() // Allow 5 blocks of leeway per hop in case people's wallets are out of sync locktime := height + int32(len(mh.Path)*(consts.DefaultLockTime+5)) // This handler needs to return before OfferHTLC can work go func() { logging.Infof("offering HTLC with RHash: %x", msg.HHash) err = nd.OfferHTLC(qc, uint32(mh.Amt), msg.HHash, uint32(locktime), [32]byte{}) if err != nil { logging.Errorf("error offering HTLC: %s", err.Error()) return } // Set the dirty flag on each of the nodes' channels we used nd.ChannelMapMtx.Lock() for _, hop := range nd.InProgMultihop[idx].Path { for i, channel := range nd.ChannelMap[hop.Node] { if channel.Link.CoinType == hop.CoinType { nd.ChannelMap[hop.Node][i].Dirty = true break } } } nd.ChannelMapMtx.Unlock() var data [32]byte outMsg := lnutil.NewMultihopPaymentSetupMsg(firstHopIdx, msg.HHash, mh.Path, data) logging.Debugf("Sending multihoppaymentsetup to peer %d\n", firstHopIdx) nd.tmpSendLitMsg(outMsg) }() break } } } ```

Leave a reaction on this issue to contribute to the project by classifying this instance as a Bug :-1:, Mitigated :+1:, or Desirable Behavior :rocket: See the descriptions of the classifications here for more information.

commit ID: 511d703a128dca889b36170d1a1d99af9a02e959

mdempsky commented 3 years ago

This case is interesting, because it does use a goroutine that captures the range loop variable, but there's a break statement immediately afterwards, so the variable never gets reassigned after that.

kalexmills commented 3 years ago

That is weird. I honestly didn't think I'd see an example of the loopclosure linter which wasn't a bug. 🤷‍♂️