View Issue Details

IDProjectCategoryView StatusLast Update
0002683unrealircdpublic2015-05-27 18:17
Reporterbrain4 Assigned Tosyzop  
Status resolvedResolutionfixed 
Platformi386OSFreeBSD, LinuxOS VersionAny
Product Version3.2.3 
Fixed in Version3.2.5 
Summary0002683: Multiple notify fails to trigger watch events
DescriptionIf 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 Informationthis 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.
TagsNo tags attached.
3rd party modules



2005-11-10 10:48

administrator   ~0010685

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 :).


2005-11-11 03:29

reporter   ~0010701

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.


2005-11-11 11:14

administrator   ~0010709

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).


2005-11-12 01:14

reporter   ~0010713

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.


2005-11-15 08:53

reporter   ~0010746

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.


2005-11-15 10:58

reporter   ~0010747

Last edited: 2005-11-15 10:59

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 (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 which i believe is 3.2.3 but with less frequency than on 3.2.2b.


2005-11-16 22:57

reporter   ~0010759

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...


2005-11-17 10:00

administrator   ~0010762

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%?)


2005-11-17 10:09

reporter   ~0010765

Last edited: 2005-11-17 10:12

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.


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?


2015-05-27 18:17

administrator   ~0018355

can't reproduce, tried both local & remote server. must have been fixed then.

Issue History

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 stskeeps Status new => assigned
2005-11-11 02:55 stskeeps Assigned To => codemastr
2005-11-11 02:56 stskeeps Assigned To codemastr => stskeeps
2005-11-11 02:56 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