<div dir="ltr">replied in cfe-dev<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 1:09 AM, ZhaoKang via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">Hello,<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">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.)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">However, when
using clang to compile our two cases with this option, one case error out with
following message:<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US">==31183==ERROR: AddressSanitizer <b><span style="color:red">failed to allocate 0x400000000</span></b> (17179869184) bytes
at address 67fff8000 (errno: 12)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US">==31183==<wbr>ReserveShadowMemoryRange failed
while trying to map 0x400000000 bytes. Perhaps you're using ulimit </span><span lang="EN-US" style="font-family:"Courier New"">–</span><span lang="EN-US">v<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">The other case
error out with following message:<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US">==30711==ERROR: AddressSanitizer: <b><span style="color:red">stack-buffer-overflow</span></b> on address 0x7fff8a931dcd at
pc 0x000000861eec bp 0x7fff8a9303f0 sp 0x7fff8a9303e8<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US">READ of size 1 at 0x7fff8a931dcd thread
T0<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> #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/<wbr>sprite/hls/BugSpray/crs/<wbr>810730/hscale/solution1/csim/<wbr>build/csim.exe+0x861eeb)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> #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/<wbr>sprite/hls/BugSpray/crs/<wbr>810730/hscale/solution1/csim/<wbr>build/csim.exe+0x7d717f)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> </span><span lang="EN-US" style="font-family:"Courier New"">…</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> #6 0x3099a1d9c3 in
__libc_start_main (/lib64/libc.so.6+<wbr>0x3099a1d9c3)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> #7 0x4c3648 in _start
(/wrk/xbj_vdi/fangqing/work/<wbr>sprite/hls/BugSpray/crs/<wbr>810730/hscale/solution1/csim/<wbr>build/csim.exe+0x4c3648)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US">Address 0x7fff8a931dcd is located in
stack of thread T0 at offset 1549 in frame<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> #0 0x78628f in
hscale_core(hls::stream<HSC_<wbr>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/<wbr>sprite/hls/BugSpray/crs/<wbr>810730/hscale/solution1/csim/<wbr>build/csim.exe+0x78628f)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US"> This frame has 215 object(s):<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.6pt"><span lang="EN-US">[32, 33)
'RegSmplsPerClk'<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.6pt"><span lang="EN-US">[48, 49)
'RegBitsPerCol'<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.6pt"><span lang="EN-US">[64, 66)
'TotalLines'<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.6pt"><span lang="EN-US" style="font-family:"Courier New"">…</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:15.75pt"><span lang="EN-US">[1552, 1553)
'ref.tmp65' <== Memory access at offset 1549 underflows this variable<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.0pt"><span lang="EN-US">[1568, 1569)
'ref.tmp68'<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.0pt"><span lang="EN-US" style="font-family:"Courier New"">…</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText" style="text-indent:21.0pt"><span lang="EN-US"> </span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">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.<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">From the error
message we can see AddressSanitizer need to allocate a very large memory (about
16G byte) from heap memory pool (1<sup>st</sup> case), or occupy large stack
memory and cause stack-buffer-overflow (2<sup>nd</sup> case). (ulimit </span><span lang="EN-US" style="font-family:"Courier New";color:#2f5597">–</span><span lang="EN-US" style="color:#2f5597">v shows unlimited)<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">So our question is
it is this feature</span><span lang="EN-US" style="font-family:"Courier New";color:#2f5597">’</span><span lang="EN-US" style="color:#2f5597">s shortcoming or
there is something wrong with our development environment?<u></u><u></u></span></p>
<p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">Thanks!</span></p><p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597"><br></span></p><p class="m_-3080594308066782666MsoPlainText"><span lang="EN-US" style="color:#2f5597">Kang </span></p><br><br><br><br><br><br><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>