View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002683||unreal||ircd||public||2005-11-10 03:52||2015-05-27 18:17|
|Platform||i386||OS||FreeBSD, Linux||OS Version||Any|
|Fixed in Version||3.2.5|
|Summary||0002683: Multiple notify fails to trigger watch events|
|Description||If two nicks are placed on the watchlist, and a user changes from one of these nicks to another which is ALSO on the watchlist, one of the WATCH events (signon for the second nick) is lost.|
Instead of getting:
NICKA is offline
NICKB is online
you will just get:
NICKA is offline
|Steps To Reproduce||(in any client, tested with irssi, mirc, xchat):|
user two then signs on as nickone, then does /nick nicktwo
User one will see:
- nickone is online
- nickone is offline
(and no mention of nicktwo)
|Additional Information||this is not a client issue as i have tested this with every client i happen to have a copy of. It does seem somewhat random, sometimes the online event WILL trigger on nickchange, but the majority of the time it will not.|
|Tags||No tags attached.|
|3rd party modules|
That sounds like a bug indeed.
[quote] It does seem somewhat random, sometimes the online event WILL trigger on nickchange, but the majority of the time it will not.[/quote]
*nod* I just tested it indeed and got exactly that, so good you mention it ;)
Perhaps it's related to remote nicks or something? Don't know, I only had time for a quick check right now, will research this later further.
If you spot a pattern though, let me know :).
I had a brief session in telnet with stskeeps today, couldn't spot anything conclusive - but as I'm at my normal netcafe, couldn't check comfortably :).
I'll have a play tonight or something, in case syzop doesn't have time/I get any more info.
Sure, take a look if you want.
At least a simple nickchange local or on a remote server (only tested 1 hop away) does not trigger this bug.
Even if you can only find a reproducable case, just let me know.
Otherwise, in case you take source aproach (in that case, if you found something, be sure to check if it is indeed causing a problem by simply testing it, don't blindly assume it ;p), pay attention to calls to hash_check_watch.
On a side note, I just committed this:
- Removed useless (unused) WATCH code that was still present in the core.
there was some old m_watch/show_watch code present in the core, this code was completely unused however (forgot to remove it in the core when the watch stuff got moved to src/modules/m_watch.c).
I had a bit of a run through last night, with a 2 server testnet (and 1 server) - was unable to reproduce this.
I'll have another go with my full 20 server testnet (it's rare when I can be bothered starting them all up :P) and see what happens.
sorry, im unable to reproduce this,
ive been watching with my debug window open, ive tryed local server, 1 hop 2 hops, and 4 hops apart, and i got both the log off and the log on.
Could this be related to the number of users on the network/local server, and therefore the number of entries in the nick hash? Its often duplicatable over on irc.chatspike.net (3.2.2b hotfix), at least for me.
We have ~1100 users currently,and i have to say until recently (since 3.2.1) the issue hasnt reared its head at all. Its a pretty recent issue.
I was also able to duplicate it on irc.deepspace.org which i believe is 3.2.3 but with less frequency than on 3.2.2b.
Looking over our hash stuff, we use (exactly) the same as bahamut 1.8.3 (I've no idea if that's the most recent, it was when I downloaded it a few months back now). (Oh, and except we use unsigned int some places where they use int, doubt that could have any effect though?)
So, I somehow doubt that it's hashing problems...
I tried both on chatspike and deepspace, and could not reproduce it.
This is what I do:
- connect usera to server A
- connect userb to server B
- note: there is no userc online at this time
- usera: WATCH +userb +userc
- userb: NICK userc
And I get all the normal (expected) stuff
Also when userb & userc where on watch, I reconnected userb, still all good.
Tried it a few more times too.
How often do you get it? (33%? 10%? 5%?)
A couple of weeks ago, i was getting this almost 100% of the time, recently i get it much less -- during this time, we havent added or removed any modules or upgraded/downgraded our system, or introduced anything else nonstandard onto our network.
*** ON A RELATED NOTE ***
I'd like to point out that next to no clients actually send watch in the form:
WATCH +n1 +n2
They all seem to send WATCH to unreal with something like:
WATCH C nick1 nick2 N
or something of that nature, mIRC does this, xchat does this and i think irssi does. Dont know why they do it, but could this be part of the problem? Is unreal identifying its WATCH incorrectly?
||can't reproduce, tried both local & remote server. must have been fixed then.|
|2005-11-10 03:52||brain4||New Issue|
|2005-11-10 10:48||syzop||Note Added: 0010685|
||Status||new => assigned|
||Assigned To||=> codemastr|
||Assigned To||codemastr => stskeeps|
||Assigned To||stskeeps =>|
|2005-11-11 03:29||w00t||Note Added: 0010701|
|2005-11-11 11:14||syzop||Note Added: 0010709|
|2005-11-12 01:14||w00t||Note Added: 0010713|
|2005-11-15 08:53||White_Magic||Note Added: 0010746|
|2005-11-15 10:58||brain4||Note Added: 0010747|
|2005-11-15 10:59||brain4||Note Edited: 0010747|
|2005-11-16 22:57||w00t||Note Added: 0010759|
|2005-11-17 10:00||syzop||Note Added: 0010762|
|2005-11-17 10:09||brain4||Note Added: 0010765|
|2005-11-17 10:12||brain4||Note Edited: 0010765|
|2015-05-27 18:17||syzop||Note Added: 0018355|
|2015-05-27 18:17||syzop||Status||assigned => resolved|
|2015-05-27 18:17||syzop||Fixed in Version||=> 3.2.5|
|2015-05-27 18:17||syzop||Resolution||open => fixed|
|2015-05-27 18:17||syzop||Assigned To||=> syzop|