This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
VEC.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |