-
dvdhrm's right. There should probably be some limit that floats slightly above the number of channels that the operator is currently in.
2009-10-11 16:38:19 UTC by entrope
-
The epoll function engine_set_events() generates an ET_ERROR event on the socket if the epoll_ctl() function call fails. If the socket belongs to a user, this will result in a call to exit_client(). This, however, will send data over the socket, thus indirectly calling send_buffer() which itself again indirectly uses engine_set_events() and hence will produce a stack-overflow due to an endless...
2009-10-07 20:50:39 UTC by dvdhrm
-
This would be a serious memory leak in the daemon. A user could simply invite the oper to thousands of channels and the invites won't get deleted. However, you may set an hard-limit to something higher than MAXCHANNELSPERUSER.
2009-09-21 10:07:06 UTC by dvdhrm
-
and add && !IsChannelService(cptr) too, in fact, you should excempt anything that is not bound to the maxchan limit.
2009-09-20 11:28:40 UTC by key2peace
-
Make that:
if ((int)(cli_user(cptr))->invites >=
feature_int(FEAT_MAXCHANNELSPERUSER) && !is_oper(cptr) && !IsChannelService(cptr))
Channelservices also should not have a limit :)
2009-09-20 11:23:27 UTC by key2peace
-
During checking the autoinvite feature an ircop/csc member pointed out that certain invites where missing, trying to track down the issue I found the following in the current svn code that might be the reason:
78 if ((int)(cli_user(cptr))->invites >= feature_int(FEAT_MAXCHANNELSPERUSER))
79 del_invite(cptr, (cli_user(cptr))->invited->value.chptr);
Since ircops are not bound to...
2009-09-20 11:18:00 UTC by key2peace
-
I, myself, would rather they stay as notices. There's already enough numeric pollution as it is. And, the second message pertains more to the user, than the server itself. Using your example:
*Helsinki.FI.EU.Undernet.org* on 1 ca 1(4) ft 10(10)
This notice is basically informing you that there is one client (you) on the network with your IP address, and that this essentially your first...
2009-09-12 09:48:28 UTC by brdbell
-
I'm bringing up a new IRC client. In the interest of creating a pleasant user experience for non-technical users, I'm doing my best to provide complete graphical UI, with as little as possible of the kind of raw and generally intimidaing messages that most IRCd's spew out on connection (yes, the MOTD gets displayed, if its changed, and yes all the server stats are tucked away in an information...
2009-09-08 05:54:09 UTC by nobody
-
Sorry, I was not logged in.
I also wanted to add, that the other IO engines like kqueue and epoll do not have this assertion so I think the assertion has to be removed and the auth_sock_callback is "right".
2009-09-06 14:27:06 UTC by dvdhrm
-
My code is the u2.10.12 branch and I use the select() IO engine (only for testing purposes) and the assertion placed in line 406:
assert(s_fd(sock) == i);
should not be there since at least the "auth_sock_callback" function sets the s_fd() field to -1 when the ident-query fails.
David Herrmann.
2009-09-06 14:24:17 UTC by nobody
