Commit
6b1747cd1 ("invoke_xmethod & array_view") contains this change:
- argvec = (struct value **) alloca (sizeof (struct value *) * 4);
+ value *argvec_storage[3];
+ gdb::array_view<value *> argvec = argvec_storage;
However, value_x_unop still does:
argvec[2] = value_from_longest (builtin_type (gdbarch)->builtin_int, 0);
argvec[3] = 0;
This triggers an error with -fsanitize=address from userdef.exp:
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdcf185068 at pc 0x000000e4f912 bp 0x7ffdcf184d80 sp 0x7ffdcf184d70
WRITE of size 8 at 0x7ffdcf185068 thread T0
#0 0xe4f911 in value_x_unop(value*, exp_opcode, noside) ../../binutils-gdb/gdb/valarith.c:557
[...]
I think the two assignments to argvec[3] should just be removed, and
that this was intended in the earlier patch but just missed.
This passes userdef.exp with -fsanitize=address.
gdb/ChangeLog
2018-11-29 Tom Tromey <tom@tromey.com>
* valarith.c (value_x_unop): Don't set argvec[3].
+2018-11-29 Tom Tromey <tom@tromey.com>
+
+ * valarith.c (value_x_unop): Don't set argvec[3].
+
2018-11-26 Simon Marchi <simon.marchi@ericsson.com>
PR gdb/23917
case UNOP_POSTINCREMENT:
strcpy (ptr, "++");
argvec[2] = value_from_longest (builtin_type (gdbarch)->builtin_int, 0);
- argvec[3] = 0;
nargs ++;
break;
case UNOP_POSTDECREMENT:
strcpy (ptr, "--");
argvec[2] = value_from_longest (builtin_type (gdbarch)->builtin_int, 0);
- argvec[3] = 0;
nargs ++;
break;
case UNOP_LOGICAL_NOT: