| Age | Commit message (Collapse) | Author |
|---|
|
* bjorn/hipe/fix-race-condition:
Delay patching of closures to eliminate a race condition
hipe: Break apart hipe_bif:make_fe/3 into two BIFs
|
|
* hb/stdlib/qlc_fix/OTP-11758:
Fix a qlc bug where filters were erroneously optimized away
|
|
* ia/ssl/proplist-input-check/OTP-11760:
ssl: Add input sanity check
|
|
Avoid puzzling behavior due to options being disregarded if they
are not key value tuples.
|
|
* ia/ssl/doc-imp/OTP-11759:
ssl: Improved documentation of the cacertfile option
|
|
|
|
* egil/fix-maps-eq:
erts: Fix Map cmp exact equal of an empty map
|
|
* egil/fix-compiler-error-msg:
compiler: Fix error message printout on compile error
|
|
Thanks to Sam Bobroff for reporting the bug.
|
|
Use correct stack in printout.
|
|
The loader of native code tries to avoid race condition by bringing
down the system to a single scheduler. Unfortunately, that will not
completely avoid race conditions beacuse other processes may still
run while the code is being loaded. Therefore, we must still make
sure that native code has been fully fixed up before it can be
executed.
Under unlucky circumstances, it was possible for the global name
register process to call a fun in native code before the native
code for the fun had been fully fixed up. The run-time system
would crash when running the not-fully-fixed-up code.
Here is a way to make the bug 100% reproducible. First add this
function to the 'global' module:
silly_looper(List) ->
lists:foreach(fun(E) -> put(any_atom, E) end, List),
silly_looper(List).
Then insert the following code at the beginning of the init/1
function in the 'global' module:
spawn_link(fun() -> silly_looper(lists:seq(1, 100)) end),
The run-time system will crash during start up when the native
code for the 'global' module is being loaded. What will happen
is that lists:foreach/2 (which runs in native code) will call
the native code for the fun in silly_looper/1 before the reference
to 'any_atom' has been changed from a 0 to the proper tagged
atom value. The put/2 BIF will exit when attempting to calculate
the hash value for the illegal value 0 (it is not properly tagged).
To eliminate this race condition, we must delay patching the
native code addresses for a fun into the fun entry until the native
code has been fully fixed up. We will use the new BIFs introduced
in the previous commit.
While we are at it, we will also make sure that we erase any
temporary variables in the process dictionary used by the
hipe_unified_loader module.
|
|
This commit is a preparation for eliminating a race condition
loading the native code for modules whose BEAM code has already
been loaded. Here we introduce two new BIFs so that looking up
a fun entry is separate from setting the native address in the
fun entry.
|
|
The expression,
#{} =:= M
where M was any Map, would always result in 'true'.
This commit fixes this issue by first comparing sizes for
both terms and then checking for size zero.
|
|
* rickard/xcomp-readme:
Let xcomp/README.md refer to HOWTO/INSTALL-CROSS.md
|
|
* bjorn/erts/fp-exceptions-on-osx:
Disable accidentally enabled floating point exceptions on MacOS X
|
|
|
|
|
|
In c7ddafbe, which disabled floating point exceptions on Linux,
floating point exceptions were accidentally enabled on MacOS X.
|
|
|
|
|
|
* ia/ssl/fix-warnings:
ssl: Fix compiler warnings
ssl: Fix appup regexps and instructions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* sverk/hipe-disable-gc-bug:
erts: Fix heap overwrite by hipe "trap frames" when GC is disabled
ASSERT that GC is not tried with "need" when GC is disabled
|
|
by trapping BIFs like term_to_binary and binary_to_term.
|
|
* ia/ssl/prepare-for-release:
ssl: Prepare for release
|
|
|
|
* kostis/hipe-tests-bs/OTP-11748:
Up the time limit (globally) for some slow machines
Add check so that tests are skipped if HiPE is not available
Add a Makefile for the HiPE tests
Add tests for the HiPE compiler (Part 1: binaries and bitstrings)
|
|
* hb/syntax_tools/correct_igor_contract:
Correct a contract in the igor module
|
|
Thanks Kostis.
|
|
|
|
* anders/diameter/grouped_decode/OTP-11675:
Be lenient with the M-bit in Grouped AVPs
|
|
|
|
RFC 6733 says this, in 4.4:
Receivers of a Grouped AVP that does not have the 'M' (mandatory) bit
set and one or more of the encapsulated AVPs within the group has the
'M' (mandatory) bit set MAY simply be ignored if the Grouped AVP itself
is unrecognized. The rule applies even if the encapsulated AVP with its
'M' (mandatory) bit set is further encapsulated within other sub-groups,
i.e., other Grouped AVPs embedded within the Grouped AVP.
The first sentence is mangled but take it to mean this:
An unrecognized AVP of type Grouped that does not set the 'M' bit MAY
be ignored even if one of its encapsulated AVPs sets the 'M' bit.
This is a bit of a non-statement since if the AVP is unrecognized then
its type is unknown. We therefore don't know that its data bytes contain
encapsulated AVPs, so can't but ignore any of those that set the M-bit.
Doing anything else when the type *is* known would be inconsistent.
OTP-11087 (commit 066544fa) caused the M-bit on any unrecognized AVP to
be regarded as an error, unrecognized being taken to mean "not
explicitly defined as a member of its container". (That is, an AVP that
can't be packed into a dedicated record field, which is slightly
stronger than "not defined".) This fixed the original intention for
top-level AVPs but broke the required leniency for Grouped AVPs whose
type is known. This commit restores the leniency.
Note that dictionary files need to be recompiled for the commit to have
effect.
Thanks to Rory McKeown for reporting the problem.
|
|
* rickard/otp_version/OTP-11615:
Update OTP version documentation
|
|
|
|
|
|
|
|
* lukas/erts/float_encoding/OTP-11738:
erts: Set default external enc to use new float scheme
|
|
|
|
|
|
|
|
* bjorn/gs/warnings:
gs: Turn compiler warnings into errors
gs: Eliminate a compiler warning
|
|
Create tests for the HiPE native code compiler. This is the first
part of the effort and contains tests that check that the native
code produced by the HiPE compiler for binaries and bitstrings is
OK and behaves similarly to the code produced by the BEAM compiler.
|
