develooper Front page | perl.perl5.porters | Postings from February 2003

Re: Inline::C seems to hang during make test

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 27, 2003 09:33
Subject:
Re: Inline::C seems to hang during make test
Message ID:
20030227173302.C2347@plum.flirble.org
Summary for p5p: David Dyck has found that Inline::C refuses to make test
on currently bleadperl. It seems to lock up into an infinite CPU loop.
Repeating "make test" causes it all to work. I can recreate the loop:
On Thu, Feb 27, 2003 at 04:35:03PM +0000, Nicholas Clark wrote:
> On Thu, Feb 27, 2003 at 04:06:51PM +0000, Nicholas Clark wrote:
> 
> > I don't quite what that means, but I'm guessing that something is sending
> > the regexp ending into a (near) infinite loop.
> 
> -Dtr suggests an infinite loop:
> 
> Found floating substr `'' at offset -1115720...
> Contradicts anchored substr `'', trying floating at offset -1115719...
> Found floating substr `'' at offset -1115720...
> Contradicts anchored substr `'', trying floating at offset -1115719...
> Found floating substr `'' at offset -1115720...
> Contradicts anchored substr `'', trying floating at offset -1115719...
> Found floating substr `'' at offset -1115720...
> Contradicts anchored substr `'', trying floating at offset -1115719...
> Found floating substr `'' at offset -1115720...

The loops is while matching the attached data against the attached regepx 

(as stolen from gdb:

(gdb) call open ("foo", 66, 511)
$4 = 10
(gdb) call write (10, 0x87251b0, 3379)
$5 = 3379
(gdb) call close(10)
$6 = 0

)

However, if I attempt to write a test script to do this, I see:

Found floating substr ` ' ' at offset 1827...
Contradicts anchored substr ` ' ', trying floating at offset 1828...
Found floating substr ` ' ' at offset 2186...
Found anchored substr ` ' ' at offset 1827...
Starting position does not contradict /^/m...
Guessed: match at offset 1827


then some more stuff, then

Match failed
Freeing REx: `" \\' [^\\\\']* (\\\\.[^\\\\']*)* \\' "'


and the script exits.
I've no idea where that offset of -1115719 comes from. The SV as matched
against is:

(gdb) call Perl_sv_dump(targ)
SV = PVMG(0x85a9520) at 0x85d8b18
  REFCNT = 37
  FLAGS = (SMG,POK,pPOK,SCREAM)
  IV = 0
  NV = 0
  PV = 0x87251b0 "\12code:   part(s) \12        {\12         return 1;\12
...
else: \12        /.*/\12\12"\0
  CUR = 3379
  LEN = 3380
  MAGIC = 0x84f6e80
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = PERL_MAGIC_regex_global(g)
    MG_LEN = 473


so there doesn' appear to be any UTF8 flag on it. The most recent patching
activity nearby seems to be patch 15356:
http://public.activestate.com/cgi-bin/perlbrowse?patch=15356&action=patch

I'm not able to reverse that patch cleanly, so I can't test without it.
Any ideas? For debugging purposes, is it possible to disable Jarkko's UTF8
offset cache?

Should some assertions get added to trap negative offsets?

Nicholas Clark

PS regexp has no trailing newline. I'm not sure if mailers will add one.
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About