mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #114] Thread 'test_server:udp:server' panic #60
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#60
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @liranringel on GitHub (Apr 9, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/114
The test
test_server_www_udpseems to leak the thread calledtest_server:udp:serverand panic with that error:First occurred to me in appveyor, and I'm able to reproduce it on my local windows machine:
https://ci.appveyor.com/project/liran-ringel/trust-dns/build/1.0.4/job/33yskkn020b6ec0p
@bluejekyll commented on GitHub (Apr 9, 2017):
Huh. I haven't noticed that anywhere else. Do you have a back trace possibly?
@liranringel commented on GitHub (Apr 9, 2017):
When I don't set RUST_BACKTRACE=1, It stuck.
When I do set RUST_BACKTRACE=1, It just print that the panic happened, but does not display the backtrace.
Then I thought I need to pass
--nocapture, but when I do that, It doesn't panic at all.@bluejekyll commented on GitHub (Apr 9, 2017):
Sounds like a race condition. I don't think I'm doing anything crazy there, so I wonder if there is a bug in the library.
@liranringel commented on GitHub (Apr 10, 2017):
Is that ok that the thread called
test_server:udp:serveris not joined? Threads are detached whenJoinHandleis dropped, not terminated.@liranringel commented on GitHub (Apr 10, 2017):
Ok I set a breakpoint on
panic_unwind::__rust_start_panicwith windbg, that's the backtrace:https://gist.github.com/liranringel/ac938f20e6beecf4b5182013460440dd
@bluejekyll commented on GitHub (Apr 10, 2017):
Woh. I totally misread the docs on that. That's a good catch. I should definitely be joining both threads.
@bluejekyll commented on GitHub (Apr 10, 2017):
Not sure why it's a problem on windows though. It's only a few threads, and all should be cleaned up on process exit.
@bluejekyll commented on GitHub (Apr 10, 2017):
Never mind. Now I'm more confused as to why I have seen this on Linux or macOS. Anyway, I'll look at a patch tonight. Should I set up an app auto account to connect to this?
@liranringel commented on GitHub (Apr 10, 2017):
Sorry I didn't understand the last question.
According to the backtrace, the panic is raised here: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/thread_local.rs#L69
It happens because
TlsAlloc()returnsTLS_OUT_OF_INDEXES(https://msdn.microsoft.com/en-us/library/windows/desktop/ms686801(v=vs.85).aspx).That article says that TLS (thread-local storage) has a limit on windows:
https://msdn.microsoft.com/en-us/library/ms686749(VS.85).aspx
as opposed to linux: http://stackoverflow.com/a/1461048
So if there is a leak of the thread-local storage, it can explain why it happens only on windows.
@bluejekyll commented on GitHub (Apr 10, 2017):
Thanks for the links. I guess the reason I'm confused is because the number of connections even with the leak (which we should fix) should only be 6 or so. But anyway, I'll get a fix in for the thread join.