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

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

This code is causing perl to issue a Segmentation fault on a Debian Squeeze machine.
use Apache::Session::File; tie %s, 'Apache::Session::File', undef, { Directory => '/tmp/sessions', }; $s{'bob'} = "bill";
oddly
use Apache::Session::File; tie my %s, 'Apache::Session::File', undef, { Directory => '/tmp/sessions', }; $s{'bob'} = "bill";
does not Seg fault.

UPDATE: fixed typos.

-- gam3
A picture is worth a thousand words, but takes 200K.

Replies are listed 'Best First'.
Re: Tie hash Segmentation fault
by jwkrahn (Abbot) on Jan 08, 2010 at 07:33 UTC

    According to the documentation you are missing a comma after the third argument.

    tie %s, 'Apache::Session::File', undef { Directory => '/tmp/sessions', };

    Should be:

    tie %s, 'Apache::Session::File', undef, { Directory => '/tmp/sessions', };
      You are quite right, but it has nothing to do with the Segmentation fault. No text in a perl script should ever cause a segmentation fault.
      -- gam3
      A picture is worth a thousand words, but takes 200K.
Re: Tie hash Segmentation fault
by educated_foo (Vicar) on Jan 08, 2010 at 04:39 UTC
    You would be more likely to get help if you ran it inside gdb (e.g. "gdb --args perl my-script.pl"), grabbed a backtrace with the "where" command, and posted that.
      Yes you are quite correct. That would be helpful.

      The bug seems to be in Storable.

      Program received signal SIGSEGV, Segmentation fault. 0x00007ffff662f194 in do_store (my_perl=0x602010, f=0x0, sv=0x74dad0, +optype=0, network_order=1, res=0x7fffffffe440) at Storable.xs:3739 3739 dSTCXT; #0 0x00... in do_store (my_perl=0x602010, f=0x0, sv=0x74dad0, optype= +0, network_order=1, res=0x7fffffffe440) at Storable.xs:3739 #1 0x00... in net_mstore (my_perl=0x602010, cv=<value optimized out>) + at Storable.xs:3914 #2 XS_Storable_net_mstore (my_perl=0x602010, cv=<value optimized out> +) at Storable.xs:6444 #3 0x00... in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #4 0x00... in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #5 0x00... in Perl_call_sv () from /usr/lib/libperl.so.5.10 #6 0x00... in Perl_sv_clear () from /usr/lib/libperl.so.5.10 #7 0x00... in Perl_sv_free2 () from /usr/lib/libperl.so.5.10 #8 0x00... in ?? () from /usr/lib/libperl.so.5.10 #9 0x00... in Perl_sv_clean_objs () from /usr/lib/libperl.so.5.10 #10 0x00... in perl_destruct () from /usr/lib/libperl.so.5.10 #11 0x00... in main ()
      UPDATE:
      • Updated GDB output to version with symbol table.
      -- gam3
      A picture is worth a thousand words, but takes 200K.
        Here is where Perl debugging gets ugly. "dSTCTX" expands into something or other, often through multiple layers of macros, and GDB doesn't do so well at debugging macros. Your goal is to fully expand "dSTCTX" and figure out which part of it is seg-faulting.
Re: Tie hash Segmentation fault
by BrowserUk (Patriarch) on Jan 08, 2010 at 07:18 UTC

    Not my areas of knowledge--*nix nor Apache--but two things ring bells in my head.

    1. If you are running under a persistant environment--mod_perl or fastcgi--isn't the use of global variables problematic?
    2. Why are you passing the return value of undef to tie?

    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.
Re: Tie hash Segmentation fault
by doug (Pilgrim) on Jan 08, 2010 at 17:20 UTC

    gam3,

    I have no idea what is going on here. It does look like your program has ended and is cleaning up when this happens. If so, that implies the segfault comes from improper cleanup issues. Try untie when you are done with %s to see if that fixes anything.

    - doug