Re: completion crash

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 30,  6:26pm, Mikael Magnusson wrote:
} Subject: Re: completion crash
}
} I've tracked this down to something calling popheap() when it
} shouldn't, because putting "return;" at the top of popheap() makes the
} crash go away, also, at one point during all this, in
} parse.c:ecgetstr(), char *r gets a string assigned to it that has the
} same address as amatches->matches, which is subsequently overwritten
} by an strcpy. I'm not exactly sure if it's this corruption that causes
} the crash, what eventually crashes is an access to
} amatches->matches->prpre which is broken.
} (gdb) print amatches->matches
} $5 = (Cmatch *) 0x7ffff7fe3fa0
} #1  0x000000000048008c in dupstring (s=0x6bd8fc "-s") at string.c:40
} 40	    strcpy(t, s);
} (gdb) print t
} $7 = 0x7ffff7fe3fa0 "-"
} 
} This is presumably not good. Any ideas?

If you're in dupstring() when that strcpy() happens, then I strongly
suspect that what's happening is that amatches->matches points to
freed memory which is being re-allocated in dupstring().

This could be because popheap() is being called improperly, or it may
instead be that amatches or amatches->matches is not being reset to
zero at some point where the memory it points to is correctly freed.
I believe we've had that latter come up before.

Or it could be amatches should never point into heap memory and there
is a dupstring() or zhalloc() in a spot that should be a ztrdup() or
zalloc() instead.  Most likely you're goig to need to find the place
where amatches->matches is being set, rather than the spot where it is
already pointing at garbage.