Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dns.setServers() crash #894

Closed
BLeQuerrec opened this issue Feb 19, 2015 · 27 comments
Closed

dns.setServers() crash #894

BLeQuerrec opened this issue Feb 19, 2015 · 27 comments
Assignees
Labels
confirmed-bug Issues with confirmed bugs. dns Issues and PRs related to the dns subsystem.

Comments

@BLeQuerrec
Copy link

Hi,

In a Vagrant Ubuntu environment, io.js crashes with this code:

$ cat dns.js
var dns = require('dns');

dns.resolveSoa('example.org', function(err, soa){
    console.log(soa.nsname);
    dns.resolve4(soa.nsname, function (err, nameServers) {
        console.log(dns.getServers());
        dns.setServers(nameServers);
        console.log(dns.getServers());
    });
});

Expected result:

$ iojs dns.js
sns.dns.icann.org
[ '10.0.2.3' ]
[ '199.4.28.26' ]

Actual result:

$ iojs dns.js
sns.dns.icann.org
[ '10.0.2.3' ]
iojs: ../deps/cares/src/ares_destroy.c:102: ares__destroy_servers_state: Assertion `ares__is_list_empty(&server->queries_to_server)' failed.
Aborted (core dumped)

Other informations:

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.1 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.1 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
$ iojs -v
v1.2.0

DNS test (in test/simple/test-dns.js) ends successfully. This bug can be fixed by removing line 102 in deps/cares/src/ares_destroy.c.
Node.js bug: nodejs/node-v0.x-archive#9243

@tellnes
Copy link
Contributor

tellnes commented Feb 19, 2015

I'm seeing similar results on os x 10.9.5

$ iojs dns.js
sns.dns.icann.org
[ '10.0.0.1' ]
Assertion failed: (ares__is_list_empty(&server->queries_to_server)), function ares__destroy_servers_state, file ../deps/cares/src/ares_destroy.c, line 102.
Abort trap: 6

@Fishrock123 Fishrock123 added the confirmed-bug Issues with confirmed bugs. label Feb 19, 2015
@rvagg
Copy link
Member

rvagg commented Feb 19, 2015

@iojs/tc can someone qualified jump on this? otherwise it'll have to go in to "known issues" in 1.3.0.

@indutny
Copy link
Member

indutny commented Feb 19, 2015

Will do.

@indutny indutny self-assigned this Feb 19, 2015
indutny added a commit to indutny/io.js that referenced this issue Feb 20, 2015
`ares_set_servers()` should terminate all active queries to previous
servers before destroying them.

When invoking query callback remove it from the queue, to ensure that it
won't be called two times.

Fix: nodejs#894
@indutny
Copy link
Member

indutny commented Feb 20, 2015

I have two solutions to the problem:

What do you think will be most preferable? cc @bnoordhuis

@silverwind
Copy link
Contributor

wait until query completion before changing the servers

Would that block new queries from using the updated servers until all outstanding requests finish? If so, any way to have setServers apply for all following queries?

@tellnes
Copy link
Contributor

tellnes commented Feb 20, 2015

The best solution would be that queries created before calling setServers is using the old servers while queries created after calling setServers is using the new servers.

If I understand your solutions correctly, that would mean wait until query completion and queue up new queries.

@silverwind
Copy link
Contributor

Meant what @tellnes said. If that's possible, there's no need to throw.

@indutny
Copy link
Member

indutny commented Feb 20, 2015

Good suggestion. I'll see what I can do.

@silverwind
Copy link
Contributor

I'm unsure how far you got here @indutny, but if it proves easier to add support for a server option on resolve like I proposed in #1071, we could possibly deprecate setServers and getServers in 2.0 or 3.0.

@silverwind
Copy link
Contributor

Once this is fixed to work like #894 (comment) describes, I can work on adding the resolve option for a truly async API. Probably not worth to deprecate after all.

rvagg added a commit to rvagg/io.js that referenced this issue Mar 12, 2015
Use an EE with some state data to gate async resolution operations in
c-ares so that setServers() can run independently.

Likely a temporary fix for nodejs#894
with a better solution being to fix c-ares to do this without barfing.
@silverwind
Copy link
Contributor

@emotional-engineering c-ares is now on GitHub. Would you mind posting your patch as a pull request there? @indutny mentioned they should be more responsive now.

@silverwind
Copy link
Contributor

Filed c-ares/c-ares#41

@jasnell
Copy link
Member

jasnell commented Apr 22, 2016

Closing this as it's a duplicate of #1071 (or, 1071 is a duplicate of this... either way, we don't need two issues tracking the same problem). It's still an open issue, however.

@jasnell jasnell closed this as completed Apr 22, 2016
@silverwind
Copy link
Contributor

silverwind commented Apr 22, 2016

I have to object. This is the original issue tracking the crash. The other one is more of an API topic.

@indutny you're still assigned here?

@silverwind silverwind reopened this Apr 22, 2016
@jasnell
Copy link
Member

jasnell commented Apr 22, 2016

@silverwind .. ok, no problem :-) just trying to do a bit of housecleaning.

@raimondi1337
Copy link

Ran into this issue today on node v6.9.1

I'm running this loop thousands of times one after another and it works:

    dns.setServers([server['ip']]);
    dns.lookup('something.com', fn()(...));

but this breaks after two executions resulting in the error in the original post:

    dns.setServers([server['ip']]);
    dns.resolve('something.com', fn()(...));

has this been fixed for lookup but not resolve or something like that?

@silverwind
Copy link
Contributor

@raimondi1337 lookup uses the system resolver, so does not go through c-ares. setServers has no effect on lookup.

anchnk pushed a commit to anchnk/node that referenced this issue May 19, 2017
The callback function in cares_query is synchronous and called before
closed. So dns.setServers in the synchronous callback before closed will
occur crashing.

Fixes: nodejs#894
Refs: https://github.com/nodejs/node/blob/v6.9.4/deps/cares/src/ares_process.c#L1332-L1333
Refs: https://github.com/OpenSIPS/opensips/blob/2.3.0/proxy.c
PR-URL: nodejs#13050
Reviewed-By: Anna Henningsen <[email protected]>
XadillaX added a commit to XadillaX/node that referenced this issue Jun 16, 2017
The callback function in cares_query is synchronous and called before
closed. So dns.setServers in the synchronous callback before closed will
occur crashing.

Fixes: nodejs#894
Refs: https://github.com/nodejs/node/blob/v6.9.4/deps/cares/src/ares_process.c#L1332-L1333
Refs: https://github.com/OpenSIPS/opensips/blob/2.3.0/proxy.c
PR-URL: nodejs#13050
Reviewed-By: Anna Henningsen <[email protected]>
MylesBorins pushed a commit that referenced this issue Jul 10, 2017
The callback function in cares_query is synchronous and called before
closed. So dns.setServers in the synchronous callback before closed will
occur crashing.

Fixes: #894
Refs: https://github.com/nodejs/node/blob/v6.9.4/deps/cares/src/ares_process.c#L1332-L1333
Refs: https://github.com/OpenSIPS/opensips/blob/2.3.0/proxy.c
Backport-PR-URL: #13724
PR-URL: #13050
Reviewed-By: Anna Henningsen <[email protected]>
MylesBorins pushed a commit that referenced this issue Jul 11, 2017
The callback function in cares_query is synchronous and called before
closed. So dns.setServers in the synchronous callback before closed will
occur crashing.

Fixes: #894
Refs: https://github.com/nodejs/node/blob/v6.9.4/deps/cares/src/ares_process.c#L1332-L1333
Refs: https://github.com/OpenSIPS/opensips/blob/2.3.0/proxy.c
Backport-PR-URL: #13724
PR-URL: #13050
Reviewed-By: Anna Henningsen <[email protected]>
@dzek69
Copy link

dzek69 commented Jun 16, 2018

If noone noticed - this is fixed with 9.3.0 version and fix seems to be backported to 8.10.0 too.

But I monkey patched dns module to fix that - if anyone needs to keep unpatched Node version and doesn't want the crashes - please use my fix.
More information here: https://github.com/dzek69/node-dns-bugfix

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Oct 22, 2018
Original commit message:

    Prevent changing name servers while queries are outstanding

    Changing name servers doesn't work, per c-ares/c-ares#41.
    Better to return an error code than to crash.

Refs: c-ares/c-ares#41
Refs: c-ares/c-ares#191
Refs: nodejs#894
abhishekumar-tyagi pushed a commit to abhishekumar-tyagi/node that referenced this issue May 5, 2024
The callback function in cares_query is synchronous and called before
closed. So dns.setServers in the synchronous callback before closed will
occur crashing.

Fixes: nodejs/node#894
Refs: https://github.com/nodejs/node/blob/v6.9.4/deps/cares/src/ares_process.c#L1332-L1333
Refs: https://github.com/OpenSIPS/opensips/blob/2.3.0/proxy.c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs. dns Issues and PRs related to the dns subsystem.
Projects
None yet
Development

No branches or pull requests