| Age | Commit message (Collapse) | Author |
|---|
|
* ia/pr/778:
snmp: Prepare for release
Snmp agent vacmViewTreeFamily with non 'null' mask bugfix
|
|
The run-time system would terminate if code:load_abs/1 was
called with a filename containing any non-latin1 characters.
The reason is that code_server would attempt to construct a
module name from the filename using list_to_atom/1 and that
atoms currently are limited to the latin1 character set.
But how should the error be reported?
I have decided to that the simplest and least confusing way
is to move the call to list_to_atom/1 to 'code' module and
let it crash the calling process. The resulting stack back
trace will make it clear what the reason for the crash was.
|
|
As long as it is not prioritized to make an snmp_upgrade_SUITE it is
not worth trying to do anything but restart_application
|
|
* ia/ssl/test-alpn-cuddle:
ssl: Fix typos that broke alpn tests
|
|
* ia/ssl/hs-timing/OTP-13253:
ssl: Prepare for release
ssl: Fix timing releated bug
|
|
* siri/cover/nofile/OTP-13200:
[cover] Don't crash when compiling beam without 'file' attribute
[cover] Simplify module cc in cover test to avoid confusion
|
|
|
|
When a constrained INTEGER has more than 16536 values and named
values, the compiler would crash when compiling to the PER
format. Example:
Longitude ::= INTEGER {
oneMicrodegreeEast(10),
oneMicrodegreeWest(-10),
unavailable(1800000001)
} (-1799999999..1800000001)
Reported-by: Ingars
|
|
Adresses problems desciribed in
http://erlang.org/pipermail/erlang-bugs/2015-April/004891.html
http://erlang.org/pipermail/erlang-patches/2015-April/004766.html
The original patch also suggested the following fix.
However we need more information to be able to understand if
this is correct or not, and it does not have priority at the moment
for us to investigate.
@@ -816,7 +816,7 @@ next_node(D, {tree, Tree, {table_entry, _MibName}},
"~n RevOidSoFar: ~p"
"~n MibView: ~p", [size(Tree), Oid, RevOidSoFar, MibView]),
OidSoFar = lists:reverse(RevOidSoFar),
- case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of
+ case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar ++ Oid, MibView) of
true ->
?vdebug("next_node(tree,table_entry) -> not in mib view",[]),
false;
|
|
|
|
|
|
* ia/ssl/version_support_check:
ssl: In interop tests always check if SSL/TLS version is supported by OpenSSL
|
|
As sslv3 is being faced out we need to test for old version support as well as
newer versions.
|
|
The new time warp safe option is safe_fixed_monotonic_time which
gives erlang:monotonic_time().
The safe_fixed option was also slightly changed. It now gives
erlang:timestamp() instead of erlang:now(). This has however
not been documented, so it is considered a compatible change.
The above effects both ets, and dets.
This commit also include the bugfix OTP-13239 for
dets:info(Tab, safe_fixed). The timestamp in the result returned
by dets:info(Tab, safe_fixed) was unintentionally broken as a
result of the time API rewrites in OTP 18.0.
|
|
New timestamp options for trace, sequential trace, and
system profile:
- monotonic_timestamp
- strict_monotonic_timestamp
|
|
OTP-13249
* sverk/crypto-aec-ecb-multiblock:
crypto: Fix bug for multiple blocks for AES-ECB
|
|
|
|
|
|
|
|
* egil/improve-map-cerl-prettypr/OTP-13238:
compiler, hipe: Fix pretty printing of Core Maps
hipe: Fix map pretty printing of pairs
dialyzer: Update Maps tests
|
|
Bug reported by Josemic. See also ERL-63.
|
|
Correction of commit d57f5e.
|
|
|
|
Literal maps could cause dialyzer to crash when pretty printing the results.
Reported-by: Chris McGrath <[email protected]>
|
|
In commit f667931e2905797ffab63e224e56eaf07f77178a the core format changed
for map pairs. Let dialyzer and hipe pretty printing of maps also adhere to
those changes.
An Erlang map update, M#{foo := 1, bar => 2} will now be printed as:
~{ 'foo' := 1, 'bar' => 2 | M }~
|
|
|
|
The module is deprected and will be removed in OTP 19. The reason is
that the module is not used, and that we se no obvious use case for
it.
|
|
* bjorn/compiler/map-bug/OTP-13231:
Fix crash when attempting to update a fun as if it were a map
|
|
The Erlang Code Linter no longer crashes if there is a -deprecated()
attribute but no -module() declaration.
See also ERL-62 at bugs.erlang.org.
|
|
See also ERL-32 at bugs.erlang.org. Thanks to Ben Paxton.
|
|
Use erlang:unique_integer/1 instead of erlang:now/0 to generate a
unique node name.
Use rand:uniform/1 instead of random:uniform/1, so we don't need to
generate a seed ourselves.
|
|
Allow adding extra options for outgoing TLS distribution connnections,
as supported for plain TCP connections.
|
|
The following example would cause an internal consistency
failure in the compiler:
f() -> ok.
update() -> (fun f/0)#{u => 42}.
The reason is that internally, v3_core will (incorrectly)
rewrite update/0 to code similar to this:
update() ->
if
is_map(fun f/0) ->
maps:update(u, 42, fun f/0)
end.
Since funs are not allowed to be created in guards, incorrect and
unsafe code would be generated.
It is easy to fix the bug. There already is a is_valid_map_src/1
function in v3_core that tests whether the argument for the map update
operation can possibly be a valid map. A fun is represented as a
variable with a special name in Core Erlang, so it would not be
recognized as unsafe. All we'll need to do to fix the bug is to look
closer at variables to ensure they don't represent funs. That will
ensure that the code is rewritten in the correct way:
update() ->
error({badmap,fun f/0})
end.
Reported-by: Thomas Arts
|
|
|
|
If a behaviour module contains an non-exported function with the same name as
one of the behaviour's callbacks, the callback info was inadvertently deleted
from the PLT as the dialyzer_plt:delete_list/2 function was cleaning up the
callback table. This bug was reported by Brujo Benavides.
Fixes ERL-72 bug report.
|
|
|
|
Dialyzer used to report unknown behaviours in the same way as unknown
functions and types. This functionality has been removed in d101155, but
some code remained.
|
|
The following code would crash v3_codegen:
order(From) ->
catch
if
From#{[] => sufficient} ->
saint
end.
Before explaining the crash, first some background on the stack
frame and the Y registers.
Certain instructions, most notably the 'call' instructions, clobber
all X registers. Before any such instruction, all X registers that
have values that will be used after the call must be saved to Y
registers (i.e. to the stack frame). adjust_stack/4 will be called
when X registers must be saved.
There is also another situation when X registers must be saved, namely
within a 'catch' if we are about to execute any instruction that may
cause an exception. Examples of such instructions are some guard BIFs
(such as length/1) and construction of binaries or maps. Within a
'catch', X registers must be be saved because if an exception is
thrown and catched all X registers will be destroyed. The same
adjust_stack/4 function will be called for those instructions, but
only if they occur within a 'catch'.
There is actually one more complication. If there is code in
a guard within a catch, the X registers should not be saved, because
the code in a guard never clobbers any X registers that were alive
before the guard code was entered. v3_codegen is written with the
implicit assumption that code in guards never cause anything
to be saved to Y registers.
The code for building maps and binaries would incorrectly save X
registers within a guard inside a 'catch'.
For construction of binaries, that would mean that a useless but
harmelss 'move' instruction was generated.
But for construction of maps, the saving of the Y register would not
be harmless. There would be a crash when attempting to merge #sr{}
records. #sr{} records keeps track of the contents of X and Y
registers. When two separate code paths are joined (e.g. at the end of
'case' statement), the register descriptors must be reconciled.
Basically, the register descriptors for both paths must be identical.
The #sr{} record for one path must not claim that {y,0} contains
a certain value, while another path claims that {y,0} is dead.
Thus, the crash occurs in sr_merge/2 when failing to reconcile the
Y registers.
To fix this bug this bug we will introduce a new function called
maybe_adjust_stack/5. It will save X registers on the stack only
if the code is inside a catch but not inside a guard. We will
change all existing code to use this new function when appropriate.
Reported-by: Thomas Arts
|
|
|
|
|
|
|
|
|
|
* bjorn/compiler/beam_bool/OTP-13208:
beam_bool: Fix unsafe optimization
|
|
beam_bool would make the following code unsafe (which would be
reported by beam_validator):
scotland(Echo) ->
found(case Echo of
Echo when true; Echo, Echo, Echo ->
Echo;
echo ->
[]
end,
Echo = placed).
found(_, _) -> million.
Basically, beam_bool would see that the 'case' would always return
the value of Echo. Thus:
scotland(Echo) ->
found(Echo, Echo = placed).
The only problem is that beam_bool would also remove a 'move'
instruction that would save Echo to the stack. Here is the
assembly code for part of the function:
{allocate_zero,1,1}.
{move,{x,0},{y,0}}. %% Save Echo on stack.
{bif,'=:=',{f,7},[{x,0},{atom,true}],{x,1}}.
{bif,'=:=',{f,7},[{x,0},{atom,true}],{x,2}}.
{bif,'=:=',{f,7},[{x,0},{atom,true}],{x,3}}.
{bif,'and',{f,7},[{x,2},{x,3}],{x,2}}.
{bif,'and',{f,7},[{x,1},{x,2}],{x,1}}.
{jump,{f,8}}.
{label,7}.
{move,{atom,false},{x,1}}.
{label,8}.
{bif,'or',{f,6},[{atom,true},{x,1}],{x,1}}.
{test,is_eq_exact,{f,6},[{x,1},{atom,true}]}. %% Jump never taken.
{jump,{f,5}}.
{label,6}.
{test,is_eq_exact,{f,9},[{x,0},{atom,echo}]}.
{move,nil,{x,0}}.
{jump,{f,5}}.
{label,9}.
{test_heap,3,0}.
{put_tuple,2,{x,0}}.
{put,{atom,case_clause}}.
{put,{y,0}}.
{line,[{location,"t.erl",5}]}.
{call_ext,1,{extfunc,erlang,error,1}}.
{jump,{f,5}}.
{label,5}.
{test,is_eq_exact,{f,12},[{atom,placed},{y,0}]}.
beam_bool would see that the is_eq_exact test at label 8 would
always succeed. It could therefore remove most of the code before
the jump to label 5. Unfortunately it also removed the essential
move of Echo to the stack:
{allocate_zero,1,1}.
%% Instruction incorrectly removed: {move,{x,0},{y,0}}.
{jump,{f,5}}.
{label,5}.
{test,is_eq_exact,{f,12},[{atom,placed},{y,0}]}.
The root cause of the problem is that the 'move' instruction is
included in the block of 'bif' instructions before label 8.
Normally the 'move' instruction would not have been discarded,
but because the left operand to the 'or' BIF is 'true', the
entire block with 'bif' instructions are dropped.
As far as I can see, there is no gain by including 'move'
instructions in the first place. There is no way that better
code will be produced. In fact, the entire optimization can
be given up if 'move' instructions are found in the block.
Thus we can fix this bug by never including any 'move' instructions
in the block of 'bif' instructions. We can also remove all the
code that deals with 'move' instructions within blocks.
Reported-by: Thomas Arts
|
|
Today, if you press Ctrl+W inside erl, it will erase word chars including dots.
This may have made sense in the past when Erlang had packages, but today
considering the most common case for dots inside erl is to work with records,
considering the dot part of the word is rather a mistake.
For example, imagine the following code, where [] is the cursor:
1> S#elixir_scope.name[]
When I press Ctrl+W it erases all up to #:
1> S#[]
This patch changes it to the dot is no longer considered part of the name:
1> S#elixir_scope.[]
Which is rather expected behaviour for most use cases of dot in Erlang.
|
|
* legoscia/tls_dist_error_reporting:
Report bad options for outgoing TLS distribution
Save error reasons for TLS distribution connections
Report bad options for TLS distribution connections
OTP-13219
|
|
* josevalim/jv-map-fun-eval-maint:
Use full list of bindings when matching on map keys
OTP-13218
|
|
* lucafavatella/dialyzer-fun-call:
Teach Dialyzer call to funs `M:F/A` (literal M, F, A)
OTP-13217
|
|
|
|
|
