Scant info to go on, but maybe this will help some.

Devel::StackTrace is called from Exception::Class::Base which is a part of Exception::Class which is used by HTML::Mason.

Working back from the other end, the actual error message you are seeing is being raised in sv.c (line 3734 in 5.8.1-rc4) in the function Perl_sv_setsv_flags(). The stated purpose of this function (although it can be called from the perl sources and/ or XS code under the guise of several macros) is to copy one scalar to another. The situation in which it raises this error is when it encounters a source scalar that is a reference to a HASH/ARRAY/CODE/IO. It doesn't explain why this is considered bizarre, but it's probably obvious to those (few) that understand it:).

In the most generic sense, it would appear that an exception is being raised inside Mason and it is in the process of trying to generate a stack trace, and specifically, trying to get a copy of the arguments (DB::args) to the function (or probably method) that was called before the exception was raised, and it is during the process of copying these args from an array in the DB package to a local array that it encounters a scalar that is a reference which is considered an error, either because of the time when it is being copied, or because of the method being used to copy it.

Beyond this purely circumstantial evidence, there's not much more that can be identified until you can identify the code at your end that is causing the exception to be raised. Looking at the sample you posted in your follow up, it looks some sort of linked list is being set up. The archetypical error with this sort of code is that somewhere, a node in the link list gets linked back to itself and the next time a search or insert occurs, it starts looping around forever. Total speculation, but I think that's about the best you hope for given the sparsity of the info.

To try and debug this further, you either need to re-create the problem whilst running under the debugger, which is a PIA to do for a webapp, or you need to litter warn statements through your app. Starting at the highest level, isolate where the Bizzarre msg is coming from and track it in function by function, line by line until you find where your leaving your code, and with what parameters, prior to the msg.

The fact that the exception reporting mechanism is itself riasing an exception is decidedly unhelpful:), and is probably something that the author of most of the modules I listed above, Dave Rolsky would be interested in. Of course, he'd prefer a 5 line script that demonstrated the problem along with your bug report, but it might be worth contacting him even without that as this miight be something he has encountered before.

It would also be worth ensuring that you are running the latest version of Mason and its dependancies and that the error still exists, before you do make contact though, as that's almost certainly the first question you will be asked.

An afterthought, but possibly a significant one. The error could be right there in Devel::StackTrace.

The code in question is trying to get the arguments that were passed to a sub from DB::args, but it doesn't check to see if there were any args passed to the sub (frame) in question.

Try modifying the line in the error message to read:

my @a = $c[4] ? @DB::args : ();
[download]

and see if the problem goes away.

Logic: From Perlfunc:caller()

...$hasargs is true if a new instance of @_ was set up for the frame....

Furthermore, when called from within the DB package, caller returns more detailed information: it sets the list variable @DB::args to be the arguments with which the subroutine was invoked.

If so, you're SOL because I've given up supporting RedHat's idiotic decisions to ship beta/dev software. Try installing a real 5.8.0 and see if the bug goes away.

OTOH, if it is a real Perl 5.8.0, a recipe to reproduce this would be welcome. But please send it to me via email.

A bit more information: the errors always seem to happen when I make a method call (pump from IPC::Run, or some of our internal module methods). The data structures used in the vicinity of where I'm seeing frequent errors are extremely, um, baroque. A few representative lines:

${$children->[0]->{'harness'}}->{'next'} = $inUse;
$children->[0]->{'harness'} = $inUse;
$inUse = $$inUse->{'next'};
${$children->[0]->{'harness'}}->{'next'} = undef;
[download]

Please note that I didn't write this code, and would rather rewrite it than debug it, but that may not be an option right now.