Completion crash owing to bad allocation

[Peter Stephenson <Peter.Stephenson@csr.com>]

On Wed, 11 May 2011 15:27:35 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> I'm running into a segfault, though. The git repository is located in
> `/tmp/linux-2.6'. I've changed a file (fs/adfs/dir.c) slightly and I'm
> doing this:
> 
>   % git add f<tab>
>   % git add fs/<tab>
>   % git add fs/adfs/<tab>
> 
> And that's where the shell crashes. It's a build of today's HEAD.

This seems to be another variant of the "amatches" problem.

amatches is a global in the completion code that holds one version of
the list of matches during completion.  This is on the heap, and because
it's not scoped it's virtually impossible to keep track of the point at
which it becomes invalid.  For extra ease of maintainance, at some point
in the procedure it is deliberately set to point to a permanently
allocated copy.  When the crash happens we are scanning through
some (possibly subtly disguised) part of amatches and examining some
no longer valid memory.

One way to tackle this would be to add a stack corresponding to the
current heap stack, with each level having a unique (up to 32-bit
integer wrap) ID that tells you if that heap variant is valid.  Then
when memory is allocated for use by a Cmgroup it stores the ID
corresponding to the currently pushed heap at the top of the stack
(with a special ID to be used if it was permanently allocated).  Every
time amatches is examined the code could report an error if a heap ID
stored somewhere along the list doesn't correspond to one somewhere on
the current heap debug stack.  (Unfortunately examining amatches at the
point of a popheap() won't work --- the code is lax about marking
amatches as invalid, it just expects you not to access it in that case,
which is part of the problem.)

I won't be doing the completion code debugging, I'm fed up with days of
my life disappearing into code I never seem to get any closer to
understanding and have quite enough else to manage, but if someone
thinks they might get round to that (understanding is optional for now,
we just need to be able to track what's going on with amatches) I'd be
happy to have a go at writing the tools for heap debugging.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom