https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
--- Comment #1 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
Hi Akhilesh,
No that's certainly not a known issue -- thanks for reporting it!
I'm having trouble reproducing your issue, do you mind giving a little more
information on your command line and the machine you're running on etc?
One point that seems worth looking into is that the line numbers on your
backtrace don't seem to match up with the line numbers in my source tree.
(e.g. GetAccessInfo is given line number 383 of hwasan_linux.cpp, while in my
source tree that function spans lines 328-376). Have you made any
modifications to the source? Or maybe you're running a different libsanitizer
version?
For reference I'm using libsanitizer from LLVM hash
6e7dd1e3e1170080b76b5dcc5716bdd974343233, and the sha256sum of hwasan_linux.cpp
in my source tree is
3986e9f4e519409e7c73a7b97722125300afc4dc1f44a3f966fedf679329fd0a.
Based on what line number `HwasanOnSIGTRAP` calls `GetAccessInfo` in my source
tree, and assuming the offset between our line numbers are the same for the
GetAccessInfo line in your stack trace, it seems that the SEGV happens when
dereferencing the address that caused the signal.
That value should be the address of the `brk` instruction in __hwasan_load1
(having been inlined from `SigTrap` in hwasan_checks.h) which caught the bad
access, but the value of 0x30 which caused this SEGV is clearly not that value.
If the offset between our line numbers is a bit different, then getting that
address might make a bit more sense. There are various struct member accesses
via pointers that `GetAccessInfo` recieves.
However, those arguments are just taken from the siginfo_t and ucontext_t
pointers that the kernel provides on receipt of a deadly signal.
I haven't found any access in that function which look like they would have an
offset of 0x30 from a NULL pointer, although I guess different kernel versions
would have different offsets.
What kernel are you running on? Is there any chance the signal handler
HwasanOnDeadlySignal is getting a NULL pointer as one of its arguments?
For reference I happen to be running on a linux kernel based off of commit
585e5b17b9 (but with some modifications that should not affect anything -- just
config changes so I can build the kernel itself with -fsanitize=hwaddress).
Just for reference -- what I see when compiling your testcase:
ubuntu@ubuntu:~/working-directory/temp/pr97941$
../../gcc-hwasan-install/bin/gcc -fsanitize=hwaddress ./test.c -o test
./test.c: In function ‘main’:
./test.c:2:20: warning: implicit declaration of function ‘malloc’
[-Wimplicit-function-declaration]
2 | char *x = (char*)malloc(10 * sizeof(char*));
| ^~~~~~
./test.c:1:1: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
+++ |+#include <stdlib.h>
1 | int main() {
./test.c:2:20: warning: incompatible implicit declaration of built-in function
‘malloc’ [-Wbuiltin-declaration-mismatch]
2 | char *x = (char*)malloc(10 * sizeof(char*));
| ^~~~~~
./test.c:2:20: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
./test.c:3:3: warning: implicit declaration of function ‘free’
[-Wimplicit-function-declaration]
3 | free(x);
| ^~~~
./test.c:3:3: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’
./test.c:3:3: warning: incompatible implicit declaration of built-in function
‘free’ [-Wbuiltin-declaration-mismatch]
./test.c:3:3: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’
ubuntu@ubuntu:~/working-directory/temp/pr97941$
LD_LIBRARY_PATH=~/working-directory/gcc-hwasan-install/lib64 ./test
==8600==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefe0ffff0005 at pc
0xffffa828be70
READ of size 1 at 0xefe0ffff0005 tags: e2/d5 (ptr/mem) in thread T0
#0 0xffffa828be6c in SigTrap<0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27
#1 0xffffa828be6c in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:88
#2 0xffffa828be6c in __hwasan_load1
../../../../gcc-source/libsanitizer/hwasan/hwasan.cpp:375
#3 0x400944 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400944)
#4 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
[0xefe0ffff0000,0xefe0ffff0060) is a small unallocated heap chunk; size: 96
offset: 5
0xefe0ffff0005 is located 5 bytes inside of 80-byte region
[0xefe0ffff0000,0xefe0ffff0050)
freed by thread T0 here:
#0 0xffffa828d64c in __sanitizer_free
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:108
#1 0x400934 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400934)
#2 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
#3 0x400814 (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)
previously allocated here:
#0 0xffffa828db30 in __sanitizer_malloc
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:169
#1 0x400928 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400928)
#2 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
#3 0x400814 (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)
hwasan_dev_note_heap_rb_distance: 1 1023
hwasan_dev_note_num_matching_addrs: 0
hwasan_dev_note_num_matching_addrs_4b: 0
Thread: T0 0xeffe00002000 stack: [0xffffccb69000,0xffffcd369000) sz: 8388608
tls: [0xffffa8bdc000,0xffffa8bdc760)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
0xfefd0fffef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffefa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffefb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffefc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffefd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffefe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0fffeff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
=>0xfefd0ffff000:[d5] d5 d5 d5 d5 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
0xfefd0ffff080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Tags for short granules around the buggy address (one tag corresponds to 16
bytes):
0xfefd0fffeff0: .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
..
=>0xfefd0ffff000:[..] .. .. .. .. .. .. .. .. .. .. .. .. .. ..
..
0xfefd0ffff010: .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
..
See
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules
for a description of short granule tags
SUMMARY: HWAddressSanitizer: tag-mismatch
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27 in SigTrap<0>
