http://qs321.pair.com?node_id=810858

mje has asked for the wisdom of the Perl Monks concerning the following question:

I realise this is a tough one but I'm hoping someone might be to give me new ideas on how to track this error down. Background: a very large application written in Perl and happily running on 5.8 on another server. Moved to new server with 5.10.0 AND changed some code to use Try::Tiny and now we get a lot of these panics.

I've tried reproducing the problem in a small example but have failed. That example looks something like this:

use Try::Tiny; use Log::Log4perl qw(get_logger :levels); Log::Log4perl->init_and_watch('/etc/log4.conf', 60); my $log = get_logger('Q::S'); fred(); sub fred { my $x = try { dave(); 0; } catch { my $ev = $_; if (0) { eval { my $a = 1; 1; } or $log->warn("failed $@"); } else { $log->logwarn("test $_"); } 1; }; print "$x\n"; return if $x; # <---- this would be q.pl line 1895 } sub dave { # the following line would be DB.pm line 1380 my ($sth, $options, @args) = @_; }

The big problem is we seem to have to run this code a while before it starts happening and then it happens all the time. I can run the code in debug and I get slightly more out of it:

perl -t -I /home/martin/modules/BET/lib q.pl -n1 -p 9999 -r -c /etc/se +rvices.ini Attempt to free unreferenced scalar: SV 0xa7b9650, Perl interpreter: 0 +x9ad0008 at q.pl line 1895, <GEN41> line 1. Failed to insert into job_audit, panic: attempt to copy freed scalar a +7b9650 to ad20598 at /home/martin/modules/X/lib/X/DB.pm line 1380, <G +EN42> line 1.

Any ideas how to identify the freed scalar and track this down?

Replies are listed 'Best First'.
Re: panic: attempt to copy freed scalar a7b9650 to ad20598
by BrowserUk (Patriarch) on Dec 03, 2009 at 16:47 UTC

    Suggestion: In the real code, inside its equivalent of dave(), put

    sub dave { die; ... }

    Does that make the failure you are seeing occur?

    What I'm getting at is does the attempt to copy freed only occur when dave() fails?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      The sample was not quite right. The sub "dave" is a generic sub which calls a procedure with DBD::Oracle. The call to "dave" in the example does fail but what is missing from the example is that the catch also may call "dave" but with a different procedure name. This is closer:

      use Try::Tiny; use Log::Log4perl qw(get_logger :levels); Log::Log4perl->init_and_watch('/etc/log4.conf', 60); my $log = get_logger('Q::S'); fred(); sub fred { my $x = try { # dave dies in the cases we get the panic dave('proc1', {}, 'arg1', 'arg2'); 0; } catch { my $ev = $_; if ($sometimes) { # sometimes goes this path and sometimes the + else eval { dave('proc2', {}, 'arg1', 'arg2'); 1; } or $log->warn("failed $@"); } else { $log->logwarn("test $_"); } 1; }; print "$x\n"; return if $x; # <---- this would be q.pl line 1895 } sub dave { # the following line would be DB.pm line 1380 my ($sth, $options, @args) = @_; }
        Re: trying to get a simple test case - After trying a simple die in dave(), try doing something simple in DBI, like selecting from a table that doesn't exist, with RaiseError set so that it dies. And with the variables scoped as closely as possible to that of your original program.

        What happens if you use "test $ev" instead?

Re: panic: attempt to copy freed scalar a7b9650 to ad20598
by gmargo (Hermit) on Dec 03, 2009 at 16:13 UTC

    The obvious question is: Which change caused the problem, new perl or Try::Tiny?

      Problem goes away when I remove the Try::Tiny code and change it back to eval. I'd rather not do that, I'd rather find the problem.

        I doubt the problem is with Try::Tiny. This kind of problem is caused by bugs in Perl code or code that uses Perl as a library (XS code, B::, etc), and Try::Tiny doesn't have anything that. In fact, it's a tiny (living up to its name) and straightforward (nothing fancy) Perl module.

        Start by trying your code on 5.10.1. Lots of bug fixes there.

Re: panic: attempt to copy freed scalar a7b9650 to ad20598
by markjugg (Curate) on Oct 22, 2010 at 23:24 UTC

    We got this same symptom today, using Try::Tiny 0.04:

    Attempt to free unreferenced scalar: SV 0x82d1fa0 at lib/Try/Tiny.pm l +ine 76. Attempt to free unreferenced scalar: SV 0x82d1fc0 at lib/Try/Tiny.pm l +ine 76. Attempt to free unreferenced scalar: SV 0x83d4060 at lib/Try/Tiny.pm l +ine 76. Attempt to free unreferenced scalar: SV 0x83d4080 at lib/Try/Tiny.pm l +ine 76. Segmentation fault (core dumped)
    We haven't found the root cause yet.
      I should mention: We are using Perl 5.8.8 on that server. Also, here's a third case of it happening, in the Fennec test suite. Search through CPAN tester data via Google may find more:

      In my case there was no problem in Try::Tiny but I had declared a variable like this my $thing if (some_test); which is really bad. The changes I made to introduce Try::Tiny seemed to have triggered the error to be seen.