ZhaoKang via llvm-dev
2016-Sep-08 08:09 UTC
[llvm-dev] Question about Clang/LLVM addresssanitizer
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
The other case error out with following message:
==30711==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff8a931dcd at pc 0x000000861eec bp 0x7fff8a9303f0 sp 0x7fff8a9303e8
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?
Thanks!
Kang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160908/dd9fa229/attachment.html>
Kostya Serebryany via llvm-dev
2016-Sep-08 21:50 UTC
[llvm-dev] Question about Clang/LLVM addresssanitizer
replied in cfe-dev On Thu, Sep 8, 2016 at 1:09 AM, ZhaoKang via llvm-dev < llvm-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 > > > > The other case error out with following message: > > ==30711==ERROR: AddressSanitizer: *stack-buffer-overflow* on address > 0x7fff8a931dcd at pc 0x000000861eec bp 0x7fff8a9303f0 sp 0x7fff8a9303e8 > > 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? > > Thanks! > > > Kang > > > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160908/ea5f3ad6/attachment.html>