On Sat, Jun 26, 2010 at 04:37:17PM -0600, Alex Hunsaker wrote: > On Sat, Jun 26, 2010 at 15:29, Tim Bunce <[email protected]> wrote: > > On Fri, Jun 25, 2010 at 10:02:29AM -0600, Alex Hunsaker wrote: > >> On Fri, Jun 25, 2010 at 04:47, Tim Bunce <[email protected]> wrote: > >> > >> Hrm seems to be null on this setup: > > > NYTProf's pp_entersub_profiler() gets called instead of > > perl's pp_entersub(). The first thing pp_entersub() does is call > > SvTYPE(sv) on the value on the top of the stack. > > Yeah, If I throw in some quick fprintf to mod_perls > modperl_perl_call_list we see it calls call_sv with bad values. > > modperl_util.c:482 > for (i=0; i<=AvFILLp(subs); i++) { > CV *cv = (CV*)ary[i]; > SV *atsv = ERRSV; > > fprintf(stderr, "call_list: %d %p\n\n", i, cv); > ... > > gives us: > call_list: 0 0x82b16dc > call_list: 1 0x82aece4 > call_list: 2 0x820db2c > call_list: 3 0xc1 > > Interestingly if I change the options I give NYTProf I can change cv: > default: 0xf09 > stmts=0: 0xc1 > subs=0: 0x41 > > So it smells like some kind of corruption to me. If I run it under valgrind: > ==27940== Invalid read of size 4 > ==27940== at 0x4A52F84: modperl_perl_call_list (modperl_util.c:479) > ==27940== by 0x4A61697: modperl_perl_call_endav (modperl_perl.c:199) > ==27940== by 0x4A616F2: modperl_perl_destruct (modperl_perl.c:142) > ==27940== by 0x4A454DC: modperl_interp_destroy (modperl_interp.c:146) > ==27940== by 0x4A455FB: modperl_interp_pool_destroy (modperl_interp.c:202) > ==27940== by 0x40B14CC: run_cleanups (in /usr/lib/libapr-1.so.0.4.2) > ==27940== by 0x40B2136: apr_pool_destroy (in /usr/lib/libapr-1.so.0.4.2) > ==27940== by 0x40B23C7: apr_pool_clear (in /usr/lib/libapr-1.so.0.4.2) > ==27940== by 0x8064D94: main (in /usr/sbin/httpd) > ==27940== Address 0x5717d04 is 0 bytes after a block of size 28 free'd > ==27940== at 0x4023B1C: free (in > /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) > ==27940== by 0x4B39F4B: Perl_safesysfree (util.c:262) > ==27940== by 0x4B59E4A: Perl_av_extend (av.c:166) > ==27940== by 0x4B5A3D5: Perl_av_store (av.c:352) > ==27940== by 0x4B5B43D: Perl_av_push (av.c:562) > ==27940== by 0x5739B31: XS_DB__END (NYTProf.xs:4973) > ==27940== by 0x4B6CCD2: Perl_pp_entersub (pp_hot.c:2888) > ==27940== by 0x572F5EB: pp_subcall_profiler (NYTProf.xs:2421) > ==27940== by 0x572F467: pp_entersub_profiler (NYTProf.xs:2378) > ==27940== by 0x4AC7F91: Perl_call_sv (perl.c:2717) > ==27940== by 0x4A5304A: modperl_perl_call_list (modperl_util.c:484) > ==27940== by 0x4A61697: modperl_perl_call_endav (modperl_perl.c:199) > > I dont have any idea _why_. Ring any bells ?
No, but by inspection: http://perl.apache.org/dist/mod_perl-2.0-current/src/modules/perl/modperl_util.c void modperl_perl_call_list(pTHX_ AV *subs, const char *name) { I32 i, oldscope = PL_scopestack_ix; SV **ary = AvARRAY(subs); MP_TRACE_g(MP_FUNC, "pid %lu" MP_TRACEf_TID MP_TRACEf_PERLID " running %d %s subs", (unsigned long)getpid(), MP_TRACEv_TID_ MP_TRACEv_PERLID_ AvFILLp(subs)+1, name); for (i=0; i<=AvFILLp(subs); i++) { CV *cv = (CV*)ary[i]; SV *atsv = ERRSV; PUSHMARK(PL_stack_sp); call_sv((SV*)cv, G_EVAL|G_DISCARD); if (SvCUR(atsv)) { Perl_sv_catpvf(aTHX_ atsv, "%s failed--call queue aborted", name); while (PL_scopestack_ix > oldscope) { LEAVE; } Perl_croak(aTHX_ "%s", SvPVX(atsv)); } } } you could argue whose fault it is, but their code is not robust against the array changing whilst they are iterating over it. They've used AvARRAY() to get a pointer to the array's storage, and a side effect of a recent code change I made is that we now might cause that array to get extended. Of course, I looked at the core perl source to see how END blocks were run, and the behaviour was safe with perl. perl unshifts each CV from the list before it calls it. I should have remembered that inevitably mod_perl is "special". On reflection, I think that this *is* a bug in mod_perl, as they're going to get tripped up in similar fashion if any code run as part of an END block contains a string eval containing an END block. This list, obviously, isn't the right place to report bugs in mod_perl. Nicholas Clark -- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected]
