| Age | Commit message (Collapse) | Author |
|---|
|
* dev:
erts: Add a sanity check to autoimport_SUITE
erts: Fix failing autoimport test case
|
|
* bjorn/erts/fix-autoimports-testcase:
erts: Add a sanity check to autoimport_SUITE
erts: Fix failing autoimport test case
|
|
|
|
* fm/enif_compare-64-to-32bits-cast:
Fix enif_compare on 64bits machines
OTP-9533
|
|
* dc/fix_win32_static_crypto:
Fix win32 OpenSSL static linking broken in 20c9d6e
OTP-9532
|
|
* hw/detect-cpus-on-irix:
Detect the available CPUs on IRIX
OTP-9531
|
|
* fm/external_size_2:
Add erlang:external_size/2 BIF
OTP-9528
|
|
* hw/ignore-empty-epmd-address:
Let epmd ignore empty ERL_EPMD_ADDRESS
OTP-9525
|
|
If we fail to parse out any functions from erlang.xml, make sure
that we fail.
|
|
The autoimport_SUITE:autoimport/1 test case would interpret
data type definitions as function calls. Fix this by skipping
to the <funcs> tag before starting to collect function names.
|
|
* dev:
erlc_SUITE: Fix arg_overflow/1 test case
|
|
* bjorn/erts/fix-erlc_SUITE-arg_overflow:
erlc_SUITE: Fix arg_overflow/1 test case
|
|
In commit be8759e68b337524c056b8bb757ea68c9996d863, a buffer overflow
was fixed in erlc and the erlc_SUITE:arg_overflow/1 test case was
added. That test cases invokes erlc with 10000 -D options, which will
result in 'erl' being invoked with more than 30000 arguments.
On some platforms, the test case will fail for the wrong reason:
* 64-bit Linux kernels before 2.6.23 limit the number of arguments in
an excvp() call to 16383. (See "Number of arguments and maximum length
of one argument" in http://www.in-ulm.de/~mascheck/various/argmax/.)
* The command shell in Windows limits the size of the command line to
8191 characters.
Depending on the platform, pass a different number of -D options
to erlc. Since the size of the options does not matter for this
test case, make the options as short as possible by generating
numbers in base 36.
|
|
* dev:
Update documentation and specifications of some of the zlib functions
Conflicts:
erts/preloaded/ebin/zlib.beam
|
|
The functions zlib:deflateSetDictionary/2 and zlib:inflateSetDictionary/2
accept iodata() as Dictionary.
The functions zlib:crc32/2,3, zlib:adler32/2,3, zlib:compress/1,
zlib:uncompress/1, zlib:zip/1, and zlib:unzip/1 accept iodata() as
data.
|
|
In 64bits machines the Sint type has a size of 8 bytes,
while on 32bits machines it has a 4 bytes size.
enif_compare was ignoring this and therefore returning
incorrect values when the result of the CMP function
(which returns a Sint value) doesn't fit in 4 bytes.
For example, passing the operands -1294536544000 and
-1178704800000 to enif_compare would trigger the bug.
|
|
|
|
* ta/configure-fdatasync:
Document fdatasync -lrt requirement (SunOS <= 5.10)
Move fdatasync autoconf checks to proper place
OTP-9512
|
|
|
|
* ms/epmd-fix-compiler-warnings:
epmd: fix compiler warnings
OTP-9500
|
|
This BIF's second parameter is a list of options.
Currently the only allowed option is {minor_version, Version}
where version is either 0 (default) or 1.
|
|
* dev:
code: Optimize purge/1 and soft_purge/1 using check_old_code/1
Add erlang:check_old_code/1
check_process_code/2: Quickly return 'false' if there is no old code
|
|
* bjorn/line-numbers-in-exceptions/OTP-9468: (51 commits)
debugger: By default, only save non-tail-recursive calls
debugger: Add line_number_SUITE
debugger: Include line numbers in exceptions
Update examples in the documentation to include line numbers
Update documentation for erlang:raise/3 and erlang:get_stacktrace/0
beam_lib: Retain the "Line" chunk when stripping BEAM files
erl: Add +L to suppress loading of line number information
compiler: Add no_line_info for suppressing line/1 instructions
exception_SUITE: Test line numbers in exceptions
common_test: Use line numbers in exceptions
common_test tests: Don't do detailed testing of the stack backtrace
test_server: Refactor init_per_testcase/3 into two functions
Implement process_info(Pid, current_{location,stacktrace})
beam_emu: Factor out saving of stack trace from save_stacktrace()
compiler: Don't create filenames starting with "./"
ops.tab: Remove line instructions before tail-recursive calls
Lookup and include filenames and line numbers in exceptions
Fix decrement of continuation pointers
Refactor building of the exception stacktrace
BEAM loader: Load the line table
...
|
|
|
|
Add erlang:check_old_code/1 to quickly check whether a module
has old code. If there is no old code, there is no need to call
erlang:check_process_code/2 for all processes, which will save
some time if there are many processes.
|
|
There is no need to suspend the process if the module has no old
code. Measurements show that this change will make
erlang:check_process_code/2 in an SMP emulator about four times
faster if the module has no old code.
|
|
* rc/r14-gc-fix:
fix 64-bit issues in the garbage collection
OTP-9488
|
|
|
|
|
|
|
|
|
|
Put the actual saving of the continuation pointers on the stack
in the new function erts_save_stacktrace() so that it can be reused.
The code is too tricky and complicated to allow it to
become duplicated.
|
|
|
|
|
|
|
|
As a preparation for providing information about the source
location for an MFA item in an exception stacktrace, refactor
the code that builds the exception stacktrace. Basically we
need two passes over the saved continuation counters: a first
pass to calculate the needed heap space and a second pass to
actually build the stacktrace.
|
|
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
Introduce the line/1 instruction in the compiler and the BEAM
virtual machine. It will not yet be generated by the compiler and
will not actually carry any information.
|
|
'eval_bits' is a common utility module used for evaluting binary
construction and matching. The functions that do matching
(match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as
an abstract data type, but they assume that the bindings have the same
representation as in the erl_eval module. That may cause binary
matching to fail in the debugger, because the debugger represents the
bindings as an unordered list of two-tuples, while the erl_eval
modules uses an ordered list of two-tuple (an ordset).
One way to fix the problem would be to let the debugger to use ordered
lists to represent the bindings. Unfortunately, that would also change
how the bindings are presented in the user interface. Currently, the
variable have most been recently assigned is shown first, which is
convenient.
Fix the matching problem by mending the leaky abstraction in
eval_bits. The matching functions needs to be passed two additional
operations: one for looking up a variable in the bindings and one for
adding a binding. Those operations could be passed as two more funs
(in addition to the evaluation and match fun already passed), but the
functions already have too many arguments. Therefore, change the
meaning of the match fun, so that the first argument is the operation
to perform ('match', 'binding', or 'add_binding') and second argument
is a tuple with arguments for the operation.
|
|
Use a union for pointer type conversion to avoid compiler warnings
about strict-aliasing violations with gcc-4.1. gcc >= 4.2 does not
emit the warning.
TODO: Reconsider use of union once gcc-4.1 is obsolete?
|
|
|
|
We discovered that if a single Erlang process tried to grow above 32
GB (i.e., more 64-bit words than can be counted by a 32-bit number),
the VM failed to find the next larger heap size, even though there
were plenty more heap sizes left to pick from and even though we had a
lot more memory available on the machine. (Obviously, this is only
applicable on 64-bit Erlang.)
It turned out to be due to some 'int' variables in the heap resizing
parts of erl_gc.c not being properly updated to 'Uint' or 'Sint'. Once
that was fixed, I got segfaults instead as soon as the heap got larger
than 2^32 words, due to even more 'int' declarations in the same file,
but now in the GC code.
After fixing this as well, I successfully ran an Erlang node in which
a single Erlang process had a heap so large that I'm not at liberty to
divulge the exact size, but I think the scientific term is
"humongous", and I'm confident that there are no further immediate
problems with very very large individual process heaps.
|
|
|
|
|
|
* ms/inet-socket-domain-error:
inet: error if fd does not match socket domain
OTP-9455
|
|
|
|
* cg/fix-constant-logical-operand:
Fix use of logical operator && with constant operand instead of bitwise &.
OTP-9454
|
|
|
|
* pg/fix-freebsd-dualcore-detection:
Fix bug in FreeBSD topology detection code
OTP-9453
|
