| Age | Commit message (Collapse) | Author |
|---|
|
The test case tests that the bs_append instruction tests for overflow.
Make that clear by renaming the test case.
While at it, also add a few explicit garbage_collection/0 calls to
make it more likeley to run successfully in tight memory situations.
|
|
This test case can fail for the wrong reason (swapping
followed by a timetrap timeout). It is unlikely to fail because
of a real bug.
|
|
|
|
|
|
* john/erts/fix-binary-append-syslimit/OTP-14524:
Check for overflow when appending binaries, and error out with system_limit
# Conflicts:
# erts/emulator/test/bs_construct_SUITE.erl
|
|
This fixes the following bug:
A = <<0:((1 bsl 32)-8)>>,
B = <<2, 3>>.
B =:= <<A/binary,1,B/binary>>. %% Evaluated to true...
|
|
|
|
c062dfc485a added timetraps to test suites that had no timetraps.
Some of added timetraps are only 5 or 10 seconds, which is can be
too short time on some slow computers. Change those times to one
or two minutes.
|
|
free_mem/0 returned the number of free Kb, but the caller
assumed that it was in Mb.
Also add another clause to further scale down the size of
the binaries created.
|
|
* lukas/erts/testfixes-19:
erts: Increase bif and nif call_time trace test
erts: Fix distribution_SUITE:bulk_send_bigbig on windows
erts: Ensure bs_add_overflow test has enough memory
kernel: Better explain controlling_process' tcp behaviour
kernel: Fix t_recv_delim on bsd
os_mon: Make sure to start/stop os_mon in tests correctly
ssl: Fix use_interface dist_SSL test
erl_interface: Fix signed int overflow tc bug
erts: fix atom_roundtrip_r15b tc
erts: Require more memory for debug tests
|
|
|
|
* Previous free_mem calculation did not work on all platforms
* Increase test timeout for bs_construct_SUITE:huge_binary/1
|
|
|
|
|
|
|
|
Those clause are obsolete and never used by common_test.
|
|
|
|
|
|
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
Also, some of the branches were testing sizes in bits against a constant
?MAX_BINSIZE, which was in bytes. The signed comparisons masked this
mistake. These branches have been removed since all sizes in bits that
fit in a machine word are valid binary sizes.
Finally, a test that reproduces the issue was added to bs_construct,
along with a test for one of the cases (bs_init<0>(...)) when the test
against ?MAX_BINSIZE must be changed to unsigned rather than removed.
|
|
The test whether the result would fit in a smallnum could overflow into
a negative number that would fit a smallnum. A test that reproduces the
issue was added to bs_construct_SUITE.
|
|
huge_binary/1 did not consider that the Shift variable is not a
constant, and misses the case of a literal size.
|
|
|
|
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).
|
|
* sverk/bs_construct_SUITE-outofmem:
erts: Limit memory usage of bs_construct_SUITE:huge_binary
|
|
depending on the amount of free memory on the host
|
|
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
|
|
|
|
|
|
Constructing binaries using the bit syntax with literals sizes
that would not fit in an Uint will either cause an emulator crash
or the loading to be aborted.
Use the new TAG_o tag introduced in the previous commit to make sure
that the attempt to create huge binary literals will generate a
system_limit exception at run-time.
|
|
Attempting to construct <<0:((1 bsl 32)-1)>>, the largest bitstring
allowed in a 32 bit emulator, would cause an emulator crash because
of integer overflow.
Fix the problem by using an Uint64 to avoid integer overflow.
Do not attempt to handle construction of <<0:((1 bsl 64)-1>> in
a 64-bit emulator, because that will certainly cause the emulator
to terminate anyway because of insufficient memory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<<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
|
|
|
