View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002570unrealircdpublic2005-06-24 18:062006-01-06 16:21
ReporterMonk Assigned Tosyzop  
PrioritynormalSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
Platformi386OSDebian SargeOS Version3.1
Product Version3.2.3 
Fixed in Version3.2.4 
Summary0002570: spamfilter viruschan action incompatible with user target
Descriptionhttp://www.phpmemx.net/~unrealir/forums/viewtopic.php?t=2114

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.

Regards,

Monk
TagsNo tags attached.
3rd party modules

Activities

syzop

2005-06-25 17:30

administrator   ~0010123

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

Monk

2005-06-25 20:00

reporter   ~0010125

Last edited: 2005-06-25 20:02

 Yes, we have quite some user filters with virus chan action.

This is the spamfilter block from the config:

    spamfilter {
        virus-help-channel "#spam-prison";
        virus-help-channel-deny yes;
        except "#AntiSpam,#MindForge";
            };

syzop

2005-06-26 16:15

administrator   ~0010141

Last edited: 2005-06-26 16:19

 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.

syzop

2005-08-19 12:29

administrator   ~0010359

Last edited: 2005-08-19 12:29

 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.

codemastr

2005-08-19 14:18

reporter   ~0010363

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?

syzop

2005-08-19 14:25

administrator   ~0010366

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

syzop

2005-08-19 14:30

administrator   ~0010367

Last edited: 2005-08-19 14:31

 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

syzop

2005-12-24 14:30

administrator   ~0010891

I've put this on the todo-for-3.2.4-list. Would be nice to have this fixed.

aquanight

2005-12-28 13:01

reporter   ~0010904

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?

syzop

2006-01-06 16:21

administrator   ~0010928

Should be fixed in CVS [.405].

Issue History

Date Modified Username Field Change
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
2005-08-19 14:18 codemastr 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