Hello - We have a random, recurring bug here at $work that is boggling my mind. Occasionally, when a bit of code tries to delegate to its SUPER class, the package name is somehow off by one random letter. Here's an example of the error message we're getting:

Can't locate object method "new" via package "MyCompany::Oages::TemplateConstants::SUPER" at MyCompany::Pages::TemplateConstants::new

This error is triggered by the following (slightly abbreviated) code:

package MyCompany::Pages::TemplateConstants; use strict; use warnings; use base qw(MyCompany::Interfaces::Object); # don't ask, it's lega +cy code sub new { my $class = shift; my $self = $class->SUPER::new(); # <--- randomly fails ... return $self; }

At the line where SUPER::new is called, the error is triggered. This code is executed thousands of times per day successfully but about once per day, it fails with the error listed above. The error varies slightly but there is always one letter in the class name that is "decremented" by one letter. In the specific case I pasted above, the P is turned into an O but it could be any letter in the class name. For instance, I've seen the following failures as well (in different classes but the same symptom):

MyCompany::Pages::TemplateObjectWraoper::SUPER
  vs.
MyCompany::Pages::TemplateObjectWrapper::SUPER

or

MyCompany::Pages::TemplateAbcount::SUPER
  vs.
MyCompany::Pages::TemplateAccount::SUPER

I can't understand how the value of $class would allow code execution to get into the correct new method but then when calling $class->SUPER::new it no longer provides the correct class to allow the @ISA traversal to work. In some instances, the invocant is a class name (i.e. $class as shown above) but in other times, it's a blessed reference (i.e. $self). The same error pops up in either case.

I'm not sure it's related to an incorrect @ISA but we are not (knowingly) modifying the contents of any classes @ISA array. I've grep'd through all of the CPAN modules we're using and I can't find anything that fiddles with a packages @ISA at this level (although I don't really know what to grep for in compiled C extensions).

I have not had the opportunity yet to put debugging code in our production environment to try and track down more specifically the state of $class/$self or @ISA. Are there any other bits of data that might be helpful to log in troubleshooting this issue?

We are using Perl v5.12.2.

Can anyone think of any possibilities for what is causing this bug?

Thanks for any help you might offer!


In reply to SUPER delegation fails because class name getting munged (somehow?) by bpphillips

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.