Client Crash When Whois From Another Client Connected To ZNC
See original GitHub issueRan into this crash when I ran a /whois <nick>
in Hexchat that is also connected to the same ZNC instance as TheLounge. It spat out this when it crashed:
Feb 18 15:02:25 <removed> lounge[75171]: /usr/lib/node_modules/thelounge/node_modules/irc-framework/src/commands/handlers/user.js:89
Feb 18 15:02:25 <removed> lounge[75171]: cache.nick = nick;
Feb 18 15:02:25 <removed> lounge[75171]: ^
Feb 18 15:02:25 <removed> lounge[75171]: ReferenceError: nick is not defined
Feb 18 15:02:25 <removed> lounge[75171]: at IrcCommandHandler.RPL_ENDOFWHOIS (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/commands/handlers/user.js:89:26)
Feb 18 15:02:25 <removed> lounge[75171]: at IrcCommandHandler.executeCommand (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/commands/handler.js:62:37)
Feb 18 15:02:25 <removed> lounge[75171]: at IrcCommandHandler.dispatch (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/commands/handler.js:49:14)
Feb 18 15:02:25 <removed> lounge[75171]: at /usr/lib/node_modules/thelounge/node_modules/irc-framework/src/client.js:103:36
Feb 18 15:02:25 <removed> lounge[75171]: at next (/usr/lib/node_modules/thelounge/node_modules/middleware-handler/index.js:42:18)
Feb 18 15:02:25 <removed> lounge[75171]: at MiddlewareHandler.handle (/usr/lib/node_modules/thelounge/node_modules/middleware-handler/index.js:64:3)
Feb 18 15:02:25 <removed> lounge[75171]: at Connection.<anonymous> (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/client.js:97:31)
Feb 18 15:02:25 <removed> lounge[75171]: at Connection.emit (/usr/lib/node_modules/thelounge/node_modules/eventemitter3/index.js:130:35)
Feb 18 15:02:25 <removed> lounge[75171]: at Connection.processReadBuffer (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/connection.js:265:14)
Feb 18 15:02:25 <removed> lounge[75171]: at Connection.socketLine (/usr/lib/node_modules/thelounge/node_modules/irc-framework/src/connection.js:99:14)
Feb 18 15:02:25 <removed> systemd[1]: thelounge.service: Main process exited, code=exited, status=1/FAILURE
Feb 18 15:02:25 <removed> systemd[1]: thelounge.service: Unit entered failed state.
Feb 18 15:02:25 <removed> systemd[1]: thelounge.service: Failed with result 'exit-code'.
I can reproduce the crash every single time.
Issue Analytics
- State:
- Created 7 years ago
- Comments:12 (8 by maintainers)
Top Results From Across the Web
FAQ - ZNC
There needs to be one connection between the client and the ZNC if you wish to connect to multiple networks at the same...
Read more >2.2.2 Milestone · GitHub
Client Crash When Whois From Another Client Connected To ZNC Type: Bug Issues that report and PRs that solve any defects that cause...
Read more >Bug listing with status RESOLVED with resolution FIXED as at ...
... Bug:2228 - "Nautilus build on Gentoo/PPC fails with error relating to Mozilla ... Bug:2840 - "yafc-0.7.8.ebuild, Yet Another Ftp Client" status:RESOLVED ...
Read more >HexChat Documentation - Read the Docs
This is intended to be used as a reply, something that will not cause the other client to send any acknowledgement back. When...
Read more >IRC Client Extra-Ordinaire - IceChat
Fix bug with certain SSL Servers not connecting * Menu Styles are now saved. Build 9.18 Sept 23 2017 ... Do not perform...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Re-opening until we bump
irc-framework
to version 2.6.1.@xPaw, I believe
irc-framework
2.6.0 did not fix this actually, as you can see your fix in the 2.6.1 diff: https://github.com/kiwiirc/irc-framework/compare/v2.6.0...v2.6.1.Problem is, at this time 2.6.0 is still the latest version of the npm package so that’s why Greenkeeper did not warn us of an update. I’m wondering if @prawnsalad didn’t forget to publish to npm after pushing the tag.