Front page | perl.perl5.porters |
Postings from May 2003
seeking help in debugging a segfault in pp_goto
Thread Next
From:
pcg
Date:
May 11, 2003 10:44
Subject:
seeking help in debugging a segfault in pp_goto
Message ID:
20030511174405.GA13277@schmorp.de
Hi, I am on the list, but a courtesy CC: would help me a lot, thx.
Anyways, I am reporting,f rom time to time, strange segfault problems that
I cannot create testcases for, and now I found a reproducible segfault,
but still way too large to make a testcase out of it.
The program implements an object system that dynamically loads objects
(which includes perl code) from a database while running. Thus I have
heavy compiling activity, together with heavy use of exceptions + most
features that perl offers, which proved to be an explosive mix (although
5.8.1 works quite well nowadays).
Ok, I have this piece of source:
use overload
'&{}' => sub {
my $self = shift;
sub {
unshift @_, $self;
goto &call;
};
};
And if I remove that goto all works fine, but if I add it, I get a
segfault here (around ppctl.c line 2293, which is):
#ifndef USE_5005THREADS
if (cx->blk_sub.hasargs)
#endif /* USE_5005THREADS */
{
AV* av = (AV*)PAD_SVl(0);
SV** ary;
#ifndef USE_5005THREADS
cx->blk_sub.savearray = GvAV(PL_defgv);
GvAV(PL_defgv) = (AV*)SvREFCNT_inc(av);
#endif /* USE_5005THREADS */
CX_CURPAD_SAVE(cx->blk_sub);
cx->blk_sub.argarray = av;
++mark;
**2293** if (items >= AvMAX(av) + 1) {
ary = AvALLOC(av);
The segfault seems to be caused by av being zero (although I am not 100%
sure, gdb is currently having a vacation on linux and not very reliable
when debugging apache).
This is in a non-threaded 5.8.1 snapshot. Any ideas what could cause this,
or for what I should be looking for? I initially thought that PAD_SV(0)
should be GvAV(PL_defgv) in my perl, but that is of course untrue.
BTW, the overload above is used to create "callbacks" that can be called
like normal functions, even if not loaded, i.e. I have objects that
contain a plan on how to load the necessary code into memory and then
jumps into it, using (another) goto which made similar problems.
Since I could never get a sensible backtrace of it, I just removed
it. This one I can seem to reproduce, or maybe the circumstances are just
"better".
Here is a perl backtrace just before the segfault (the STORE is actually
a tied scalar STORE), which features 2 nested callback calls, only the
nested one segfaults:
Warning[13442]: cluck at /opt/perl/lib/perl5/PApp/Callback.pm line 215
PApp::Callback::Function::__ANON__('undef','PApp::Callback::Function=ARRAY(0x9482ca0)','PApp::DataRef::Scalar=HASH(0x9482c88)',12884902367) called at /opt/perl/lib/perl5/PApp/DataRef.pm line 205
PApp::DataRef::Scalar::STORE('PApp::DataRef::Scalar=HASH(0x9482c88)',12884902367) called at /root/src/PApp/macro/editform.papp line 144
PApp::PPKG0005::_ef_parse_field('HASH(0x94537b8)',8,'iso-8859-1') called at /root/src/PApp/macro/editform.papp line 203
PApp::PPKG0005::__ANON__('PApp::FormBuffer=HASH(0x93e2218)','ef02','text/plain','HASH(0x863602c)','HASH(0x86360d4)') called at (PApp.pm) line 1148
PApp::parse_multipart_form('CODE(0x9163650)') called at /root/src/PApp/macro/editform.papp line 241
PApp::PPKG0005::__ANON__ called at /opt/perl/lib/perl5/PApp/Callback.pm line 200
PApp::Callback::Function::call('undef','undef','undef') called at (PApp.pm) line 2004
eval {...} called at (PApp.pm) line 2020
PApp::_handler() called at (PApp/Apache.pm) line 122
PApp::Apache::__ANON__('Apache=SCALAR(0x84a9224)') called at /dev/null line 0
eval {...} called at /dev/null line 0
Thanks a lot for any insights ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Thread Next
-
seeking help in debugging a segfault in pp_goto
by pcg