Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Template-Toolkit CPAN distribution.

Report information
The Basics

Nobody in particular
jasonjcrowther [...]

Broken in:
Fixed in:

Subject: Possible Bug with Redundant USE in an INCLUDEd Template
first off, many thanks for the great tool. long time user, first time I've run into a problem. after a recent upgrade from TT 2.14 to 2.20 (on perl 5.8.8, linux: 2.6.20-1.2320.fc5), I'm getting a fatal error when I have a redundant USE for a custom filter in an INCLUDEd file. Previously, this generated no errors or warnings. here's some code that exhibits the quirk: # ------- - simple driver script #!/usr/bin/perl use Template; my $tt = Template->new({'PLUGIN_BASE'=>'test'}); $tt->process('t1.txt',{ 'name' => 'jason', 'name2' => 'fred', 'name3' => 'jim', }) || print STDERR $tt->error(); # ------- t1.txt - simple template [% USE simple %] test 1: [% name | simple %] [% INCLUDE t2.txt %] test 3: [% name3 | simple %] # ------- t2.txt - an included template [% USE simple %] test 2: [% name2 | simple %] # ------- a super simple custom filter package test::simple; use Template::Plugin::Filter; use base qw( Template::Plugin::Filter ); sub filter { my ($self, $text, $args, $conf) = @_; return qq|**|.$text.qq|**|; } sub init { my $self = shift; $self->{'_DYNAMIC'}=1; my $name = $self->{ _CONFIG }->{ name } || 'simple'; $self->install_filter($name); return $self; } 1; #---------- This example works fine in 2.14. In 2.20, it generates the following error: undef error - Can't call method "filter" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Template/Plugin/ line 74. If I comment out the USE for simple in t2.txt it works fine. Is this a bug or change in default behaviour? I'd prefer to be able to keep the redundant USE. in my real world usage, the t1 is template for an entire page, while t2 is the template for an ajax updateable fragment of the page. so when used for the fragment, it needs to have the USE on its own, otherwise it just inherits from the calling template. thanks for the help and keep up the great work!
Hi Jason, Thanks for the bug report. It's now been fixed. A new developer release will be coming out Real Soon Now. Cheers A
I'm not sure but I think there might be an actual fix rather than just reverting your weaken'ing of the $self ref. It looks like when you USE a plugin, it gets placed in the stash with the name of the plugin as the key. When the same plugin is USE'd a second time, it is set in the stash with the same name which causes the first reference to be garbage collected (if it's been weakened). It looks like if you use an alias when USE'ing the plugin (i.e. [% USE foo = MyPlugin %][% USE foo2 = MyPlugin %]) is a decent workaround but does require you to pretty much ALWAYS use this form of USE and never with the same alias in any of your files that are processed by a single TT instance. Perhaps you could force a unique name when storing the plugin in the stash (Template::Directive::use)? (name + args or something even more unique?) Or perhaps push the plugin references onto a list or stack object in the stash (or some other place in the TT object tree) if it's used more than once? Alternatively in my own custom plugins, I've been maintaining an additional reference to the plugin object in a class-level lexical hash to keep the refcount from getting to zero prematurely. Perhaps this is reintroducing the same memory leak that the original bug report asked you to fix by weakening the ref :-) On Sat Jul 04 12:32:51 2009, ABW wrote:
Show quoted text
> Hi Jason, > > Thanks for the bug report. It's now been fixed. > > > > A new developer release will be coming out Real Soon Now. > > Cheers > A
And this gets back. I am having lots of memory leaks because of that commented weaken :-(
I, too, am having problems with memory leaks from this location.
Just in case it helps anyone reading this bug, at CV-Library we ran into this issue, and worked around it by rewriting our code to avoid Template::Plugin::Filter: I'm afraid that doesn't help solve the original problem though! Tim

This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with to