search for: highshadow

...ffset. I guess there are plenty of platforms where this > mapping > > won't work or will require different offset. > > I got a bit confused there, TBH. How do you guarantee that that part > of memory will be allocated? On 32-bit, the shadow region is: [0x28000000, 0x3fffffff]HighShadow[0x24000000, 0x27ffffff]ShadowGap[0x20000000, 0x23ffffff]LowShadow This is 0.5G total. So, I mmap all these three shadow subregions and 'mprotect' the ShadowGap. This is done at startup. If the mmap fails, an assert will fire. On 64-bit, the shadow looks like this: [0x0000140000000000, 0x0...

On 17 June 2011 09:14, Kostya Serebryany <kcc at google.com> wrote: > Maybe the fallback code should just use a function call. Much simpler for > documentation purposes. Sounds good. On 32-bit, the shadow region is: > [0x28000000, 0x3fffffff] HighShadow [0x24000000, 0x27ffffff] ShadowGap [0x20000000, > 0x23ffffff] LowShadow > > This is 0.5G total. So, I mmap all these three shadow subregions and > 'mprotect' the ShadowGap. > This is done at startup. If the mmap fails, an assert will fire. > I see. On embedded platforms...

...di << address is the paremeter to __asan_report_error_2 402ed8: e8 53 69 00 00 callq 409830 <__asan_report_error_2> << is_write and size is encoded in the function name --kcc > > > On 32-bit, the shadow region is: >> [0x28000000, 0x3fffffff] HighShadow [0x24000000, 0x27ffffff] ShadowGap [0x20000000, >> 0x23ffffff] LowShadow >> >> This is 0.5G total. So, I mmap all these three shadow subregions and >> 'mprotect' the ShadowGap. >> This is done at startup. If the mmap fails, an assert will fire. >> > &g...

...t_error_2 > 402ed8: e8 53 69 00 00 callq 409830 > <__asan_report_error_2> << is_write and size is encoded in the function > name > > > --kcc > > >> >> >> On 32-bit, the shadow region is: >>> [0x28000000, 0x3fffffff] HighShadow [0x24000000, 0x27ffffff] ShadowGap [0x20000000, >>> 0x23ffffff] LowShadow >>> >>> This is 0.5G total. So, I mmap all these three shadow subregions and >>> 'mprotect' the ShadowGap. >>> This is done at startup. If the mmap fails, an assert will fi...

...184==AddressSanitizer: failed to intercept '__isoc99_vsnprintf' ==29184==AddressSanitizer: failed to intercept '__isoc99_vfprintf' ==29184==AddressSanitizer: libc interceptors initialized || `[0x002000000000, 0x007fffffffff]` || HighMem || || `[0x001400000000, 0x001fffffffff]` || HighShadow || || `[0x001200000000, 0x0013ffffffff]` || ShadowGap || || `[0x001000000000, 0x0011ffffffff]` || LowShadow || || `[0x000000000000, 0x000fffffffff]` || LowMem || MemToShadow(shadow): 0x001200000000 0x00123fffffff 0x001280000000 0x0013ffffffff redzone=16 max_redzone=2048 quarantine_size=256M m...

...NS=debug=1,verbosity=1 LD_PRELOAD=libclang_rt.asan-arm-android.so LD_LIBRARY_PATH=. ./djpeg ./testimg.jpg" ==28210==Parsed ASAN_OPTIONS: debug=1,verbosity=1 ==28210==AddressSanitizer: libc interceptors initialized || `[0x20000000, 0xffffffff]` || HighMem || || `[0x04000000, 0x1fffffff]` || HighShadow || || `[0x00040000, 0x03ffffff]` || ShadowGap || MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 0 ==28210==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed...

...pointer -Os -g -Wl,-rpath,<path to sanitizers> -o hello hello.cpp This is the output from setting verbosity=1 - how can I debug this issue? ==3401806==AddressSanitizer: libc interceptors initialized || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || || `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap || || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || || `[0x000000000000, 0x00007fff7fff]` || LowMem || MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff redzone=16 max_redzone=2048 quarantine_size_mb=256M thre...

On 17 June 2011 08:55, Kostya Serebryany <kcc at google.com> wrote: > I am rather reluctant to add 'generic' code that handles unknown/untested > platforms because the memory mapping is very platform specific anyway. Indeed, but the point of that is more for helping writing platform-specific versions than actually using it as a general-purpose routine. Kinda documentation of

...-o hello hello.cpp >> >> This is the output from setting verbosity=1 - how can I debug this issue? >> >> ==3401806==AddressSanitizer: libc interceptors initialized >> || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || >> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || >> || `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap || >> || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || >> || `[0x000000000000, 0x00007fff7fff]` || LowMem || >> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff >> redzone=16...

On Fri, Jun 17, 2011 at 11:48 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 16 June 2011 20:57, Kostya Serebryany <kcc at google.com> wrote: > >> I see, maybe you could leave your C implementation as a fall back. > > > > Not easy, because it will require a fallback code in the run time > library. > > But yes, possible. > > I was

...LOAD=libclang_rt.asan-arm-android.so LD_LIBRARY_PATH=. ./djpeg > ./testimg.jpg" > > ==28210==Parsed ASAN_OPTIONS: debug=1,verbosity=1 > ==28210==AddressSanitizer: libc interceptors initialized > || `[0x20000000, 0xffffffff]` || HighMem || > || `[0x04000000, 0x1fffffff]` || HighShadow || > || `[0x00040000, 0x03ffffff]` || ShadowGap || > MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff > red_zone=16 > malloc_context_size=30 > SHADOW_SCALE: 3 > SHADOW_GRANULARITY: 8 > SHADOW_OFFSET: 0 > ==28210==Shadow memory range interleaves with an exist...

...rove stack error reports for large shadow granularity The following features don't work yet, but can be fixed: - i386/x86_64 assembly instrumentation. - Prelink support. The memory map with MidMem for this configuration is more complicated that that expected by compiler_rt. The current HighShadow would overlap with MidMem so would need to be adjusted. It's not clear to me that whether is an important feature? - Intra object overflow. This appears to be an experimental feature, and I have not ported the padding insertion for different granularity. Some features will not work as...

...can be fixed: > > - i386/x86_64 assembly instrumentation. > That's fine. It doesn't really work in regular mode either. > > - Prelink support. The memory map with MidMem for this configuration > is more complicated that that expected by compiler_rt. The current > HighShadow would overlap with MidMem so would need to be adjusted. > It's not clear to me that whether is an important feature? > you may safely ignore this for 32-bit granularity, but please keep it working in regular mode. > > - Intra object overflow. This appears to be an experimental...