Re: Cores almost on demand in patcompile()

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 20 Oct 2016 11:42:16 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Thu, 20 Oct 2016 12:30:50 +0200
> Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> > Valgrind points at patadd(NULL, 0, nmeta, 0). Wonder why not to its
> > interior? But to all logic, problem should be inside patadd() because
> > nothing else near dereferences a pointer. So there might be two
> > problems. Debugger didn't report inaccessible memory when I did
> > step-over on the patadd(), maybe memory is accessible but invalid from
> > other reason recognized by Valgrind.
> 
> Just to be sure, could you confirm the problem goes away if you change
> line 292 of pattern.c
> 
> /* Default size for pattern buffer */
> #define P_DEF_ALLOC 256
> 
> to
> 
> /* Default size for pattern buffer */
> #define P_DEF_ALLOC 512
> 
> ?  That's not a fix, it's just putting off the problem, but if it's
> initially allocating something larger than what your pattern needs I'd
> expect the crash not to happen.

I'm now starting to wonder if the realloc is a red herring and the key
point is this...

		 * Careful in case we've overwritten the node for the next ptr.

It's a long time since I did this but if the P_PURESTR flag is set,
I don't think there can be more than one P_EXACTLY.  So the solution may
be to break out of the for loop at the end of the

		    if (P_OP(pscan) == P_EXACTLY) {
		        /* .... */
			break;      /* <- here... */
		    }

immediately after line 692 in the modified code since the "next" can't
be relevant any more.

pws