| Summary: | Commands from old connection bleeding into new one after reconnect | ||
|---|---|---|---|
| Product: | [Applications] konversation | Reporter: | Jonas Thiem <contact> |
| Component: | general | Assignee: | argonel <argonel> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | argonel, hein |
| Priority: | NOR | Keywords: | triaged |
| Version: | 1.3.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | The output of a /raw window | ||
commit e4d7d56a44bb7be7eaa206e297ff7f39b94266ac Author: eli mackenzie <argonel@gmail.com> Date: Wed Sep 8 02:53:45 2010 -0400 stop the auto-who timer when the server is not connected CCBUG:249675 diff --git a/src/irc/channel.cpp b/src/irc/channel.cpp index 85b8c9d..3a53e9c 100644 --- a/src/irc/channel.cpp +++ b/src/irc/channel.cpp @@ -2689,6 +2689,7 @@ void Channel::setActive(bool active) topicLine->clear(); clearModeList(); clearBanList(); + m_whoTimer.stop(); } } commit 0a19c2109f7c8b514240d3f29fa8e2ab43a7355e Author: eli mackenzie <argonel@gmail.com> Date: Wed Sep 8 03:15:21 2010 -0400 stop the lag timer when disconnected CCBUG:249675 diff --git a/src/irc/server.cpp b/src/irc/server.cpp index 315f54b..f0a6263 100644 --- a/src/irc/server.cpp +++ b/src/irc/server.cpp @@ -651,6 +651,7 @@ void Server::broken(KTcpSocket::Error error) resetQueues(); m_notifyTimer.stop(); + m_pingSendTimer.stop(); m_pingResponseTimer.stop(); m_inputFilter.setLagMeasuring(false); m_currentLag = -1; Is this still an issue with current versions of Konversation? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |
Created attachment 51154 [details] The output of a /raw window Version: 1.3.1 (using KDE 4.4.5) OS: Linux After filling up Konvi's send queue with looots of commands to the point where the server will kick me for Excess Flood, Konversation will, after the subsequent reconnect, bleed commands from the old connection into the new one. To see what sort of commands I'm talking of, see the attached raw output. Apparently, some WHO commands and other stuff gets then sent during the authentication period, and it was probably supposed to get sent before the disconnect happened (and is now, due to a bug, still queued and sent out despite the old connection being gone). Reproducible: Sometimes Steps to Reproduce: 1. Apparently a DCC transfer seems to accelerate it for me. Maybe slowing down the connection helps 2. Sent a lot of stuff, but not just PRIVMSGs, but also lots of WHOIS commands 3. Do it so excessively that the server will kick you (if you have trouble at this point, I recommend trying on irc.eloxoph.com which has a relatively harsh flood limit) Actual Results: Reconnect often fails or yields a lot of "Not registered" errors Expected Results: Reconnect works fine and no commands that shouldn't be there are seen in the raw log during authentication