Front page | perl.perl5.porters |
Postings from November 2016
Re: [perl #130010] v5.25.5-184-ga5540cf breaks texinfo
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
November 9, 2016 09:13
Subject:
Re: [perl #130010] v5.25.5-184-ga5540cf breaks texinfo
Message ID:
6cacd67d-0b21-2563-2130-53aaf16f45e5@cpan.org
On 11/09/2016 09:54 AM, demerphq wrote:
>
> On 7 Nov 2016 17:29, "James E Keenan via RT"
> <perlbug-followup@perl.org <mailto:perlbug-followup@perl.org>> wrote:
> >
> > On Mon, 07 Nov 2016 13:47:55 GMT, jkeenan wrote:
> > >
> > > The question is: What is it about this the pattern:
> > >
> > > #####
> > >
> /([^\S\x{202f}\x{00a0}]+)|(\p{InFullwidth})|((?:[^\s\p{InFullwidth}]|[\x{202f}\x{00a0}])+)/
> > > #####
> > >
> > > ... that (a) as of commit C<a5540cf> but not previously; and (b) in
> > > the context of this test suite but not in isolation, perceives
> > > something to be a read-only value not subject to modification?
> >
> > My next brainstorm: Add "use re 'debug';" to sub add_text() in
> tp/Texinfo/Convert/ParagraphNonXS.pm.
> >
> > When I did so and ran the debugging program found in one of my
> previous attachments, I got this output:
> >
> > #####
> >
> Texinfo::Convert::ParagraphNonXS::add_text(../../tp/Texinfo/Convert/ParagraphNonXS.pm:329):
> > 329: my @segments = split
> > 330:
> /([^\S\x{202f}\x{00a0}]+)|(\p{InFullwidth})|((?:[^\s\p{InFullwidth}]|[\x{202f}\x{00a0}])+)/,
> > 331: $text;
> > DB<6> n
> > Matching REx
> "([^\S\x{202f}\x{00a0}]+)|(\p{InFullwidth})|((?:[^\s\p{InFull"...
> against "This is "
> > 0 <> <This is > | 0| 1:BRANCH(18)
> > 0 <> <This is > | 1| 2:OPEN1(4)
> > 0 <> <This is > | 1| 4:PLUS(16)
> > | 1| ANYOF[\t\n\x0B\f\r \x85][1680
> 2000-200A 2028-2029 205F 3000] can match 0 times out of 2147483647...
> > | 1| failed...
> > 0 <> <This is > | 0| 18:BRANCH(34)
> > 0 <> <This is > | 1| 19:OPEN2(21)
> > 0 <> <This is > | 1|
> 21:ANYOF[+utf8::Texinfo::Convert::ParagraphNonXS::InFullwidth](32)
> > | 1| failed...
> > 0 <> <This is > | 0| 34:BRANCH(68)
> > 0 <> <This is > | 1| 35:OPEN3(37)
> > 0 <> <This is > | 1| 37:CURLYM[0]{1,INFTY}(66)
> > 0 <> <This is > | 2| 39:BRANCH(51)
> > 0 <> <This is > | 3| 40:ANYOF[^\t\n\x0B\f\r
> \x85\xA0{+utf8::Texinfo::Convert::ParagraphNonXS::InFullwidth}1680
> 2000-200A 2028-2029 202F 205F 3000](64)
> > Modification of a read-only value attempted at
> ../../tp/Texinfo/Convert/ParagraphNonXS.pm line 329.
> > at ../../tp/Texinfo/Convert/ParagraphNonXS.pm line 329.
> >
> Texinfo::Convert::ParagraphNonXS::add_text(Texinfo::Convert::ParagraphNonXS=HASH(0x35ba938),
> "This is ") called at ../../tp/Texinfo/Convert/Info.pm line 308
> >
> Texinfo::Convert::Info::_info_header(Texinfo::Convert::Info=HASH(0x35b3038))
> called at ../../tp/Texinfo/Convert/Info.pm line 81
> >
> Texinfo::Convert::Info::output(Texinfo::Convert::Info=HASH(0x35b3038),
> HASH(0x35ab7c0)) called at ../texi2any.pl <http://texi2any.pl> line 1348
> > panic: POPSTACK
> > Debugged program terminated.
> > #####
> >
> > Since I have never previously used the regex debugger, I have no
> idea if there are any clues to a solution in that output.
> >
> > Thoughts?
>
> Have you tried putting a breakpoint or assert on the code that issues
> the error message about an attempt to modify a RO value, and then used
> gdb to get a stack trace?
>
> If its a macro that you arent sure where it gets called, put an assert
> that will fail, like assert(0); in where the code to print the message
> gets called, and then run under gdb.
>
> Once you have a stack-trace we will be interested in whatever happens
> in or after the call to reginclass().
>
> Once you have that you should be able to add a sv_dump() call to the
> right place to see the var that is triggering the RO. (You can do this
> right before the assert(0); call).
>
> BTW, from what i can tell from the re 'debug' output, the error comes
> from trying to fulfil
>
> [^\s\p{InFullwidth}]
>
>
> which is the third item in that alternation. So it seems like the
> issue is somehow related to negating a charclass, possibly in negating
> the return from InFullWidth. I was unaware that \p{} could execute at
> run time, I thought it would be resolved at compile time and baked
> into the char-class. So I would also look for things in InFullWidth
> that might not work if called twice. Does InFullWidth somehow return
> constant values?
>
> Anyway, I have not managed to find a copy of InFullWidth to look at,
> nor the code that calls this. But I would use Devel::Peek sv_dump(),
> gdb, and the techniques above to dig into this if I were debugging it.
> I am not sure where the core comes in, i have never really debugged a
> core dump.
>
> Another thing I would do is twiddle that charclass. If you change it to
>
> [^ \t\n\r\p{InFullWidth}]
>
> does the bug go away?
>
> What happens if you remove all the \p{InFullWidth} from that pattern?
>
> No doubt you are way beyond any of the advice here, but i thought i
> would write this anyway.
>
> Yves
User-defined \p properties, which InFullWidth is, that aren't available
at compile time are expanded at run time. It used to be that all \p
were done at run time. The problem here likely is that the changes in
the blamed commit are trying to modify a swash byproduct that has been
set read-only. I have looked at the code, and don't see how that is
happening, which is why a stack trace is needed. So, getting that back
trace is the best way forward.
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next