net: lookupIPAddr dns resolving panic by data race. about kratos HOT 4 CLOSED

🤖

Thank you for providing the detailed information and the code to reproduce the issue. It's clear that you're experiencing a panic due to a data race when using the lookupIPAddr function for DNS resolving in the Kratos microservices framework.

The error message you provided indicates a segmentation violation, which usually occurs when a program tries to read or write an illegal memory location. This could be due to a nil pointer dereference or an out-of-bounds array index.

You mentioned that you're using Kratos version v2.6.2 and Go version 1.20. The issue seems to be related to the use of the sync.Pool object pool.

To better understand and resolve this issue, could you please provide the following additional information:

1. Have you tried updating to the latest version of Kratos (v2.7.1) to see if the issue persists?
2. Could you provide the full stack trace of the panic? This could help identify the exact line of code causing the issue.
3. Are there any specific conditions under which the panic occurs? For example, does it happen every time you run the server and start 200 threads, or only under certain conditions?
4. Have you made any modifications to the Kratos or Go runtime environment that could potentially affect the behavior of the lookupIPAddr function or the sync.Pool object pool?

Your answers to these questions will help us better understand the issue and find a solution.

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

from kratos.

🤖

Hello @lyouthzzz,

Nice to meet you! I'm Dosu, a helpful bot designed to assist you with Kratos. While we're waiting for a human maintainer, I'm here to help solve bugs, answer questions, and guide you on how to become a contributor.

I'm currently reviewing your issue and will provide a full answer shortly. Hang tight!

from kratos.

more detail: golang/go#63927

from kratos.

@lyouthzzz I still have this problem after updating to v2.7.2.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x63f1b2]

goroutine 3315105 [running]:
net.(*Resolver).lookupIPAddr(0x3a68320, {0x2316a70?, 0xc007a505a0}, {0x1e6ff2f, 0x3}, {0xc003c8bc20, 0x26})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/lookup.go:346 +0x8b2
net.(*Resolver).internetAddrList(0x2316a70?, {0x2316a70?, 0xc007a505a0?}, {0x1e6ff2f, 0x3}, {0xc003c8bc20?, 0x2b?})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/ipsock.go:288 +0x67a
net.(*Resolver).resolveAddrList(0x3a9db40?, {0x2316a70, 0xc007a505a0}, {0x1e7119f, 0x4}, {0x1e6ff2f?, 0x433a90?}, {0xc003c8bc20, 0x2b}, {0x0, ...})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/dial.go:222 +0x41b
net.(*Dialer).DialContext(0xc0000a22a0, {0x2316a70, 0xc007a505a0}, {0x1e6ff2f, 0x3}, {0xc003c8bc20, 0x2b})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/dial.go:410 +0x448
net/http.(*Transport).dial(0x0?, {0x2316a70?, 0xc007a505a0?}, {0x1e6ff2f?, 0x0?}, {0xc003c8bc20?, 0x8?})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/http/transport.go:1170 +0xda
net/http.(*Transport).dialConn(0x3a4bf40, {0x2316a70, 0xc007a505a0}, {{}, 0x0, {0xc006a357a0, 0x4}, {0xc003c8bc20, 0x2b}, 0x0})
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/http/transport.go:1608 +0x83f
net/http.(*Transport).dialConnFor(0xc0041347e0?, 0xc003f138c0)
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/http/transport.go:1450 +0xb0
created by net/http.(*Transport).queueForDial
	/opt/hostedtoolcache/go/1.19.13/x64/src/net/http/transport.go:1419 +0x3f2

from kratos.