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

This fixes the IPv6-Issue #90 for me. #91

Merged
merged 2 commits into from
Jun 28, 2012

Conversation

ccoenen
Copy link
Contributor

@ccoenen ccoenen commented Jun 12, 2012

I am not sure if it breaks anything, though. My hubot still works fine.

…breaks anything, though. My hubot still works fine.
@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 12, 2012

Nope it's not stable. For some reason, my hubot just crashed with this stacktrace. :-(

TypeError: Cannot read property 'users' of undefined
  at Client.<anonymous> (/srv/hubot-repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:330:35)
  at Client.emit (events.js:67:17)
  at /srv/hubot-repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:517:22
  at Array.forEach (native)
  at Socket.<anonymous> (/srv/hubot-repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:514:15)
  at Socket.emit (events.js:67:17)
  at TCP.onread (net.js:362:31)

@martynsmith
Copy link
Owner

Do you know of a public IRC server I can connect to to try this out ?

@martynsmith
Copy link
Owner

Better still, since I don't easily have any client capable of ipv6 at the moment, if you could collect some raw data and paste it here, that'd be really handy :-)

If you put something like:

console.log('parseMessage(', line, ')');

At the start of the parseMessage function, and then just pasted some of the raw output from whois queries, I think I could poke around and see what needs fixing.

Thanks,

@martynsmith
Copy link
Owner

With all the experimentation I've done, it seems that your patch works fine.

Are you sure the hubot stacktrace you got wasn't related to some other issue?

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 14, 2012

I'm collecting a few instances. So far, it has crashed on me twice. I haven't yet looked into it (so far it works fair enough for a proof-of-concept).

i'll post the incoming lines as soon as i can get to it. Thanks for the support so far!

@martynsmith
Copy link
Owner

No problems.

I might hold off merging your pull request until you've collected a bit more information.

Let me know how things go.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 14, 2012

Here's the output of one whois-attempt. I just replaced the actual domain with "domain"

parseMessage( :domain 311 hubert cc amenthes 0::ffff:192.168.1.104 * :purple )
parseMessage( :domain 319 hubert cc :#debug  )
parseMessage( :domain 312 hubert cc domain :Inspircd )
parseMessage( :domain 320 hubert cc :is using a secure connection )
parseMessage( :domain 317 hubert cc 1 1339659779 :seconds idle, signon time )
parseMessage( :domain 318 hubert cc :End of /WHOIS list. )

i'll keep the console.log in place for the next few days. If it continues to crash, i'll let you know.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

well... i started recording all my network traffic and wrote extensive logfiles. But over the past week the node-irc hasn't crashed once! It was possibly just some random coincidence.

I'll keep the logs/recordings in place for a few weeks (just in case).

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

Awesome. Just as i was writing the last comment, i realize that hubot is no longer in the channel :-/

Stacktrace:

repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:520
                    throw err;
                          ^
TypeError: Cannot read property 'users' of undefined
    at Client.<anonymous> (repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:330:35)
    at Client.emit (events.js:67:17)
    at repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:517:22
    at Array.forEach (native)
    at Socket.<anonymous> (repo/node_modules/hubot-irc/node_modules/irc/lib/irc.js:514:15)
    at Socket.emit (events.js:67:17)
    at TCP.onread (net.js:362:31)

Last parseMessages:

parseMessage( PING :i.irc.meso.net )
parseMessage( PING :i.irc.meso.net )
parseMessage( :tb!tobl@0::ffff:192.168.1.69 PART #debug )

I can now safely reproduce the bug by just typing /part into my IRC-Client. I also tested the same thing before my patch and it does not crash without my modification.

In essence this means: Hold off merging a little longer. I'll look into it.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

Okay, i traced it back to https://github.com/martynsmith/node-irc/blob/v0.3.3/lib/irc.js#L329 - here the chanData() call will return undefined, which is why the subsequent delete will fail.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

aaaah: the this.chans object in https://github.com/martynsmith/node-irc/blob/v0.3.3/lib/irc.js#L441 looks like this in my test:

{
  ":#debug":{
    "key": ":#debug",
    "serverName": ":#debug",
    "users": {},
    "mode": ""
  }
}

note the leading colon of the key and servername fields. I guess my patch is really not ready for primetime, yet.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

The error appears to be when the bot is joining. The line in question:

:Hubot!nodebot@0::ffff:192.168.1.104 JOIN :#debug

parses to

{
  "prefix": "Hubot!nodebot@0::ffff:192.168.1.104",
  "nick": "Hubot",
  "user": "nodebot",
  "host": "0::ffff:192.168.1.104",
  "command": "JOIN",
  "rawCommand": "JOIN",
  "commandType": "normal",
  "args": [
    ":#debug"
  ]
}

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

(thinking aloud ahead, you may skip over large parts of this :-D)

In https://github.com/martynsmith/node-irc/blob/v0.3.3/lib/irc.js#L735 the rest of the aforementioned line will be

":#debug"

by then, the so-far-parsed message will be

{
  "prefix": "Hubot!nodebot@0::ffff:192.168.1.104",
  "nick": "Hubot",
  "user": "nodebot",
  "host": "0::ffff:192.168.1.104",
  "command": "JOIN",
  "rawCommand": "JOIN",
  "commandType": "normal",
  "args": []
}

It might be fixed by changing the replace statement in https://github.com/martynsmith/node-irc/blob/v0.3.3/lib/irc.js#L724 to insert one singular whitespace instead of empty string:

    line = line.replace(/^[^ ]+ +/, ' ');

But then the channel won't get created in the first place (i.e. it never gets to line https://github.com/martynsmith/node-irc/blob/v0.3.3/lib/irc.js#L305 ), because the self.nick was not set (it is an empty string in my case. It is correctly set in the connect-listener, but then overwritten in the listener for 'raw' in case 001. The line that causes it is this:

:domain.name.net 001 Hubot :Welcome to the IRC Network Hubot!nodebot@0::ffff:192.168.1.104

which parses to

{
  prefix: 'domain.name.net',
  server: 'domain.name.net',
  command: '001',
  rawCommand: '001',
  commandType: 'normal',
  args: [
   '',
   'Hubot',
   'Welcome to the IRC Network Hubot!nodebot@0::ffff:192.168.1.104'
  ]
}

the leading empty string in args comes from the message.args = middle.split(/ +/);, which in turn parses rubbish because of the empty space in front i introduced with the altered line.replace earlier.

Long story short: i'll need to come up with a better patch.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 20, 2012

i came up with a solution that uses a regex instead of the indexOf. It survives the /part that killed the previous approach, but also works with all the collected lines i discussed here and in #90.

@ccoenen
Copy link
Contributor Author

ccoenen commented Jun 28, 2012

I've been running this version since my last commit. Since it didn't crash or cause any problems, i think it might be worth merging.

martynsmith added a commit that referenced this pull request Jun 28, 2012
This fixes the IPv6-Issue #90 for me.
@martynsmith martynsmith merged commit c60b696 into martynsmith:master Jun 28, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants