SA Bugzilla – Bug 3317
'make test' failure in spamd_maxchildren, spamd_parallel, etc
Last modified: 2004-04-28 15:17:01 UTC
SpamAssassin version 3.0.0-r10051 "make test" generates failures in t/spamd_maxchildren, t/spamd_parallel, and t/whitelist_addrs. Last test from t/log/spamd_maxchildren-spamd.err: logmsg: connection from localhost.localdomain [127.0.0.1] at port 32928 logmsg: Still running as root: user not specified with -u, not found, or set to root. Fall back to nobody. logmsg: processing message <9PS291LhupY> for root:99. debug: ---- MIME PARSER START ---- debug: main message type: text/plain debug: parsing normal part debug: added part, type: text/plain debug: ---- MIME PARSER END ---- debug: bayes: no dbs present, cannot tie DB R/O: ./log/user_state/bayes_toks debug: received-header: parsed as [ ip=193.120.211.219 rdns=mail.webnote.net helo=webnote.net by=mail.netnoteinc.com ident= envfrom= intl=0 id=09C18114095 ] debug: received-header: parsed as [ ip=24.226.157.50 rdns=USR-157-050.dr. cgocable.ca helo=netsvr.Internet by=webnote.net ident= envfrom= intl=0 id=IAA29903 ] debug: received-header: parsed as [ ip=216.214.106.173 rdns=max1-45.losangeles. corecomm.net helo=R00UqS18S by=netsvr.Internet ident= envfrom= intl=0 id=1429NTL5 ] Can't call method "get_num_nets" on unblessed reference at .. /blib/lib/Mail/SpamAssassin/Received.pm line 96, <GEN2> line 39. logmsg: server killed by SIGTERM, shutting down The "Can't call method "get_num_nets" on unblessed reference" error appears for each test that fails. Data::Dumper output of $spam->{conf}, called just before that line in Received. pm, shows this : 'trusted_networks' => { 'nets' => undef },
Created attachment 1923 [details] spamd_maxchildren-spamd.err perl 5.8.3, Fedora test2, fyi.
Created attachment 1924 [details] full 'make test' output
I have a feeling it's related to the config copy code ... will take a look. wonder if this is related to 3301?
Yep, "trusted_networks" doesn't survive the copy_config() process. It looks like copy_config tries to poke around with the NetSet object internals by coping data from it and dump it back in after the scan, except that $conf_backup->{trusted_networks} is a HASH and is copied back as such, destroying the NetSet object that used to exist.
yep. copy_config()... fixed in r10323. commit comment: bug 3317: copy_config() needs to deal with the one-off object copying (in this case the trusted networks object array) _before_ dealing with standard reference copying. I didn't put it in the comment, but the problem was that we'd make a note in the backup copy that trusted_networks (or internal_networks) should be dealt with, but then when we copied from backup to the main config we weren't dealing with a NetSet object, just a HASH reference, so the conf NetSet object would get blown away, and it would be replaced with a HASH reference, which has no code associated with it. I moved the generic copy to the bottom of the loop and put in an obvious all-uppercase note to leave the generic copy at the bottom for this very reason.
*** Bug 3279 has been marked as a duplicate of this bug. ***
*** Bug 3282 has been marked as a duplicate of this bug. ***