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 2005/12/06 19:42:09 UTC
[Bug 4722] New: make test failing in t/recreate.t test
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
Summary: make test failing in t/recreate.t test
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: Building & Packaging
AssignedTo: dev@spamassassin.apache.org
ReportedBy: sidney@sidney.com
Running make test on a clean build of svn trunk is failing the t/recreate.t test
as shown below. Justin has speculated that
''I think it's a bug that's now being exposed by the first plugin file
checked in to the "rules" or "rulesrc" directories; ie. alongside the
rules, not alongside the code. in other words it was only a matter of
time before it was exposed.
My guess is that Plugin::register_eval_hook() is attempting to create a
new eval hook every time the loadplugin line is read, instead of just
once.''
Result from running make TEST_FILES=t/recreate.t
---------------
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/recreate.t
t/recreate....ok 4/9Subroutine new redefined at
/b/home/sidney/sasvn/trunk/t/../t/log/test_rules_copy/sandbox-felicity.pm line 28.
Subroutine check_iframe_src redefined at
/b/home/sidney/sasvn/trunk/t/../t/log/test_rules_copy/sandbox-felicity.pm line 46.
Subroutine check_from_format redefined at
/b/home/sidney/sasvn/trunk/t/../t/log/test_rules_copy/sandbox-felicity.pm line 56.
Subroutine subject_length redefined at
/b/home/sidney/sasvn/trunk/t/../t/log/test_rules_copy/sandbox-felicity.pm line 69.
Subroutine check_html_uri_only redefined at
/b/home/sidney/sasvn/trunk/t/../t/log/test_rules_copy/sandbox-felicity.pm line 75.
t/recreate....NOK 9# Failed test 9 in t/recreate.t at line 76
t/recreate....FAILED test 9
Failed 1/9 tests, 88.89% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/recreate.t 9 1 11.11% 9
Failed 1/1 test scripts, 0.00% okay. 1/9 subtests failed, 88.89% okay.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
------- Additional Comments From jm@jmason.org 2005-12-06 21:27 -------
+1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
------- Additional Comments From felicity@apache.org 2005-12-07 00:27 -------
(In reply to comment #4)
> that said, it might be worth producing a patch for 3.1.0 as I'm sure it's an
> issue there, too.
Yeah, though I don't feel really strongly either way. +0 basically.
It's a trivial patch, but the likelihood people are running into this issue is small. The issue comes down to
our call to "do $module" which does no error checking (like the module is in %INC) as require does. The
problem only happens when you have a single perl interpreter trying to load the same module twice, which
would typically only happen if you have multiple Mail::SpamAssassin objects in memory, which most
people wouldn't do.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
------- Additional Comments From felicity@apache.org 2005-12-06 21:06 -------
I put in a patch that fixes this issue for me, r354530. Basically, check %INC to see if we've already loaded
the module and skip the plugin if we have.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
------- Additional Comments From jm@jmason.org 2005-12-06 22:53 -------
my +1 wasn't a vote meaning "you may apply it", it was a general vote indicating
"I think this is the right way to go about fixing it".
that said, it might be worth producing a patch for 3.1.0 as I'm sure it's an
issue there, too.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
------- Additional Comments From lwilton@earthlink.net 2005-12-07 05:34 -------
But what if someone wanted to test sandbox rules against 3.10? Wouldn't be
that the same case you fixed in trunk?
I had the impression that Justin had been intending that the sandbox setup
could handle "multiple SA versions" so that rules could be created and vetted
for potentially any of the more recent versios of SA. Certainly SARE tests
rules on multiple SA versions.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4722] make test failing in t/recreate.t test
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4722
sidney@sidney.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From sidney@sidney.com 2005-12-06 22:14 -------
This needs a vote? It isn't for 3.1 branch is it, and if it is, don't we need a
patch to vote on?
I'll assume that it is all set -- I have tested it on my system and no longer
see the error -- and mark this fixed.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.