[cfe-dev] Question about Clang/LLVM addresssanitizer

Kostya Serebryany via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 8 14:50:03 PDT 2016


On Thu, Sep 8, 2016 at 1:09 AM, ZhaoKang via cfe-dev <cfe-dev at lists.llvm.org
> wrote:

> Hello,
>
>
>
> We have one question about the clang compiler option: -fsanitize=address.
> (We want to use the feature to detect potential bug in out c++ design.)
>
> However, when using clang to compile our two cases with this option, one
> case error out with following message:
>
>
>
> ==31183==ERROR: AddressSanitizer *failed to allocate 0x400000000*
> (17179869184) bytes at address 67fff8000 (errno: 12)
>
> ==31183==ReserveShadowMemoryRange failed while trying to map 0x400000000
> bytes. Perhaps you're using ulimit –v
>

This happens at startup right?
something causes asan to fail to allocate the shadow.

please send the output of
   ASAN_OPTIONS=verbosity=1 ./your-binary

or, better, send the reproducer.


>
>
> The other case error out with following message:
>
> ==30711==ERROR: AddressSanitizer: *stack-buffer-overflow* on address
> 0x7fff8a931dcd at pc 0x000000861eec bp 0x7fff8a9303f0 sp 0x7fff8a9303e8
>

that smells like a real bug in your code.


> READ of size 1 at 0x7fff8a931dcd thread T0
>
>     #0 0x861eeb in ap_private<8, false, true>::RType<32, true>::mult
> ap_private<8, false, true>::operator*<32, true>(ap_private<32, true,
> (32)<=(64)> const&) const (/wrk/xbj_vdi/fangqing/work/
> sprite/hls/BugSpray/crs/810730/hscale/solution1/csim/
> build/csim.exe+0x861eeb)
>
>     #1 0x7d717f in ap_private<8, false, (8)<=(64)>::RType<32, true>::mult
> operator*<8, false>(ap_private<8, false, (8)<=(64)> const&, int)
> (/wrk/xbj_vdi/fangqing/work/sprite/hls/BugSpray/crs/
> 810730/hscale/solution1/csim/build/csim.exe+0x7d717f)
>
>>
>     #6 0x3099a1d9c3 in __libc_start_main (/lib64/libc.so.6+0x3099a1d9c3)
>
>     #7 0x4c3648 in _start (/wrk/xbj_vdi/fangqing/work/
> sprite/hls/BugSpray/crs/810730/hscale/solution1/csim/
> build/csim.exe+0x4c3648)
>
>
>
> Address 0x7fff8a931dcd is located in stack of thread T0 at offset 1549 in
> frame
>
>     #0 0x78628f in hscale_core(hls::stream<HSC_MPIX_STRUCT>&, ap_uint<4>,
> ap_uint<16>, ap_uint<16>, ap_uint<16>, ap_uint<32>, ap_uint<2>, ap_int<16>
> (*) [8], hls::stream<HSC_MPIX_STRUCT>&) (/wrk/xbj_vdi/fangqing/work/
> sprite/hls/BugSpray/crs/810730/hscale/solution1/csim/
> build/csim.exe+0x78628f)
>
>
>
>   This frame has 215 object(s):
>
> [32, 33) 'RegSmplsPerClk'
>
> [48, 49) 'RegBitsPerCol'
>
> [64, 66) 'TotalLines'
>
>>
> [1552, 1553) 'ref.tmp65' <== Memory access at offset 1549 underflows this
> variable
>
> [1568, 1569) 'ref.tmp68'
>
>>
>
>
> Both of them can be compiled successfully and run correctly when compiled
> with clang without this addrsanitizer option. However both of them failed
> when add this option.
>
> From the error message we can see AddressSanitizer need to allocate a very
> large memory (about 16G byte) from heap memory pool (1st case), or occupy
> large stack memory and cause stack-buffer-overflow (2nd case). (ulimit –v
> shows unlimited)
>
> So our question is it is this feature’s shortcoming or there is something
> wrong with our development environment?
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160908/065a7089/attachment-0001.html>


More information about the cfe-dev mailing list