develooper Front page | perl.perl5.porters | Postings from January 2017

[perl #130561] Coredump in Perl_re_op_compile

Thread Previous | Thread Next
From:
Hugo van der Sanden via RT
Date:
January 27, 2017 19:08
Subject:
[perl #130561] Coredump in Perl_re_op_compile
Message ID:
rt-4.0.24-7828-1485544109-974.130561-15-0@perl.org
On Fri, 27 Jan 2017 10:32:31 -0800, demerphq wrote:
> On 27 January 2017 at 19:04, Hugo van der Sanden via RT
> <perlbug-followup@perl.org> wrote:
> > On Fri, 27 Jan 2017 08:02:14 -0800, demerphq wrote:
> >> On 27 January 2017 at 16:15, Hugo van der Sanden wrote:
> >> > I'm not entirely sure that I have a use case, but what I had in
> >> > mind
> >> > was to modify the fixup loop as in your "this GOSUB may have been
> >> > optimized away" change, but combine it with a regexec-time check &
> >> > panic should we see a GOSUB that hasn't had its target set (which
> >> > requires inventing a way to flag that). Failing that, we should at
> >> > least have an assert at the point of fixup, for a clea[nr]er
> >> > failure
> >> > mode.
> >>
> >> If we do this in debug mode only then I see no harm.
> >
> > I had planned to make it a mandatory panic (not only under
> > DEBUGGING), instead of the SEGV or worse you would otherwise get.
> >
> >> Can I leave that part to you?
> >
> > For now yes - I had already had a go at it (assuming I could set
> > arg2=0 and test that for "not set") but got a bunch of test failures,
> > which I haven't tried to dig into yet. If I can't use arg2, I might
> > want to use flags - but as far as I can see we don't ever actually
> > use those as flags, so some caution will be needed.
> 
> Wait wait. Are we talking about the same thing? I thought you were
> talking about guarding the code that produced the SEGV with logic like
> i posted in my GOSUB patch which I did not apply.

I'm talking about: carefully hiding mandatory fixups in an apparently optimization-only function such as study_chunk makes me nervous. Currently downstream code just assumes it has happened.

So the first thing I want to do is remove that assumption with a runtime check and panic.

The second thing I want to do is allow for the possibility we do optimizing things in the apparently optimization-only function, and take advantage of the runtime check to make it ok to skip unset RExC_recurse nodes (or ones that no longer point to GOSUBs).

I attach the failed attempt, that's the best explanation (though the commit message now needs changing).

Hugo

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=130561

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