Segfault during eval of a regex

[sharksforarms]

Found this interesting segfault today! Seems to happen using this regex, possibly others... But if you remove a single x, it no longer segfaults...

Here is a barebone example

use pcre2::bytes::RegexBuilder;

fn main() {
    let rgx = RegexBuilder::new().jit_if_available(true).build("xxxx|xxxx|xxxx").unwrap();
    rgx.is_match(&Vec::new()).unwrap();
}

[BurntSushi]

Could you please do the debugging work required to confirm that it's a bug in this library and not PCRE2 itself? I can indeed reproduce this, however, tweaking the regex as you suggest makes the segfault go away. That strongly points toward PCRE2 itself.

[BurntSushi]

Hmmm, I wonder if this is related to the fact that you're passing an empty vec. Since it doesn't allocate, it probably points to something that can't be dereferenced. So this library probably needs to special case an empty slice.

[sharksforarms]

That's a possibility, but I find it odd that the behavior would change with the regex, if it is upstream, possibly a optimization bug? I'll look into it further

[BurntSushi]

I think the empty slice issue is the more likely candidate.

But changing a regex and having it result in buggy behavior is by itself not odd at all. Lots of optimizations in production grade regex engines have thresholds and what not, which trigger different code paths. For example, in your regex, all branches have the same fixed length. So the regex engine can tell that there is no match by just inspecting the length. It could do the same thing when you remove an x (via a minimum fixed length), but there's no guarantee that that specific optimization is implemented. Of course, the reverse is happening here, but still, something like that could be going on.

[sharksforarms]

Yes most likely rgx.is_match(&vec![0]).unwrap(); passes

[sharksforarms]

    pub unsafe fn find(
        &mut self,
        code: &Code,
        subject: &[u8],
        start: usize,
        options: u32,
    ) -> Result<bool, Error> {
        println!("pointer: {:?}", subject.as_ptr());
        let rc = pcre2_match_8(
            code.as_ptr(),
            subject.as_ptr(),
            subject.len(),
            start,
            options,
            self.as_mut_ptr(),
            self.match_context,
        );

subject.as_ptr() seems to return an invalid pointer, an empty Vec does not allocate

[sharksforarms]

Not exactly sure what the best solution is yet, please take a look at the pull-request! Happy to make changes.

[BurntSushi]

Closed by #11.

[sharksforarms]

For completeness I also reported it to pcre2 maintainers: https://bugs.exim.org/show_bug.cgi?id=2440

On one hand: Yes, we're passing it an invalid pointer, who knows what will happen
On the other hand: The length is 0, the pointer shouldn't be read. Also only happens on certain regex.

[sharksforarms]

Fixed in upstream pcre 2: https://vcs.pcre.org/pcre2?view=revision&revision=1167

[BurntSushi]

Awesome, thanks!