[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 };
--Eric
--
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
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
More information about the Pdx-pm-list
mailing list