It's weird that I didn't spot this problem earlier: When the number
of possible completions exceeds 128 (the initial size of the VEC
we use to store all completions), the debugger segfaults.

The problem, I think, is that I didn't understand how VEC_safe_push
works underneath. I didn't realize that this routine would change
the value of the given VEC*, I thought it would only change the
underlying record.

I used to have:

    procedure bla (VEC(char_ptr) *sv, ...)
    {
      ...
      VEC_safe_push (char_ptr, sv, some_string);
    }

When SV had to be expanded, the value of SV ended up being changed,
but this new address was never propagated back to the caller.

So I fixed the problem by turning parameter SV into a VEC**.

2008-02-07  Joel Brobecker  <brobecker@adacore.com>

        * ada-lang.c (symbol_completion_add): Make SV parameter a VEC**
        instead of just a VEC*. Update use of SV.
        (ada_make_symbol_completion_list): Update symbol_completion_add calls.

Tested on x86-linux, no regression. I'll commit now because it cures a SEGV
that is easy to hit, but I'd appreciate a second pair of eyes...

Thanks,
-- 
Joel