http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4179
------- Additional Comments From [EMAIL PROTECTED] 2007-12-05 02:04 ------- (In reply to comment #10) > the fix is slightly suboptimal; instead of just recompiling the methods to > *remove* the user rule code on the next scan after the rule-defining user's > scan, all future scans with that spamd child will also recompile those methods > too. But it works! ok, I had a thought about how to fix this last night, and it's now implemented as: : jm 210...; svn commit -m "bug 4179: only recompile once after user rules go 'out of scope'" Sending lib/Mail/SpamAssassin/Conf/Parser.pm Sending lib/Mail/SpamAssassin/Conf.pm Sending lib/Mail/SpamAssassin/Plugin/Check.pm Sending t/spamd_user_rules_leak.t Transmitting file data .... Committed revision 601283. Here's how it works: the want_rebuild_for_type 'flag' is actually a counter; it is decremented after each scan. This ensures that we always recompile at least once more; once to *define* the rule, and once afterwards to *undefine* the rule in the compiled ruleset again. If two consecutive scans use user rules, that's ok -- the second one will reset the counter, and we'll still recompile just once afterwards to undefine the rule again. (I renamed 'user_rules_to_compile' to the clearer 'want_rebuild_for_type', as you can see) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
