In perl.git, the branch smoke-me/davem/asan_undef has been created
<http://perl5.git.perl.org/perl.git/commitdiff/ac94c0312342cb26b6bf78fbd24589edaae207c0?hp=0000000000000000000000000000000000000000>
at ac94c0312342cb26b6bf78fbd24589edaae207c0 (commit)
- Log -----------------------------------------------------------------
commit ac94c0312342cb26b6bf78fbd24589edaae207c0
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 02:21:17 2014 +0000
update customized.dat with local 'version' change
M t/porting/customized.dat
commit 03dba5a477969147a2f998be4047f8994752ea1c
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 02:13:24 2014 +0000
'version': vutil.c: silence overflow warnings
Running 'clang -fsanitize=undefined' on the perl test suite triggers
a number of warnings:
vutil.c:354:9: runtime error: signed integer overflow: 750283776 +
1705032704 cannot be represented in type 'int'
vutil.c:354:25: runtime error: signed integer overflow: 6 * 1000000000
cannot be represented in type 'int'
vutil.c:355:10: runtime error: signed integer overflow: 1000000000 * 10
cannot be represented in type 'int'
This is because the version string parsing code takes a "maybe overflow,
then check to see if we've overflown" approach. Which is perfectly fine,
but clashes with clang.
This commit makes it take the opposite approach of checking each time
*before* doing the += mult*i and mult*=10 steps.
A bit clunky, but ASan only allows you to disable these warnings on a
per-function basis, and it's a reasonably large function.
I suspect that the block of code above this may need similar treatment,
but as it wasn't triggering clang warnings, I didn't look at it.
M vutil.c
commit fbf3612bdc9fd5b00fab3ccc174c655ded964980
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 01:17:44 2014 +0000
Digest-SHA: avoid undefined warning
With 'clang -fsanitize=undefined', (~0 << gap) gives this warning:
src/sha.c:372:41: runtime error: left shift of negative value -1
Fix it by doing (~0U << gap) instead.
NB: this commit modifies a file which appears to be part of a separate
distribution, so may have licensing implications.
M cpan/Digest-SHA/src/sha.c
commit f91cba06220277e4992b300557868d0c5343f1c2
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 01:07:36 2014 +0000
Compress-Raw-Zlib: avoid undefined warning
With 'clang -fsanitize=undefined', when f==-1, ((f)<<1) gives this warning:
deflate.c:886:54: runtime error: left shift of negative value -1
Fix it by doing ((f)*2) instead. Any half-decent compiler should spot the
'*2' and implement it efficiently underneath as a shift or add or
whatever.
NB: this commit modifies a file which is part of a separate distribution,
libbzip2, so may have licensing implications.
M cpan/Compress-Raw-Zlib/zlib-src/deflate.c
commit 27bf8fb34b0458a4ebea6dd0d61f7b18f9d8d531
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 00:48:21 2014 +0000
Compress-Raw-Bzip2: avoid overflow warning
With 'clang -fsanitize=undefined', (1<<31) gives warnings like these:
blocksort.c:256:7: runtime error: left shift of 1 by 31 places cannot be
represented in type 'int'
Fix it by shifting an unsigned value instead: (1U<<31).
NB: this commit modifies a file which is part of a separate distribution,
libbzip2, so may have licensing implications.
M cpan/Compress-Raw-Bzip2/bzip2-src/blocksort.c
commit c57a9692726186bb58857b0177545184436e7c07
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 00:29:53 2014 +0000
Socket.xs: avoid integer overflow
As spotted by 'clang -fsanitize=undefined',
the shifting of the bytes to form an IPv4 address results in an
intermediate signed int, which clang detects as overflowing when <<24.
So ensure all the values to be shifted are unsigned.
Typical clang error:
Socket.xs:796:30: runtime error: left shift of 193 by 24 places cannot be
represented in type 'int'
M cpan/Socket/Socket.xs
commit 73c644459c09cc2b659f263433cfd23662834441
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 00:07:38 2014 +0000
List::Util: fix some integer overflows
both sum() and product() didn't handle integers near IV_MIN and IV_MAX
very well. Some of this was spotted by "clang -fsanitize=undefined",
the rest by visual code inspection.
Basically when adding or multiplying two signed IV together, and deciding
when to bail out and use NVs instead, there are more permutations to
consider than was being done. This meant that the bail tests sometimes
had undefined behaviour, and in the worst case, product(...,0,...)
actually raised a divide by zero exception in the bail test
M cpan/Scalar-List-Utils/ListUtil.xs
M cpan/Scalar-List-Utils/t/product.t
M cpan/Scalar-List-Utils/t/sum.t
commit 53cc065b7185396a808d77f9963210fa37f685b8
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 21:36:14 2014 +0000
Configure: silence ASan warnings
When run under -fsanitize=undefined, some of the try.c's that are compiled
and executed give runtime warnings. Since the intent of these particular
executables is to probe beyond certain limits in order to determine those
limits, these warnings can be safely ignored. So file them in /dev/null.
M Configure
commit e254264f062d90a11973e38214ceb6c023cdb69f
Author: David Mitchell <[email protected]>
Date: Tue Dec 23 10:38:01 2014 +0000
sv_vcatpvfn_flags() avoid array bounds err
clang -fsanitize=undefined is being a bit too clever for its own good
here.
The code looks something like
U8 vhex[VHEX_SIZE];
...
v = vhex + ...;
if (v < vend) ...
The code itself is safe, but ASan detects if you've added a value
greater than the buffer size to vhex and whines.
I've changed it so that the conditional comes first and is done in such
a way that arbitrary values can't be added to vhex.
To reproduce:
printf "%.1000a\n", 1;
gives
sv.c:12327:34: runtime error: index 1000 out of bounds for type 'U8
[17]'
M sv.c
commit 8812f6c03ce97dcb58e1135b347065f0dc79f833
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 20:57:52 2014 +0000
asan_ignore: exclude S_expect_number()
This function numifies the field width string in something like
printf "%10f". It handles integer overflow itself, so suppress
ASan warnings, e.g.
sv.c:10716:26: runtime error: signed integer overflow: 922337203 * 10
cannot be represented in type 'int'
M asan_ignore
commit 83485633a09cdc13d170de83e3c2d18cd8979a25
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 20:23:28 2014 +0000
fix integer overflow in S_study_chunk().
Don't increment delta if it's "infinity" (SSize_t_MAX)
Found by -fsanitize=undefined:
regcomp.c:4999:11: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'ssize_t' (aka 'long')
M regcomp.c
commit 270f4cbf1aeccc4239abe0b2db91ae6eb9d6dba8
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 20:12:22 2014 +0000
pack(): avoid << of negative values
Treat the string as U8* rather than char* when doing all the
bit shifts for uuencode. That stops these warnings under ASan:
pp_pack.c:1890:34: runtime error: left shift of negative value -127
pp_pack.c:1891:34: runtime error: left shift of negative value -126
pp_pack.c:1899:34: runtime error: left shift of negative value -1
pp_pack.c:1900:30: runtime error: left shift of negative value -31
M pp_pack.c
commit 088da250daa69cc5bfdcfb3ac20c5918e72b8eb2
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 20:04:59 2014 +0000
avoid integer overflow in pp_flop()
This;
@a=(0x7ffffffffffffffe..0x7fffffffffffffff);
could produce under ASan:
pp_ctl.c:1212:19: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'IV' (aka 'long')
so avoid post-incrementing the loop var on the last iteration.
This fix is more to shut ASan up than an actual bug, since the
bad value on the last iteration wouldn't actually be used.
M pp_ctl.c
commit 157a4efde2713393925cee1d5931abffb810a78e
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 16:25:59 2014 +0000
fix more -IV_MIN negations
Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN.
This occurs in several places in the perl sources.
These ones were found by visual code inspection rather than
using -fsanitize=undefined, but I've added extra tests so that
-fsanitize could find them now.
M pp.c
M sv.c
M t/op/64bitint.t
M t/opbasic/arith.t
commit ee051cebf181766d842a4165c315791f6d0f3636
Author: David Mitchell <[email protected]>
Date: Mon Dec 22 09:34:40 2014 +0000
fix undefined float behaviour in pack('f')
The C standard says that the value of the expression (float)double_var is
undefined if 'the value being converted is outside the range of values
that can be represented'.
So to shut up -fsanitize=undefined:
my $p = pack 'f', 1.36514538e67;
giving
runtime error: value 1.36515e+67 is outside the range of representable
values of type 'float'
explicitly handle the out of range values.
Something similar is already done under defined(VMS) && !defined(_IEEE_FP),
except that there it floors to +/- FLT_MAX rather than +/- (float)NV_INF.
I don't know which branch is best, and whether they should be merged.
This fix was suggested by Aaron Crane.
M pp_pack.c
commit c8a4d272042483065a4db55f12ab4ab5429947c9
Author: David Mitchell <[email protected]>
Date: Sun Dec 21 00:40:13 2014 +0000
avoid integer overflow in Perl_av_extend_guts()
There were two issues; first the 'overextend' algorithm (add a fifth of
the current size to the requested size) could overflow,
and secondly MEM_WRAP_CHECK_1() was being called with newmax+1,
which could overflow if newmax happened to equal SSize_t_MAX.
e.g.
$a[0x7fffffffffffffff] = 1
$a[5] = 1; $a[0x7fffffffffffffff] = 1
could produce under ASan:
av.c:133:16: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'long'
av.c:170:7: runtime error: signed integer overflow: 9223372036854775807
+ 1 cannot be represented in type 'long'
M av.c
commit af4af4019d61b6c1b4f1911844e2b6d95eef0460
Author: David Mitchell <[email protected]>
Date: Sun Dec 21 00:00:10 2014 +0000
asan_ignore: exclude Perl_pp_left_shift()
<< in perl maps directly to << in C, so don't warn about it when the RHS
is too big.
Fixes e.g.:
print 1 << 64
use integer; print 1 << 63
Typical ASan warning:
pp.c:1893:2: runtime error: left shift of 1 by 63 places cannot be
represented in type 'IV' (aka 'long')
M asan_ignore
commit 56b3bef8bcfeed0740b1513775b2d58ea2949d4c
Author: David Mitchell <[email protected]>
Date: Sat Dec 20 16:40:52 2014 +0000
fix -IV_MIN negations
Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN.
This occurs in several places in the perl sources.
Found by -fsanitize=undefined.
Here's a typical message:
sv.c:2864:7: runtime error: negation of -9223372036854775808 cannot be
represented in type 'IV' (aka 'long'); cast to an unsigned type to negate this
value to itself
M pp.c
M pp_hot.c
M sv.c
commit 400a6b9299a7004752bc39bed5fe842f186f6d35
Author: David Mitchell <[email protected]>
Date: Sat Dec 20 15:30:01 2014 +0000
fix integer overflow in S_study_chunk().
It was calculating final_minlen + delta even when delta was already
SSize_t_MAX and final_minlen > 0.
This triggered it: /a(??{}){2}/.
Found by -fsanitize=undefined:
regcomp.c:5623:89: runtime error: signed integer overflow: 1 +
9223372036854775807 cannot be represented in type 'long'
M regcomp.c
-----------------------------------------------------------------------
--
Perl5 Master Repository
