Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Cores almost on demand in patcompile()
On Thu, 20 Oct 2016 11:42:16 +0100
Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> On Thu, 20 Oct 2016 12:30:50 +0200
> Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author