Front page | perl.perl5.porters |
Postings from November 2016
Re: [perl #130010] v5.25.5-184-ga5540cf breaks texinfo
Thread Previous
|
Thread Next
From:
demerphq
Date:
November 9, 2016 08:55
Subject:
Re: [perl #130010] v5.25.5-184-ga5540cf breaks texinfo
Message ID:
CANgJU+UdGL0rHhJczUO4NXaRs98sD0qMR73MR45AMNOZ-BH0FA@mail.gmail.com
On 7 Nov 2016 17:29, "James E Keenan via RT" <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 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
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next