http://bugzilla.spamassassin.org/show_bug.cgi?id=3776
------- Additional Comments From [EMAIL PROTECTED] 2004-10-13 14:25 ------- > hash keys are always converted to strings anyway I expected that my Lisp instincts for optimization would not work here :-) Well, does all the memory allocated in create_lm for its my %ngram and all the strings used for most of its keys get freed when create_lm returns just the array of the top 400 keys? Actually, as I think about it, I don't see how the problem of this bug report happens even if the memory is not freed at the end of create_lm. Create_lm is only called once, in the child process, so even if it leaked memory, wouldn't that be freed when the child finished processing the message? The hash table in the example is only growing to around 250,000 entries with keys 1 to 5 bytes long, and with integer values. The message body is less than 250,000 characters. How does that translate into a spamd child blowing up past a 75Mb memory image? It's great that empirically we see limiting the size of the message body passed to create_lm fixes the problem, but I'm worried that there is still a memory leak that we have just pushed down below our annoyance threshold without really fixing it. Can you explain how the current code creates the problem that we see? Sorry for pushing this, but I don't want to leave a problem of memory blowup to a fix that seems to work for one possible cause without a full understanding of how it all is working. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
