Seg-fault running t/io/fs.t under Devel::DProf #5455
Comments
From sam@airtrout.tregar.comCreated by sam@airtrout.tregar.comRunning t/io/fs.t under Devel::DProf seg-faults reliably: [sam@airtrout bleadperl]$ cd t Looking at it under gdb, it's faulting at DProf.xs at line 319: GV *gv = CvGV(cv); This looks to be the same problem as the one I reported triggering through I plan to investigate further, although I don't know have high hopes for -sam Perl Info |
From @samtregarOn 13 May 2002 sam@airtrout.tregar.com wrote:
I've done some further investigation. The segfault occurs just before the In case it helps, here's the backtrace I forgot to include in the original Program received signal SIGSEGV, Segmentation fault. |
From @jhiOn Mon, May 13, 2002 at 08:19:05PM -0400, Sam Tregar wrote:
p cv (being able to call B::Deparse::coderef2text() easily from gdb would be neat)
-- |
From @samtregarOn Tue, 14 May 2002, Jarkko Hietaniemi wrote:
(gdb) p cv
(gdb) p *cv
(gdb) call Perl_sv_dump(cv) And, if you're wondering where cv, came from - it resulted from a (gdb) call Perl_sv_dump(Sub) I think the PV value is an artifact of my having turned on DBG_SUB in -sam |
From @jhiOn Mon, May 13, 2002 at 08:35:35PM -0400, Sam Tregar wrote:
Well, dereferencing that (as CvGV() would do) leads nowhere. Or, as
If I knew ::DProf enough to what is supposed to be in the SvIVX
Yes, please.
-- |
From @samtregarOn Tue, 14 May 2002, Jarkko Hietaniemi wrote:
Amen brother. Preach it. I've experimented with patches that just return() from prof_mark() if (cv
Well, Sub comes from: SV *Sub = GvSV(PL_DBsub); /* name of current sub */ And PL_DBsub is just a funny name for $DB::sub, I think. And $DB::sub is So does that ring any bells?
Ok. Here's Sub with DBG_SUB off: (gdb) call Perl_sv_dump(Sub) And in case you're curious, here's PL_DBsub too: (gdb) call Perl_sv_dump(PL_DBsub) -sam |
From @jhi
Pretty silent around here, I'm afraid.
-- |
From @samtregarOn Mon, 13 May 2002, Sam Tregar wrote:
Wrong, me. It is a dual-var, but I'm pretty sure I don't know what it Actually, the PV side is in some kind of a quantum state. If I never do a I think the weirdness in PL_DBsub has something to do with Devel::DProf #define PERLDBf_NONAME 0x40 /* For _SUB: no name of the subr */ Which makes exactly no sense to me. The effect of PERLDBf_NONAME is to Can anyone throw me a line? Is it possible that no one in all of p5p-dom -sam |
From @jhi
I think IlyaZ is the one to ask. -- |
From @samtregarOn Tue, 14 May 2002, Sam Tregar wrote:
Hey man. I did some checking and I managed to boil down your test case to $ ./perl -Ilib -d:DProf -e 'require "t/test.pl"; SKIP: {skip("test")}' I still don't know what the problem is, but I surmise it has something to Strangely, when I tried to add this as a test case to Devel::DProf's tests -sam |
From @samtregarOn Tue, 14 May 2002, Sam Tregar wrote:
Whoa there dumbass. You must have misunderstood how Devel::DProf's test Call off the Schwern! -sam |
From @samtregarOn Tue, 14 May 2002, Sam Tregar wrote:
Here's a way to trigger it without an external file: $ ./perl -w -Ilib -d:DProf -e 'sub skip { last SKIP; } SKIP: { skip; }' Interestingly, that warning doesn't happen even after adding "-w" in the Investigating pp_ctl.c leads me to think that pp_last() is to blame. So, the task then is to figure out how to write code in pp_last() that -sam |
From @samtregarOn Tue, 14 May 2002, Sam Tregar wrote:
Wow, can one man be wrong this often in one day? It looks like goto is $ ./perl -w -Ilib -d:DProf -e 'sub foo { goto BAR; } foo(); BAR: 1;' -sam |
From @samtregarI've concluded that I do not know how to fix [ID 20020513.015]. I think So, here's what I can do. This patch adds a test that catches the problem 1) Is perldiag the right place to describe a croak() from a core module or 2) How would I go about adding a test for something that should panic? -sam Inline Patchdiff -Naur bleadperl.0/ext/Devel/DProf/DProf.pm bleadperl/ext/Devel/DProf/DProf.pm
--- bleadperl.0/ext/Devel/DProf/DProf.pm Fri Sep 21 14:11:58 2001
+++ bleadperl/ext/Devel/DProf/DProf.pm Wed May 15 16:11:48 2002
@@ -154,6 +154,23 @@
change the numeric slot (it will I<mark> it as invalid, but will not
write over it).
+Another problem is that if a subroutine exits using goto(LABEL),
+last(LABEL) or next(LABEL) then Devel::DProf will die with the error:
+
+ panic: Devel::DProf inconsistent subroutine return
+
+For example, this code will break under Devel::DProf:
+
+ sub foo {
+ last FOO;
+ }
+ FOO: {
+ foo();
+ }
+
+A pattern like this is used by Test::More's skip() function, for
+example. See L<perldiag> for more details.
+
Mail bug reports and feature requests to the perl5-porters mailing list at
F<E<lt>perl5-porters@perl.orgE<gt>>.
diff -Naur bleadperl.0/ext/Devel/DProf/DProf.xs bleadperl/ext/Devel/DProf/DProf.xs
--- bleadperl.0/ext/Devel/DProf/DProf.xs Tue May 14 21:43:53 2002
+++ bleadperl/ext/Devel/DProf/DProf.xs Wed May 15 15:35:31 2002
@@ -533,6 +533,7 @@
dMARK;
dORIGMARK;
SV *Sub = GvSV(PL_DBsub); /* name of current sub */
+ IV this_cv = SvIVX(Sub); /* address of sub on entry */
#ifdef PERL_IMPLICIT_CONTEXT
/* profile only the interpreter that loaded us */
@@ -554,6 +555,15 @@
PUSHMARK(ORIGMARK);
perl_call_sv(INT2PTR(SV*,SvIV(Sub)), GIMME_V | G_NODEBUG);
PL_curstash = oldstash;
+
+ /* Make sure we returned from the sub we called. If the called
+ * sub was exited via a goto, next or last then this will
+ * croak() rather than allow prof_mark to segfault. A better
+ * solution would be to fix Devel::DProf to work with subs
+ * that exit abnormally, but that is beyond my power. [Sam Tregar] */
+ if (SvIVX(GvSV(PL_DBsub)) != this_cv)
+ croak("panic: Devel::DProf inconsistent subroutine return");
+
prof_mark(aTHX_ OP_LEAVESUB);
g_depth--;
}
diff -Naur bleadperl.0/pod/perldiag.pod bleadperl/pod/perldiag.pod
--- bleadperl.0/pod/perldiag.pod Sun May 12 16:09:15 2002
+++ bleadperl/pod/perldiag.pod Wed May 15 15:37:54 2002
@@ -2582,6 +2582,13 @@
(P) Failed an internal consistency check while trying to reset a weak
reference.
+=item panic: Devel::DProf inconsistent subroutine return
+
+(P) Devel::DProf called a subroutine but a different subroutine
+returned. This can happen if a subroutine exits using goto(LABEL),
+last(LABEL) or next(LABEL). This is a bug that will hopefully one day
+get fixed.
+
=item panic: die %s
(P) We popped the context stack to an eval context, and then discovered |
From @samtregarOn Wed, 15 May 2002, Sam Tregar wrote:
Testing this patch with a larger application shows that it breaks some So, cancel this patch. If I can't get any more traction I'll submit a doc -sam |
From @smpeters
It appears that the patch above along with some other fixes went into |
From @jkeenanOn Mon May 13 08:22:35 2002, sam@airtrout.tregar.com wrote:
PATH=/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/local/mysql/bin/:/usr/local/apache/bin:/usr/X11R6/bin:/home/sam/bin
Devel::DProf has been removed from the Perl 5 core distribution: ###### Data for 2013-05-18 In fact, it has been deprecated in favor of Devel::NYTProf. Hence, I believe we don't need to explore this ticket further. I am Thank you very much. |
From @jkeenanOn Sat Aug 03 09:28:12 2013, jkeenan wrote:
Correction: I see that Steve Peters had previously taken this ticket, Thank you very much. |
From @cpansproutOn Sat Aug 03 09:28:12 2013, jkeenan wrote:
If DProf (on CPAN) still crashes (on panics) with the latest blead, then -- Father Chrysostomos |
From @jkeenanOn Sat Aug 03 10:19:46 2013, sprout wrote:
Unfortunately, I can't get far enough in installing Devel::DProf to run ##### I've never had to "specify prototyping behavior for DProf.xs" and don't So I recommend that we close this RT regardless of the status or Thank you very much. |
From @dcollinsnDevel::DProf is deprecated and has not been in core, or updated, since 5.14. Closing. |
From [Unknown Contact. See original ticket]Devel::DProf is deprecated and has not been in core, or updated, since 5.14. Closing. |
|
@dcollinsn - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#9321 (status was 'rejected')
Searchable as RT9321$
The text was updated successfully, but these errors were encountered: