Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #42293] t/doc/pod.t vs. tools/doc/pod_errors.pl

5 views
Skip to first unread message

Will Coleda

unread,
Apr 4, 2007, 12:29:13 AM4/4/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Will Coleda
# Please include the string: [perl #42293]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >


These two scripts perform the same basic task, but do so inconsistently.

The tools/ script should be removed, and someone should investigate
how it's checking the pod (it finds errors in the current distro
while the test does not.)

--
Will "Coke" Coleda
wi...@coleda.com


Joshua Isom

unread,
Apr 4, 2007, 6:48:25 AM4/4/07
to perl6-i...@perl.org, bugs-bi...@rt.perl.org

I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
grep -v 'pod syntax OK'` gives me far too many errors and warnings to
be good. Seems as though podchecker is stricter than our pod checker.

Paul Cochrane

unread,
Apr 4, 2007, 7:39:16 AM4/4/07
to Joshua Isom, perl6-i...@perl.org, bugs-bi...@rt.perl.org
On 04/04/07, Joshua Isom <jri...@gmail.com> wrote:
> On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
>
> > # New Ticket Created by Will Coleda
> > # Please include the string: [perl #42293]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >
> >
> >
> > These two scripts perform the same basic task, but do so
> > inconsistently.
> >
> > The tools/ script should be removed, and someone should investigate
> > how it's checking the pod (it finds errors in the current distro
> > while the test does not.)
> >
> > --
> > Will "Coke" Coleda
> > wi...@coleda.com
>
> I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
That's interesting; what OS are you using? I'm using Gentoo linux x86
and found with, for example, the t/codingstd/c_indent.t test would
cause (the gentoo package) perl to segfault. However, I've compiled
my own version of perl (same version as well 5.8.8) and it runs the
tests fine and the tools/docs/pod_errors.pl test runs. Anyway, the
reason I'm interested is because I was wondering if the segfault were
a Gentoo perl proplem.

> But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
> podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
> grep -v 'pod syntax OK'` gives me far too many errors and warnings to
> be good. Seems as though podchecker is stricter than our pod checker.

That's odd, as I fixed a failing pod test a while ago where an extra
C<=cut> was in a C<.pmc> file and podchecker said everything was hunky
dory, but t/doc/pod.t was complaining. Running the file just through
perldoc didn't seem to throw up anything either. So it seems that at
times podchecker isn't as strict.

The output from tools/docs/pod_errors.pl at least gives information
about where the problem is in the file, which is something that
t/doc/pod.t unfortunately doesn't.

Just my 2c.

Paul

Jerry Gay

unread,
Apr 4, 2007, 10:47:56 AM4/4/07
to perl6-i...@perl.org, bugs-bi...@rt.perl.org
without looking, my guess is that the different scripts are checking
different sets of files. this alone would lead to differing reports.
~jerry

Joshua Isom

unread,
Apr 4, 2007, 3:33:49 PM4/4/07
to Paul Cochrane, Perl 6 Internals, bugs-bi...@rt.perl.org
On Apr 4, 2007, at 6:39 AM, Paul Cochrane wrote:

> On 04/04/07, Joshua Isom <jri...@gmail.com> wrote:
>> On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
>>
>> > # New Ticket Created by Will Coleda
>> > # Please include the string: [perl #42293]
>> > # in the subject line of all future correspondence about this issue.
>> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >
>> >
>> >
>> > These two scripts perform the same basic task, but do so
>> > inconsistently.
>> >
>> > The tools/ script should be removed, and someone should investigate
>> > how it's checking the pod (it finds errors in the current distro
>> > while the test does not.)
>> >
>> > --
>> > Will "Coke" Coleda
>> > wi...@coleda.com
>>
>> I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
> That's interesting; what OS are you using? I'm using Gentoo linux x86
> and found with, for example, the t/codingstd/c_indent.t test would
> cause (the gentoo package) perl to segfault. However, I've compiled
> my own version of perl (same version as well 5.8.8) and it runs the
> tests fine and the tools/docs/pod_errors.pl test runs. Anyway, the
> reason I'm interested is because I was wondering if the segfault were
> a Gentoo perl proplem.
>

I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
don't think I've gotten perl to segfault in quite some time, and if I
trust my crashreporter log, the problem almost always is in S_regmatch,
but I'm not sure which file actually does the checking, too much
inheritance runaround.

>> But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
>> podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
>> grep -v 'pod syntax OK'` gives me far too many errors and warnings to
>> be good. Seems as though podchecker is stricter than our pod checker.
> That's odd, as I fixed a failing pod test a while ago where an extra
> C<=cut> was in a C<.pmc> file and podchecker said everything was hunky
> dory, but t/doc/pod.t was complaining. Running the file just through
> perldoc didn't seem to throw up anything either. So it seems that at
> times podchecker isn't as strict.
>
> The output from tools/docs/pod_errors.pl at least gives information
> about where the problem is in the file, which is something that
> t/doc/pod.t unfortunately doesn't.
>
> Just my 2c.
>
> Paul
>

So we have three methods to test for pod errors, and three different
standards for the pod. Seems as though this ticket got a little more
complicated.

Jerry Gay

unread,
Apr 6, 2007, 2:55:49 PM4/6/07
to Joshua Isom, Paul Cochrane, Perl 6 Internals, bugs-bi...@rt.perl.org
On 4/6/07, Nicholas Clark <ni...@ccl4.org> wrote:

> On Wed, Apr 04, 2007 at 02:33:49PM -0500, Joshua Isom wrote:
>
> > I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
> > don't think I've gotten perl to segfault in quite some time, and if I
> > trust my crashreporter log, the problem almost always is in S_regmatch,
> > but I'm not sure which file actually does the checking, too much
> > inheritance runaround.
>
> If it's a crash in S_regmatch that's usually due to a regular expression
> going exponential and exhausting the C stack. In turn, that's usually due to
> nested capturing parentheses, non-matching, and lots of backtracking.
>
> Whilst the C stack crash is fixed in 5.9.x, those sorts of regexps can often
> take an insane amount of time to realise that they aren't going to match,
> so (assuming I'm right here) it means that it's likely that there's a
> badly written (to the point of buggy) regexp in the pod checker.
>
> Not that that really helps track it down.
>
well, it does point us to Pod::Simple::Checker, which is the checker
that's used in tools/docs/pod_errors.pl.
~jerry

Nicholas Clark

unread,
Apr 6, 2007, 2:49:14 PM4/6/07
to Joshua Isom, Paul Cochrane, Perl 6 Internals, bugs-bi...@rt.perl.org
On Wed, Apr 04, 2007 at 02:33:49PM -0500, Joshua Isom wrote:

> I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
> don't think I've gotten perl to segfault in quite some time, and if I
> trust my crashreporter log, the problem almost always is in S_regmatch,
> but I'm not sure which file actually does the checking, too much
> inheritance runaround.

If it's a crash in S_regmatch that's usually due to a regular expression


going exponential and exhausting the C stack. In turn, that's usually due to
nested capturing parentheses, non-matching, and lots of backtracking.

Whilst the C stack crash is fixed in 5.9.x, those sorts of regexps can often
take an insane amount of time to realise that they aren't going to match,
so (assuming I'm right here) it means that it's likely that there's a
badly written (to the point of buggy) regexp in the pod checker.

Not that that really helps track it down.

Nicholas Clark

Nicholas Clark

unread,
Apr 6, 2007, 2:57:37 PM4/6/07
to jerry gay, Joshua Isom, Paul Cochrane, Perl 6 Internals, bugs-bi...@rt.perl.org

IIRC I found and removed one of those from a Pod module that was integrated
into bleadperl. It may well have been Pod::Simple, and if so, as Allison has
released new versions recently, it should now be gone, if it wasn't already.

Nicholas Clark

0 new messages