You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2008/03/20 17:23:35 UTC
[Bug 5858] New: Memory leaks with complex/deep mime messages
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
Summary: Memory leaks with complex/deep mime messages
Product: Spamassassin
Version: 3.2.3
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: spamassassin
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jgouveia@gmail.com
I've noticed that on some messages spamassassin (or related modules) doesn't
free up used memory.
This can be a problem if children are setup to accept a given number of
connections.
I'm attaching 2 files:
- sa.pl (the script I used to test this)
- bork (the problematic message)
Test results follow (watch rss column) against two messages:
-rw-r--r-- 1 jgouveia jgouveia 166968 2008-03-20 16:04 bork
-rw-r--r-- 1 jgouveia jgouveia 155216 2008-03-20 16:04 normal
With the normal message all goes well:
jgouveia@Matrix:~/sat$ perl sa.pl normal &
[1] 10464
jgouveia@Matrix:~/sat$ while true ; do ps -o pid,rss | grep 10464 ; sleep 5 ;
done
10464 35564
10464 35564
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35752
10464 35756
10464 35756
10464 35756
10464 35756
10464 35756
10464 35756
With the "bork" message, not so well:
jgouveia@Matrix:~/sat$ perl sa.pl bork &
[1] 10547
jgouveia@Matrix:~/sat$ while true ; do ps -o pid,rss | grep 10547; sleep 5 ;
done
10547 39596
10547 44064
10547 48372
10547 51524
10547 56020
10547 60360
10547 63524
10547 68028
10547 70824
10547 74104
10547 78216
10547 81336
10547 85604
10547 88724
10547 92992
10547 96112
10547 99236
10547 103516
10547 106644
10547 111088
10547 115372
10547 118496
10547 122940
10547 126212
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
Justin Mason <jm...@jmason.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Group| |security
Component|spamassassin |Security
Target Milestone|Undefined |3.2.5
--- Comment #6 from Justin Mason <jm...@jmason.org> 2008-03-20 13:01:44 PST ---
ah! sorry, I didn't realise it was leaking like that. that's more serious
alright.
marking this as a security bug, since IMO it sounds serious enough to warrant
it....
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #4 from Joao Gouveia <jg...@gmail.com> 2008-03-20 10:46:08 PST ---
(In reply to comment #3)
> hi --
>
> I think you've run into a problem with perl itself; as far as I know, whether
> or not the perl interpreter returns freed memory to the OS, is up to the
> malloc() library in use. In my experience on Linux, it never returns this
> memory (or at least never returns in a way visible to "ps" or "top").
I am aware of that, but this doesn't explain the huge diference from a "normal"
message to the sample i've attached.
> We get around this in spamd (and our mass-check script) by using child
> processes to do the check() operations, which exit after scanning several
> hundred messages. this way the "spare" memory usage is cleaned up when each
> child exits.
That's how things work here also. A pool of preforked children do the work and
die after N checks, where N is tipically set to 1000.
This has been worked fine so far, but yesterday that "problematic" messages
came in and processes started to grow allot more fat that they're supposed to.
This eventually caused OOM to trigger (10 workeds, each one with > 600Mb RSS
eventually made the box stall)
> There's a possibility btw that the "spare" memory usage is more or less
> harmless -- in that it is unused by the process after it is freed by perl, and
> therefore paged out once there's any swap pressure. but it's certainly not
> good to have.
>
That's not what I'm seeing here.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #3 from Justin Mason <jm...@jmason.org> 2008-03-20 10:33:52 PST ---
hi --
I think you've run into a problem with perl itself; as far as I know, whether
or not the perl interpreter returns freed memory to the OS, is up to the
malloc() library in use. In my experience on Linux, it never returns this
memory (or at least never returns in a way visible to "ps" or "top").
We get around this in spamd (and our mass-check script) by using child
processes to do the check() operations, which exit after scanning several
hundred messages. this way the "spare" memory usage is cleaned up when each
child exits.
There's a possibility btw that the "spare" memory usage is more or less
harmless -- in that it is unused by the process after it is freed by perl, and
therefore paged out once there's any swap pressure. but it's certainly not
good to have.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #2 from Joao Gouveia <jg...@gmail.com> 2008-03-20 09:24:52 PST ---
Created an attachment (id=4276)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4276)
Test script
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #5 from Joao Gouveia <jg...@gmail.com> 2008-03-20 11:14:02 PST ---
Running the same script for 200 iterations (default of spamd). Value on the
right shows current RSS:
jgouveia@Matrix:~/sat$ perl sa.pl bork
Done.. 1 (37684)
Done.. 2 (39636)
Done.. 3 (41108)
Done.. 4 (42600)
Done.. 5 (44096)
Done.. 6 (45568)
Done.. 7 (47048)
Done.. 8 (48520)
Done.. 9 (49988)
Done.. 10 (51468)
(..)
Done.. 194 (324340)
Done.. 195 (325980)
Done.. 196 (327468)
Done.. 197 (328960)
Done.. 198 (330440)
Done.. 199 (331924)
Done.. 200 (333404)
Would this be considered "normal"?
This message has ~170k. I'm guessing this would be even worst for a 250Kb
messages (the max recommended size)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5858] Memory leaks with complex/deep mime messages
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #1 from Joao Gouveia <jg...@gmail.com> 2008-03-20 09:24:18 PST ---
Created an attachment (id=4275)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4275)
Problematic message
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.