<div dir="ltr">2 questions: <div>- Do you see this with the fresh llvm trunk? </div><div>- Can you prepare a minimized example? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 6:18 PM, Greg Stark 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">I'm struggling to explain an ASAN report I'm now getting that I didn't<br>
get previously on the same code. In fact the report only happens with<br>
-O2 and not when I remove the -O flags which makes it hard to debug<br>
and makes me suspect it's dependent on exactly which instructions the<br>
code generation decides to access the bytes involved. Afaict the C<br>
code shouldn't be accessing the poisoned bytes.<br>
<br>
The report looks like:<br>
<br>
init_var_from_num: NUMERIC (short) w=0 d=1 POS 6 bytes: 18 00 00 00 80 80<br>
=================================================================<br>
==28714==ERROR: AddressSanitizer: unknown-crash on address<br>
0x62900003d7ac at pc 0x00000144a6d6 bp 0x7ffed6680db0 sp<br>
0x7ffed6680da8<br>
READ of size 4 at 0x62900003d7ac thread T0<br>
    #0 0x144a6d5 in init_var_from_num<br>
/home/stark/src/pg/postgresql-master/src/backend/utils/adt/numeric.c:4764:17<br>
...<br>
SUMMARY: AddressSanitizer: unknown-crash<br>
/home/stark/src/pg/postgresql-master/src/backend/utils/adt/numeric.c:4764:17<br>
in init_var_from_num<br>
Shadow bytes around the buggy address:<br>
...<br>
=>0x0c527ffffaf0: f7 f7 00 00 f7[06]00 00 f7 00 00 00 00 f7 00 00<br>
<br>
<br>
The "18 00 00 00 80 80" is a hex dump of the bytes in the 6-byte<br>
object. The preceding and following bytes were poisoned explicitly by<br>
my code which agrees with the shadow bytes listed.<br>
<br>
It looks like asan is complaining that the code is doing a 4-byte read<br>
of the last 2 bytes of the object. But in fact the code is accessing<br>
those last two bytes through a 2-byte short which an expression that<br>
looks like (n)->choice.n_short.n_header with the structure and union<br>
looking like these:<br>
<br>
struct NumericData<br>
{<br>
    int32 vl_len_; /* varlena header (do not touch directly!) */<br>
    union NumericChoice choice; /* choice of format */<br>
};<br>
<br>
union NumericChoice<br>
{<br>
    uint16 n_header; /* Header word */<br>
    struct NumericLong n_long; /* Long form (4-byte header) */<br>
    struct NumericShort n_short; /* Short form (2-byte header) */<br>
};<br>
<br>
struct NumericShort<br>
{<br>
    uint16 n_header; /* Sign + display scale + weight */<br>
    NumericDigit n_data[FLEXIBLE_ARRAY_MEMBER]; /* Digits */<br>
};<br>
<br>
struct NumericLong<br>
{<br>
    uint16 n_sign_dscale; /* Sign + display scale */<br>
    int16 n_weight; /* Weight of 1st digit */<br>
    NumericDigit n_data[FLEXIBLE_ARRAY_MEMBER]; /* Digits */<br>
};<br>
<br>
<br>
So it looks to me like -O2 is causing the optimizer to turn the 2-byte<br>
read into a 4-byte read and overrun the allocated object. But I<br>
haven't tried looking at the assembly yet.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
greg<br>
_______________________________________________<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/mailman/listinfo/llvm-dev</a><br>
</font></span></blockquote></div><br></div>