[Pdx-pm] segfault: Carp::Heavy's fault?

Eric Wilhelm scratchcomputing at gmail.com
Thu Apr 17 10:29:50 PDT 2008

# from Randall Hansen
# on Thursday 17 April 2008 08:37:

>     throws_ok{ $one->process_remittance_advice } qr/required/;

Can you replicate this with some standalone code?  It sounds like 
process_remittance_advice() is calling croak(), possibly with an object 
and then...

># found: Modification of a read-only value attempted at
> /opt/local/lib/ perl5/5.8.8/Carp/Heavy.pm line 51.

We land in format_arg() presumably from caller_info(), where there is a 
map() involving @DB::args.

>and a couple lines later it segfaults.  the segfault is in vanilla  
>perl, between the time sub A `return`s a value and Sub B sees it.

A couple of lines later in Carp::Heavy, or in the test file?

>if i replace "throws_ok" with "eval" the segfault does not occur.

I suspect it is something with Carp trying to acquire the arguments in 
the call stack.  An eval {} has a different call stack than a "sub foo 
(&) {...}".  The block (aka subref) is being passed into 
Test::Exception's functions, where it gets eval'd inside of (I think) 
_try_as_caller(), and that involves Sub::Uplevel, which is doing some 
fun stuff with *CORE::GLOBAL::caller.

If you write your own sub, does it still segfault?  If not, it probably 
involves uplevel.

  sub my_eval (&) {
    my $sub = shift;
    eval {$sub->()};
  my_eval { $one->process_remittance_advice };

So malloc calls a timeout and starts rummaging around the free chain,
sorting things out, and merging adjacent small free blocks into larger
blocks. This takes 3 1/2 days.
--Joel Spolsky

More information about the Pdx-pm-list mailing list