View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002570||unreal||ircd||public||2005-06-24 18:06||2006-01-06 16:21|
|Platform||i386||OS||Debian Sarge||OS Version||3.1|
|Fixed in Version||3.2.4|
|Summary||0002570: spamfilter viruschan action incompatible with user target|
TigerKatziTatzi already posted this issue in the mentioned forum thread. Now we have a core dump from his box (Suse 9.0)
[useful backtrace info snipped by Syzop -- no longer needed / now public]
And also my box (Debian 3.1) crashed with what we believe to be the same error. Because of my efforts to track the DNS crash (http://bugs.unrealircd.org/view.php?id=2499) I had the ircd running under valgrind with the parameters you mentioned, so I hope it helps to catch the problem. Find the file attached to this post.
|Tags||No tags attached.|
|3rd party modules|
(received the backtrace)
It seems the crash happens because a user is set +x but the virtual host is NULL.
If I look correctly, it seems you have a spamfilter 'user' filter with action 'viruschan'... I think this is causing the problem.
I'll see if I can research some more / verify that.
Yes, we have quite some user filters with virus chan action.
This is the spamfilter block from the config:
I see.. well unfortunately, it's not going to be an easy fix (not at all, not at all...). I'm not even sure if I'll be able to fix this cleanly.
reason: we (naturally) check for spamfilter user targets before the user is fully connected, this is useful for *line/kill/etc... The only exception is this viruschan thing, but this cannot be executed properly since the user was not actually fully connected yet.
The only way I can see to solve this is:
a) remove the 'viruschan' action for the 'user' target
b) move the checking to after the user got connected -- not an option for me, way too noisy
c) do the spamfiltering twice -- not an option: speed
d) save the "match" and execute it again later -- this is a real mess, it's not just 1 thing that needs to be saved, but multiple.
So... hm.. I'll have to think about that -- to see if solution 'd' can be implemented with minimal code mess.
Until then, I suggest not to use 'viruschan' in combination with the user target.
I've (temporary) disabled target 'u' in combination with 'viruschan' for now (better to prevent crashes than to keep it extremely buggy). Until a real solution is though of...
It's not impossible or anything, just hard to do without a mess ;).
EDIT: forgot to mention, it is disabled now as-of CVS .369.
|Why do we need to save multiple pieces of information? Don't we just need to record the fact that the user must be sent to the virus chan? Like, wouldn't FLAG_SENDTOVIRUSCHAN be enough?|
We also notice the reason & sig that matched to the viruschan ops, so would have to save that too (so basically, it comes down to a pointer to a TKL/spamfilter item).
relevant code part:
ircsprintf(chbuf, "@%s", chptr->chname); ircsprintf(buf, "[Spamfilter] %s matched filter '%s' [%s%s] [%s]", sptr->name, tk->reason, spamfilter_inttostring_long(type), targetbuf, unreal_decodespace(tk->ptr.spamf->tkl_reason)); sendto_channelprefix_butone_tok(NULL, &me, chptr, PREFIX_OP|PREFIX_ADMIN|PREFIX_OWNER, MSG_NOTICE, TOK_NOTICE, chbuf, buf, 0);
I suppose we could either set some static variable, which is ugly... or change (or add) a routine that accepts a aTKline **tk, which seems better...
but keep the dospamfilter() function (from the outside) with the same syntax.
(dospamfilter --> dospamfilter_ex, and then dospamfilter as a wrapper to dospamfilter_ex).
Something like that?
EDIT: but then a bit more "thought-trough" than what I'm typing here in 2 minutes ;p
||I've put this on the todo-for-3.2.4-list. Would be nice to have this fixed.|
||Couldn't you send the notice when the match is found (iow: still during the login stuff) and then just set the flag, and then after motd,etc dump, if flagged skip set::autojoin and send them to viruschan?|
||Should be fixed in CVS [.405].|
|2005-06-24 18:06||Monk||New Issue|
|2005-06-24 18:07||Monk||File Added: valgrindlog.tar.gz|
|2005-06-24 18:23||syzop||View Status||public => private|
|2005-06-25 17:30||syzop||Note Added: 0010123|
|2005-06-25 20:00||Monk||Note Added: 0010125|
|2005-06-25 20:02||Monk||Note Edited: 0010125|
|2005-06-26 16:15||syzop||Note Added: 0010141|
|2005-06-26 16:17||syzop||Status||new => confirmed|
|2005-06-26 16:19||syzop||Note Edited: 0010141|
|2005-08-19 12:29||syzop||Note Added: 0010359|
|2005-08-19 12:29||syzop||Note Edited: 0010359|
||Note Added: 0010363|
|2005-08-19 14:25||syzop||Note Added: 0010366|
|2005-08-19 14:30||syzop||Note Added: 0010367|
|2005-08-19 14:31||syzop||Note Edited: 0010367|
|2005-12-24 14:25||syzop||File Deleted: valgrindlog.tar.gz|
|2005-12-24 14:29||syzop||Reproducibility||random => sometimes|
|2005-12-24 14:29||syzop||View Status||private => public|
|2005-12-24 14:29||syzop||Description Updated|
|2005-12-24 14:29||syzop||Summary||Crash, maybe related to spam filter => spamfilter viruschan action incompatible with user target|
|2005-12-24 14:30||syzop||Note Added: 0010891|
|2005-12-28 13:01||aquanight||Note Added: 0010904|
|2006-01-02 16:01||syzop||Status||confirmed => assigned|
|2006-01-02 16:01||syzop||Assigned To||=> syzop|
|2006-01-06 16:21||syzop||Status||assigned => resolved|
|2006-01-06 16:21||syzop||Fixed in Version||=> 3.2.4|
|2006-01-06 16:21||syzop||Resolution||open => fixed|
|2006-01-06 16:21||syzop||Note Added: 0010928|