http://bugzilla.spamassassin.org/show_bug.cgi?id=3839
------- Additional Comments From [EMAIL PROTECTED] 2004-10-02 12:14 ------- Created an attachment (id=2409) --> (http://bugzilla.spamassassin.org/attachment.cgi?id=2409&action=view) "sharetest" script 'What you don't know from that diff is whether that refcnt changed during the rule processing by being incremented on reference and decremented after the reference. So while you only see changes on some rules, and there is doubtless a way to make those changes not happen, you *don't* know that you aren't doing an inc/dec mod on each rule touched. To figure that out you practically have to figure out how to get one of those dumps in the middle of processing a rule.' Actually, here's a test script that appears to show that this is *not* the case. It emulates the data structures used in Conf, and the each() loops used in PerMsgStatus, and dumps continually throughout -- including in the middle of the each() iteration loop. The REFCNTs do not change, even when iterating. So that's not the problem, after all. It does demonstrate the bug, however: top -b -n1 | grep sharetest PID USER PR NI CODE VIRT RES SHR nDRT %CPU %MEM TIME COMMAND 11784 jm 25 0 1032 37148 31m 2620 0 86.6 3.6 0:02 sharetest 11769 jm 25 0 1032 37148 31m 2620 0 0.0 3.6 0:04 sharetest Interestingly, however, I notice something unusual -- those VIRT/RES/SHR figures *never change* even when there's only *one* process there. I'm starting to think that "top" is reporting the wrong thing -- namely, that the "SHR" figure refers only to pages of code loaded from shared libraries, and that the "RES" figure basically includes all the resident allocated memory, even if that memory is shared behind the scenes. If this is the case, this "bug" is a non-issue after all. Anyway, take a look at the script if you're curious... --j. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
