Hi Thomas,
On Sun, May 18, 2014 at 12:10:13AM +0200, Thomas Heil wrote:
> Hi,
>
> On 17.05.2014 16:58, Willy Tarreau wrote:
> > Hi Thomas,
> >
> > On Sat, May 17, 2014 at 03:12:40PM +0200, Thomas Heil wrote:
> >> The patch works. No crashes anymore. Thanks a lot,
> > Thanks for confirming, however the fix is still not good (regfree
> > may only be called with a non-null pointer, and still needs free()
> > to be run afterwards). Could you please check with this one instead :
> >
> > free(errmsg);
> > - free(preg);
> > + if (preg) {
> > + regfree(preg);
> > + free(preg);
> > + }
> Ive tried with this patch
> -b
> Index: haproxy-1.5-dev25/src/cfgparse.c
> ===================================================================
> --- haproxy-1.5-dev25.orig/src/cfgparse.c
> +++ haproxy-1.5-dev25/src/cfgparse.c
> @@ -1580,7 +1580,10 @@ static int create_cond_regex_rule(const
>
> err:
> free(errmsg);
> - free(preg);
> + if (preg) {
> + regfree(preg);
> + free(preg);
> + }
> return err_code;
> }
> --
>
> but this leads to a segmentation fault. I wonder why nobody else runs
> in that issue.
Honnestly I don't know. I fear that something nasty is being done
to the memory area beneath us, or that an overflow happens on the
area. Is there a risk that you're building with libpcre with without
its headers ? I'm asking because I don't know if the regex_t struct
from libpcre has the same size as the glibc's, thus that could explain
a few things...
Thanks,
Willy
