[GH-ISSUE #355] error notifying wait, possible future leak #462

New issue

Closed

opened 2026-03-15 22:39:29 +03:00 by kerem · 1 comment

kerem commented

2026-03-15 22:39:29 +03:00

Owner

Originally created by @glebpom on GitHub (Mar 6, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/355

Hi,

I'm seeing this panic

error notifying wait, possible future leak: Err(ResolveError(Proto(Timeout), (None, stack backtrace ...

the backtrace shows that it relates to drop_cancelled function. Here is the code:

        for id in canceled {
            if let Some((req, _)) = self.active_requests.remove(&id) {
                // TODO, perhaps there is a different reason timeout? but there shouldn't be...
                //  being lazy and always returning timeout in this case (if it was canceled then the
                //  then the otherside isn't really paying attention anyway)

                // complete the request, it's failed...
                req.send(Err(E::from(ProtoErrorKind::Timeout.into())))
                    .expect("error notifying wait, possible future leak");
            }

It seems like (but I'm not sure) that it happens when the whole future (where resolving is involved) is completed, and resolve timeout happens after that:

  resolver
        .lookup_ip("google.com")
        .and_then(|_| ...do something)
        .select(stop)

If stop is completed, and timeout happens after that, is it possible that this future leak happen?

Originally created by @glebpom on GitHub (Mar 6, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/355 Hi, I'm seeing this panic ``` error notifying wait, possible future leak: Err(ResolveError(Proto(Timeout), (None, stack backtrace ... ``` the backtrace shows that it relates to `drop_cancelled` function. Here is the code: ``` for id in canceled { if let Some((req, _)) = self.active_requests.remove(&id) { // TODO, perhaps there is a different reason timeout? but there shouldn't be... // being lazy and always returning timeout in this case (if it was canceled then the // then the otherside isn't really paying attention anyway) // complete the request, it's failed... req.send(Err(E::from(ProtoErrorKind::Timeout.into()))) .expect("error notifying wait, possible future leak"); } ``` It seems like (but I'm not sure) that it happens when the whole future (where resolving is involved) is completed, and resolve timeout happens after that: ``` resolver .lookup_ip("google.com") .and_then(|_| ...do something) .select(stop) ``` If `stop` is completed, and timeout happens after that, is it possible that this future leak happen?

kerem

2026-03-15 22:39:29 +03:00

closed this issue
added the
bug

crate:proto
labels

kerem commented

2026-03-15 22:39:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 6, 2018):

I haven't seen this reported before. The reason for the panic is that there is the potential that there is a Future waiting for a DNS response that did not receive that send. In that case, there could be a memory leak as it would never stop waiting, there may be a better way to deal with this edge case. It's been a while since I've looked at this section of code.

As a work around, if you have the src, you could remove the expect, and log a warning. I won't be able to look at this until later today. I'm thinking that in the scenario you've laid out, it's possible that the early termination of the future with stop is interfering with the internal message passing in the DNS protocol handlers.

edit: actually thinking of your scenario, the stop basically removes your interest in the DNS result, and that's why this error is happening. Given that, it may be safe to always ignore this error... Again, I need to review the code to understand if that's true later.

@bluejekyll commented on GitHub (Mar 6, 2018): I haven't seen this reported before. The reason for the panic is that there is the potential that there is a Future waiting for a DNS response that did not receive that send. In that case, there could be a memory leak as it would never stop waiting, there may be a better way to deal with this edge case. It's been a while since I've looked at this section of code. As a work around, if you have the src, you could remove the expect, and log a warning. I won't be able to look at this until later today. I'm thinking that in the scenario you've laid out, it's possible that the early termination of the future with `stop` is interfering with the internal message passing in the DNS protocol handlers. ---- edit: actually thinking of your scenario, the `stop` basically removes your interest in the DNS result, and that's why this error is happening. Given that, it may be safe to always ignore this error... Again, I need to review the code to understand if that's true later.

kerem referenced this issue

2026-03-15 22:47:07 +03:00

[GH-ISSUE #462] Create a general purpose global Resolver #493

kerem referenced this issue

2026-03-15 23:04:18 +03:00

[GH-ISSUE #650] syncrhonous Resolver should maintain conn pool across uses #262