Hi,

it is not a real memory corruption/crash but it breaks with ASAN, making the
use of ASAN for regular GDB runs difficult.


echo 'void f(char *s){}main(){f((char *)1);}'|gcc -g -x c -;../gdb ./a.out -ex 'b f' -ex r
====ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000aaccf at pc 0x96eea7 bp 0x7fff75bdbc90 sp 0x7fff75bdbc80
READ of size 1 at 0x6020000aaccf thread T0
    #0 0x96eea6 in extract_unsigned_integer .../gdb/findvar.c:108
    #1 0x9df02b in val_print_string .../gdb/valprint.c:2513
[...]
0x6020000aaccf is located 1 bytes to the left of 8-byte region [0x6020000aacd0,0x6020000aacd8)
allocated by thread T0 here:
    #0 0x7f45fad26b97 in malloc (/lib64/libasan.so.1+0x57b97)
    #1 0xdb3409 in xmalloc common/common-utils.c:45
    #2 0x9d8cf9 in read_string .../gdb/valprint.c:1845
    #3 0x9defca in val_print_string .../gdb/valprint.c:2502
[..]
====ABORTING


No regressions on {x86_64,x86_64-m32,i686}-fedorarawhide-linux-gnu.

I do not think it can cause any behavior change.


Thanks,
Jan