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 |
| Reporter | brain4 | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i386 | OS | FreeBSD, Linux | OS Version | Any |
| Product Version | 3.2.3 | ||||
| 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 one: /notify nickone /notify nicktwo 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-11-10 03:52 | brain4 | New Issue | |
| 2005-11-10 10:48 | syzop | Note Added: 0010685 | |
| 2005-11-11 02:55 |
|
Status | new => assigned |
| 2005-11-11 02:55 |
|
Assigned To | => codemastr |
| 2005-11-11 02:56 |
|
Assigned To | codemastr => stskeeps |
| 2005-11-11 02:56 |
|
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 |
