Skip to content

Debugging without a network connection caused an exception #726

Description

@GerhardRi

Without a network connection, no network adapters are installed, trying to debug caused an exception on my Win8.1 computer.

Steps to reproduce (io.js Versions 1.0.4 and 1.1.0):

C:\gg>iojs.exe debug test.js
    < Debugger listening on port 5858
    connecting to port 5858.............There was an internal error in Node's debugger. Please report this bug.
    getaddrinfo ENOENT localhost:5858
    Error: getaddrinfo ENOENT localhost:5858
        at Object.exports._errnoException (util.js:738:11)
        at errnoException (dns.js:30:15)
        at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:75:26)

After installing a Loopback Adapter it works fine:

    C:\gg>iojs.exe debug test.js
    < Debugger listening on port 5858
    connecting to port 5858... ok
    break in C:\gg\test.js:1
    > 1 console.log(process.config); 

Activity

  1. Fishrock123 commented on Feb 5, 2015

    @Fishrock123
    Contributor

    @GerhardRi Can you post code that causes this without modules?

    Otherwise, it is likely that the debugger you are using has native bindings and does not support io.js (yet). (See this list.)

  2. lidlanca commented on Feb 5, 2015

    @lidlanca

    You can't use network stack without a network interface.

  3. GerhardRi commented on Feb 5, 2015

    @GerhardRi
    Author

    It's just a local programm no network connections at all
    This ist my Code:

    console.log(process.config);
    console.log(process.versions);
    

    I don't use an external debugger, just the build-in command line debugger

  4. lidlanca commented on Feb 5, 2015

    @lidlanca

    When a program uses networking even for local communication it requires a network interface.

    When you start the debugger it tried to bind to an interface, then wait for connections from the target.
    which can be remote or local.

    loopback interface is a virtual network interface that allow local programs communicate using a network stack.

  5. GerhardRi commented on Feb 5, 2015

    @GerhardRi
    Author

    As you can see ping the localhost and 127.0.0.1 works und doing the same with node.exe works too

    C:\gg>iojs debug test.js
    < Debugger listening on port 5858
    connecting to port 5858.............There was an internal error in Node's debugger. Please report this bug.
    getaddrinfo ENOENT localhost:5858
    Error: getaddrinfo ENOENT localhost:5858
        at Object.exports._errnoException (util.js:738:11)
        at errnoException (dns.js:30:15)
        at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:75:26)
    
    C:\gg>node debug test.js
    < debugger listening on port 5858
    connecting... ok
    break in C:\Users\Gerhard\Downloads\test.js:1
      1 console.log(process.config);
      2 console.log(process.versions);
      3
    debug>
    (^C again to quit)
    debug>
    
    C:\gg>ping localhost
    
    Ping wird ausgeführt für Laptop [::1] mit 32 Bytes Daten:
    Antwort von ::1: Zeit<1ms
    Antwort von ::1: Zeit<1ms
    Antwort von ::1: Zeit<1ms
    Antwort von ::1: Zeit<1ms
    
    Ping-Statistik für ::1:
        Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
    
    C:\gg>ping 127.0.0.1
    
    Ping wird ausgeführt für 127.0.0.1 mit 32 Bytes Daten:
    Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
    Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
    Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
    
    Ping-Statistik für 127.0.0.1:
        Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
    STRG-C
    
  6. ofrobots commented on Feb 6, 2015

    @ofrobots
    Contributor

    I suspect that the problem might be related to the fact that 'node debug' starts two processes that communicate over port 5858. If there is no loopback network interface, then this might not work.

  7. lidlanca commented on Feb 6, 2015

    @lidlanca

    ping.exe works, may be due to implementation exception when handling "localhost". When the tool recognize that the target is a localhost address it probably doesn't bother sending any icmp packets and assume success. (also see: "Martian packet")

    I wouldn't consider the ping tool as a control element in the question.
    ps if you ping from node as well it might still use ping.exe under the hood.

  8. bnoordhuis commented on Feb 6, 2015

    @bnoordhuis
    Member

    I think we should be able to avoid the DNS resolve step by connecting to 127.0.0.1 instead of localhost. Does this patch help?

    diff --git a/lib/_debugger.js b/lib/_debugger.js
    index 955080f..7881d72 100644
    --- a/lib/_debugger.js
    +++ b/lib/_debugger.js
    @@ -1620,7 +1620,7 @@ Interface.prototype.trySpawn = function(cb) {
       var self = this,
           breakpoints = this.breakpoints || [],
           port = exports.port,
    -      host = 'localhost',
    +      host = '127.0.0.1',
           childArgs = this.args;
    
       this.killChild();

    (You'll have to recompile the binary after applying the patch. Or you could hex-edit the existing binary, the strings are equally long. :-))

  9. GerhardRi commented on Feb 6, 2015

    @GerhardRi
    Author

    It works with a patched exe, i replaced all the 'localhost' with '127.0.0.1'
    Thank you all for your support

  10. cjihrig commented on Feb 6, 2015

    @cjihrig
    Contributor

    @bnoordhuis wouldn't that patch cause issues on machines that only support IPv6?

  11. bnoordhuis commented on Feb 6, 2015

    @bnoordhuis
    Member

    @cjihrig It would. But what machine supports IPv6 but not IPv4? It seems like an academic issue to me.

  12. cjihrig commented on Feb 6, 2015

    @cjihrig
    Contributor

    I agree, but similar problems have come up before. nodejs/node-v0.x-archive#7637

  13. bnoordhuis commented on Feb 6, 2015

    @bnoordhuis
    Member

    Right, I can see how only IPv6 might be externally routable. But disallowing IPv4 localhost traffic? Seems implausible, it would break a lot of existing programs.

  14. cjihrig commented on Feb 6, 2015

    @cjihrig
    Contributor

    Good point. This will never be an external connection. +1 from me then. If it does break for anyone, I'm sure they'll let us know.

  15. bnoordhuis commented on Feb 6, 2015

    @bnoordhuis
    Member

    Fixed in 9dc9ec3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions