panic: Future.Set called multiple times
Describe the bug
I have got a panic during sending a message:
Sep 10 08:55:45 mailserver maddy[2079]: panic: Future.Set called multiple times
Sep 10 08:55:45 mailserver maddy[2079]: goroutine 4873 [running]:
Sep 10 08:55:45 mailserver maddy[2079]: github.com/foxcpp/maddy/framework/future.(*Future).Set(0xc000281900, 0x556b49201c00, 0xc0003ac640, 0x556b4933b500, 0xc0003ac620)
Sep 10 08:55:45 mailserver maddy[2079]: github.com/foxcpp/maddy/framework/future/future.go:54 +0x10e
Sep 10 08:55:45 mailserver maddy[2079]: github.com/foxcpp/maddy/internal/target/remote.(*daneDelivery).PrepareConn.func1(0xc000300560, 0x556b4934d4e0, 0xc0003c6d20, 0xc0003f5460, 0x1b)
Sep 10 08:55:45 mailserver maddy[2079]: github.com/foxcpp/maddy/internal/target/remote/security.go:400 +0x225
Sep 10 08:55:45 mailserver maddy[2079]: created by github.com/foxcpp/maddy/internal/target/remote.(*daneDelivery).PrepareConn
Sep 10 08:55:45 mailserver maddy[2079]: github.com/foxcpp/maddy/internal/target/remote/security.go:397 +0xcd
Sep 10 08:55:45 mailserver systemd[1]: maddy.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Sep 10 08:55:45 mailserver systemd[1]: maddy.service: Failed with result 'exit-code'.
Steps to reproduce
- Just sent an email to two addresses on gmail.com and icloud.com
I tried to reproduce this issue but it seems it happened spontaneously.
Configuration file
It's the standard config file, except another domain name.
Environment information
- maddy version: maddy 0.4.0+gf9d5c0c linux/amd64 go1.15.2
I've installed maddy from the source code.
A link to the code line where the issue makes its panic: https://github.com/foxcpp/maddy/blob/master/internal/target/remote/security.go#L400
For reference: Both gmail.com and icloud.com do not have any DANE records set.
The error is still present. Do you need any further information @foxcpp ?
I am unable to identify the root cause of the issue. Just stress testing sending mail to two domains with DANE checking enabled is not revealing anything.
I pushed c3987e3 to master that masks the issue by ignoring duplicated Future.Set calls.
And added slightly more logging in 0000256 for it. This likely has some relation to resolver errors and this is why it is not always happening since most DNS errors are transient.