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

Memory corruption maybe. Are you using weird XS modules? Does the error also pop up for other perl versions?

You can also try to usemro qw/c3/; and then $obj->next::method(@args) and see if the error goes away - if yes, it's really specific to SUPER

We had this suspicion as well but it's hard to prove what might be the culprit since it's not readily reproducible. We did recently discover ImageMagick is seg-faulting when we run our app on a 64-bit OS so it's possible there may be some memory corruption going on there that doesn't result in a seg-fault on 32-bit.

I'm not sure what qualifies as "weird" XS modules but scanning through the list of .so's I don't see anything sticking out. Everything we have is pretty standard CPAN stuff. This is mod_perl (v2.0.4) and Apache (2.2.17) however, so there's lots of stuff going on in the same memory space.

As it always seems to be just one bit flipping, it could also be hardware-related memory corruption.

I once had similar problems with very strange things happening occasionally.  At first, problems only occurred very seldomly, then more and more often. After quite a bit of hunting in the wrong places, it eventually turned out to be the power supply slowly getting flaky (voltage slowly dropping, and having more DC ripples than allowed).

So, if you can take the machine down, run a memory tester (such as memtest86).

Also, have maybe other strange things been happening on the machine?  For example, compiling huge programs has always been a good (indirect) "memory test" for me, as compilers tend to be quite sensitive to corrupted memory, and usually randomly crash as a result...

O is decimal 79 is binary 01001111, P is decimal 80 is binary 01010000. So this is not bit flipping, there is something really substracting 1

Ok, my fault.  The "argument" still holds, though, as hardware memory corruption mustn't necessarily result in only single bits flipping — it just happened to begin that way in the limited number of cases I've observed so far. I.e., the memtest statistics (after running for a couple of days) showed a clear pattern of certain "bit lines" flipping far more frequently than others.

Update:

I suspect something like

use MyClass;
my $obj = MyClass::new('MyBlass');
[download]

Sure, it's very straightforward:

$c->stash->{constant} = MyCompany::Pages::TemplateConstants->new($arg)
+; # this is in Catalyst
[download]

It looks good, I suspect static '::new' style with somehow munged first arg, but 'MyClass::MySubClass->new($args)' should be equivalent to 'MyClass::MySubClass::new("MyClass::MySubClass",$args)' (if method 'new' is implemented in MySubClass).

How is that a bug? My expectation would always be that SUPER is resolved in the context of the current package and that is the way it is documented in perlboot and perltoot along with pretty much anywhere else I've seen it mentioned in documentation.

True laziness is hard work

This was actually something that I've never really thought about and at first blush was surprising (although given five minutes of thought, it makes perfect sense). The fact that $class->SUPER::method() doesn't consider the value of $class at all could be unexepected since in typical use, the method is resolved relative to the invocant. Moose's bare super keyword avoids any confusion by removing the invocant altogether. This makes it (virtually) impossible to try and call some other class's (or object's) parent method via SUPER (or super in Moose's case).

sub new {
      my $class = shift;
      $class = ref($class) if ref($class);
      my $self = $class->SUPER::new(); # <--- randomly fails
      ...
      return $self;
    }
[download]

__PACKAGE__->SUPER::new();
[download]