Tie hash Segmentation fault

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

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', };` [download] Should be: `tie %s, 'Apache::Session::File', undef, { Directory => '/tmp/sessions', };` [download]	[reply] [d/l] [select]
Re^2: Tie hash Segmentation fault by gam3 (Curate) on Jan 08, 2010 at 12:39 UTC
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.	[reply]
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.	[reply] [d/l]
Re^2: Tie hash Segmentation fault by gam3 (Curate) on Jan 08, 2010 at 12:32 UTC
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 () [download] UPDATE: Updated GDB output to version with symbol table. -- gam3 A picture is worth a thousand words, but takes 200K.	[reply] [d/l]
Re^3: Tie hash Segmentation fault by educated_foo (Vicar) on Feb 09, 2010 at 02:29 UTC
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.	[reply]
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. If you are running under a persistant environment--mod_perl or fastcgi--isn't the use of global variables problematic? 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. "I'd rather go naked than blow up my ass"	[reply]
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	[reply] [d/l] [select]