| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
erts/emulator/hipe/hipe_bif0.c
|
|
Reset p->htop in the oversize bignum error case to avoid leaving a
hole in the heap, which would crash the debug emulator.
|
|
Bignums are artifically restricted in size. Arithmetic and logical
operations check the sizes of resulting bignums, and turn oversize
results into system_limit exceptions.
However, this check is not performed when bignums are constructed by
binary matching. The consequence is that such matchings can construct
oversize bignums that satisfy is_integer/1 yet don't work. Performing
arithmetic such as Term - 0 fails with a system_limit exception. Worse,
performing a logical operation such as Term band Term results in [].
The latter occurs because the size checking (e.g. in erts_band()) is
a simple ASSERT(is_not_nil(...)) on the result of the bignum operation,
which internally is [] (NIL) in the case of oversize results. However,
ASSERT is a no-op in release builds, so the error goes unnoticed and []
is returned as the result of the band/2.
This patch addresses this by preventing oversize bignums from entering
the VM via binary matching:
- the internal bytes_to_big() procedure is augmented to return NIL for
oversize results, just like big_norm()
- callers of bytes_to_big() are augmented to check for NIL returns and
signal errors in those cases
- erts_bs_get_integer_2() can only fail with badmatch, so that is the
Erlang-level result of oversize bignums from binary matches
- big_SUITE.erl is extended with a test case that fails without this
fix (no error signalled) and passes with it (badmatch occurs)
Credit goes to Nico Kruber for the initial bug report.
|
|
except the reference counter 'refc', as different callers
have different strategies regarding the lifetime of the binary.
|
|
Found by valgrind. Probably safe on opt-VM due to CHICKEN_PAD.
|
|
|
|
Valgrind complained that erts_cmp_bits sometimes read one byte too much
from bitstrings. The byte was never used and the invalid read is safe
in opt-VM due to padding in binary allocation (CHICKED_PAD).
|
|
This complements 933e701 (OTP-10209). Without this patch the test cases
"in_guard/1" and "coerce_to_float/1" in bs_construct_SUITE fail.
The added lines in bs_construct_SUITE cover all branches that were not
covered before (small and big numbers if BIT_OFFSET(erts_bin_offset) != 0).
|
|
This complements 933e701 (OTP-10209). Without this patch the test case
"bs_match_misc_SUITE:t_float/1" fails.
Simple error example:
1> <<_,_,_,_,_,_,_,_>> = <<1.25/float>>.
<<63,244,0,0,0,0,0,0>>
2> <<1.25/float>> = <<63,244,0,0,0,0,0,0>>.
** exception error: no match of right hand side value <<63,244,0,0,0,0,0,0>>
The additional test case is added because in a former version of this
patch the ERTS_FP_ERROR_THOROUGH check for NaN/infinity was mistakenly
applied on the still word-switched double.
|
|
Code such as the following should cause an exception:
Bin = <<0:1>>,
<<Bin/binary,...>>
(Because the "binary" type implies that the binary must have a
size in bits that is a multiple of 8.)
Depending on the binary, either no exception was thrown or the
wrong exception was thrown (because c_p->freason was not set).
Noticed-by: Adam Rutkowski
|
|
|
|
On some ARMs (and maybe other platforms), doubles are stored with the
the two 32-bit words reversed with respect to more common
architectures.
The symptom is this:
> io_lib:write(1.0).
"0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005299808824"
Detect that and account for it when decoding floats.
|
|
The two noncharacter code points 16#FFFE and 16#FFFF were not
allowed to be encoded or decoded using the unicode module or
bit syntax. That causes an inconsistency, since the noncharacters
16#FDD0 to 16#FDEF could be encoded/decoded.
There is two ways to fix that inconsistency.
We have chosen to allow 16#FFFE and 16#FFFF to be encoded and
decoded, because the noncharacters could be useful internally
within an application and it will make encoding and decoding
slightly faster.
Reported-by: Alisdair Sullivan
|
|
All uses of the old deprecated atomic API in the runtime system
have been replaced with the use of the new atomic API. In a lot of
places this change imply a relaxation of memory barriers used.
|
|
|
|
|
|
<<A:0>> will always produce an empty binary, regardless of the
type of A. The bug is in the run-time system. Fix it so that a
non-numeric value for A will cause a badarg exception.
Reported-by: Zvi
|
|
This will reduce the risk of integer wrapping in bin vheap counting.
The vheap size series will now use the golden ratio instead of doubling
and fibonacci sequences.
OTP #8730
|
|
Merging the three off-heap lists (binaries, funs and externals) into
one list. This reduces memory consumption by two words (pointers) per
ETS object.
|
|
* pan/otp_8332_halfword:
Teach testcase in driver_suite the new prototype for driver_async
wx: Correct usage of driver callbacks from wx thread
Adopt the new (R13B04) Nif functionality to the halfword codebase
Support monitoring and demonitoring from driver threads
Fix further test-suite problems
Correct the VM to work for more test suites
Teach {wordsize,internal|external} to system_info/1
Make tracing and distribution work
Turn on instruction packing in the loader and virtual machine
Add the BeamInstr data type for loaded BEAM code
Fix the BEAM dissambler for the half-word emulator
Store pointers to heap data in 32-bit words
Add a custom mmap wrapper to force heaps into the lower address range
Fit all heap data into the 32-bit address range
|
|
Store Erlang terms in 32-bit entities on the heap, expanding the
pointers to 64-bit when needed. This works because all terms are stored
on addresses in the 32-bit address range (the 32 most significant bits
of pointers to term data are always 0).
Introduce a new datatype called UWord (along with its companion SWord),
which is an integer having the exact same size as the machine word
(a void *), but might be larger than Eterm/Uint.
Store code as machine words, as the instructions are pointers to
executable code which might reside outside the 32-bit address range.
Continuation pointers are stored on the 32-bit stack and hence must
point to addresses in the low range, which means that loaded beam code
much be placed in the low 32-bit address range (but, as said earlier,
the instructions themselves are full words).
No Erlang term data can be stored on C stacks (enforced by an
earlier commit).
This version gives a prompt, but test cases still fail (and dump core).
The loader (and emulator loop) has instruction packing disabled.
The main issues has been in rewriting loader and actual virtual
machine. Subsystems (like distribution) does not work yet.
|
|
|
