starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #340] Panic with "can not lookup IPs for no names" #451

New issue

Closed

opened 2026-03-15 22:32:54 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 22:32:54 +03:00

Owner

Originally created by @fafhrd91 on GitHub (Feb 9, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/340

trust-dns-resolver panic 0.8, worked with 0.7
panics only on windows, works fine for unixes.

backtrace:

---- test_resolver stdout ----
	thread 'test_resolver' panicked at 'can not lookup IPs for no names', src\libcore\option.rs:874:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::panicking::default_hook::{{closure}}
             at src\libstd\sys_common/backtrace.rs:57
             at src\libstd/panicking.rs:381
   1: std::panicking::default_hook
             at src\libstd/panicking.rs:391
   2: std::panicking::rust_panic_with_hook
             at src\libstd/panicking.rs:577
   3: std::panicking::begin_panic
             at src\libstd/panicking.rs:538
   4: std::panicking::begin_panic_fmt
             at src\libstd/panicking.rs:522
   5: rust_begin_unwind
             at src\libstd/panicking.rs:498
   6: core::panicking::panic_fmt
             at src\libcore/panicking.rs:71
   7: core::option::expect_failed
             at src\libcore/option.rs:874
   8: <core::option::Option<T>>::expect
             at C:\projects\rust\src\libcore/option.rs:302
   9: <trust_dns_resolver::lookup_ip::InnerLookupIpFuture<C>>::lookup
             at C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-resolver-0.8.0\src/lookup_ip.rs:96
  10: trust_dns_resolver::resolver_future::ResolverFuture::lookup_ip
             at C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-resolver-0.8.0\src/resolver_future.rs:268
  11: actix::actors::resolver::Resolver::new
             at src\actors/resolver.rs:195
  12: <actix::actors::resolver::Connector as actix::handler::Handler<actix::actors::resolver::Resolve>>::handle
             at src\actors/resolver.rs:156
  13: <actix::address::local_envelope::InnerLocalEnvelope<A, M> as actix::address::envelope::EnvelopeProxy>::handle
             at .\src\address/local_envelope.rs:48
  14: <actix::mailbox::Mailbox<A>>::poll
             at .\src/mailbox.rs:91

https://ci.appveyor.com/project/fafhrd91/actix-n9e64/build/1.0.242/job/4eqb35vu3ipq3dn0

Originally created by @fafhrd91 on GitHub (Feb 9, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/340 trust-dns-resolver panic 0.8, worked with 0.7 panics only on windows, works fine for unixes. backtrace: ``` ---- test_resolver stdout ---- thread 'test_resolver' panicked at 'can not lookup IPs for no names', src\libcore\option.rs:874:4 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: 0: std::panicking::default_hook::{{closure}} at src\libstd\sys_common/backtrace.rs:57 at src\libstd/panicking.rs:381 1: std::panicking::default_hook at src\libstd/panicking.rs:391 2: std::panicking::rust_panic_with_hook at src\libstd/panicking.rs:577 3: std::panicking::begin_panic at src\libstd/panicking.rs:538 4: std::panicking::begin_panic_fmt at src\libstd/panicking.rs:522 5: rust_begin_unwind at src\libstd/panicking.rs:498 6: core::panicking::panic_fmt at src\libcore/panicking.rs:71 7: core::option::expect_failed at src\libcore/option.rs:874 8: <core::option::Option<T>>::expect at C:\projects\rust\src\libcore/option.rs:302 9: <trust_dns_resolver::lookup_ip::InnerLookupIpFuture<C>>::lookup at C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-resolver-0.8.0\src/lookup_ip.rs:96 10: trust_dns_resolver::resolver_future::ResolverFuture::lookup_ip at C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-resolver-0.8.0\src/resolver_future.rs:268 11: actix::actors::resolver::Resolver::new at src\actors/resolver.rs:195 12: <actix::actors::resolver::Connector as actix::handler::Handler<actix::actors::resolver::Resolve>>::handle at src\actors/resolver.rs:156 13: <actix::address::local_envelope::InnerLocalEnvelope<A, M> as actix::address::envelope::EnvelopeProxy>::handle at .\src\address/local_envelope.rs:48 14: <actix::mailbox::Mailbox<A>>::poll at .\src/mailbox.rs:91 ``` https://ci.appveyor.com/project/fafhrd91/actix-n9e64/build/1.0.242/job/4eqb35vu3ipq3dn0

kerem

2026-03-15 22:32:54 +03:00

closed this issue
added the
crate:resolver

bug:critical

has workaround
labels

kerem commented

2026-03-15 22:33:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 9, 2018):

Do you have the query parameters for trust_dns_resolver::resolver_future::ResolverFuture::lookup_ip?

@bluejekyll commented on GitHub (Feb 9, 2018): Do you have the query parameters for `trust_dns_resolver::resolver_future::ResolverFuture::lookup_ip`?

kerem commented

2026-03-15 22:33:15 +03:00

Author

Owner

@fafhrd91 commented on GitHub (Feb 9, 2018):

it is "localhost"

@fafhrd91 commented on GitHub (Feb 9, 2018): it is "localhost"

kerem commented

2026-03-15 22:33:20 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 10, 2018):

It looks like your test is on 32bit, correct? Do you know if the same issue is happening on 64bit?

@bluejekyll commented on GitHub (Feb 10, 2018): It looks like your test is on 32bit, correct? Do you know if the same issue is happening on 64bit?

kerem commented

2026-03-15 22:33:25 +03:00

Author

Owner

@fafhrd91 commented on GitHub (Feb 10, 2018):

same happen on all windows related tests, 32/64bit gnu/msvc

@fafhrd91 commented on GitHub (Feb 10, 2018): same happen on all windows related tests, 32/64bit gnu/msvc

kerem commented

2026-03-15 22:33:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 10, 2018):

ok, I see what the issue is in the code, though I don't know why it was working before vs. now...

I think making this a FQDN by adding a final dot, localhost., will workaround this issue. I'll try and take a look when I have a minute to understand why there was a regression here and add a test case for this.

@bluejekyll commented on GitHub (Feb 10, 2018): ok, I see what the issue is in the code, though I don't know why it was working before vs. now... I think making this a FQDN by adding a final dot, `localhost.`, will workaround this issue. I'll try and take a look when I have a minute to understand why there was a regression here and add a test case for this.

kerem commented

2026-03-15 22:33:35 +03:00

Author

Owner

@fafhrd91 commented on GitHub (Feb 10, 2018):

thanks

@fafhrd91 commented on GitHub (Feb 10, 2018): thanks

kerem commented

2026-03-15 22:33:40 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 10, 2018):