Richard Carlsson | 26 Apr 20:10 2015
Picon

Suicide by module_info

Here's a fun one!

Erlang/OTP 18 [RELEASE CANDIDATE 1] [erts-7.0] [source-7ff8f81] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V7.0  (abort with ^G)
1> c(foo).
{ok,foo}
2> erlang:get_module_info(foo).
[{module,foo},
 ...]
3> code:delete(foo).          
true
4> erlang:get_module_info(foo).
Segmentation fault (core dumped)


https://github.com/erlang/otp/pull/696

        /Richard
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Loïc Hoguin | 26 Apr 14:30 2015
Picon

proc_lib man page unclear

I am not sure by what is meant in the proc_lib man page:

Using the spawn option monitor is currently not allowed, but will cause 
the function to fail with reason badarg.

If the option is not allowed then surely one would expect it to fail 
with badarg? Why "but"?

--

-- 
Loïc Hoguin
http://ninenines.eu
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Kenji Rikitake | 25 Apr 03:13 2015

A possibly-spurious warning message on 18.0-rc1 when enabling compile inline option

A warning message, which does not make sense, is generated when
compiling the following code on 18.0-rc1 (both on FreeBSD and OS X):

erlc -Werror buftest.erl
compile: warnings being treated as errors
buftest.erl:15: a term is constructed, but never used

This doesn't happen on 17.5,
and this message is not generated when
`-compile({inline, [loop/1]})` doesn't exist.

buftest.erl source code:

-module(buftest).

-export([
        loop/1
    ]).

-compile({inline, [loop/1]}).

calc(H, H2) ->
    ok = io:format("H = ~p, H2 = ~p~n", [H, H2]),
    H2.

loop({[H], RL}) ->
    NL = lists:reverse(RL),
    loop({[H|NL], []}); % <- this line generates the warning
loop({L, RL}) ->
    [H|L2] = L,
    [H2|L3] = L2,
    NH2 = calc(H, H2),
    NL2 = [NH2|L3],
    NRL = [H|RL],
    {NL2, NRL}.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Kenji Rikitake | 25 Apr 02:59 2015

ERTS_FP_CHECK_INIT error of HiPE in 18.0-rc1 running on FreeBSD 10.1-STABLE

I've seen a massive numbers of error when running a common test on
18.0-rc1 with HiPE as:

ERTS_FP_CHECK_INIT at 0x50e193: detected unhandled FPE at 0x4ad

This didn't happen when HiPE is disabled (--disable-hipe).

I have traced this in the source that this message is sent from
erts_fp_check_init_error() in erts/emulator/sys/unix/sys_float.c,
highly presumably from
hipe_fclearerror_error() in erts/emulator/hipe/hipe_native_bif.c.

The running environment is on FreeBSD amd64 10.1-STABLE #64 r281235,
and the kerl compilation options:

export CC=clang CXX=clang CFLAGS="-O3 -fstack-protector" LDFLAGS="-fstack-protector" MAKEFLAGS="-j8"
KERL_CONFIGURE_OPTIONS="--disable-native-libs --enable-vm-probes --with-dynamic-trace=dtrace
--with-ssl=/usr/local --with-javac --enable-hipe --enable-kernel-poll
--with-wx-config=/usr/local/bin/wxgtk2u-2.8-config --without-odbc --enable-threads
--enable-sctp --enable-smp-support --disable-silent-rules"

You can check this out by:

git clone https://github.com/jj1bdx/emprng/
cd emprng
make tests

Regards,
Kenji Rikitake
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Tuncer Ayaz | 24 Apr 22:35 2015
Picon

Observer Crashdump Viewer bug?

Can anyone else reproduce a responsive but blocked Observer
gui following these steps?

# install otp 18.0 from master

# clone and build erlguten
$ git clone https://github.com/richcarl/erlguten
$ cd erlguten
$ make
$ ./erlguten test/test1.xml

# start Observer use File->Examine Crash Dump to load the
# erlguten crash dump
$ erl
1> observer:start().
ok
WARNING: Found unexpected tag:scheduler
WARNING: Found unexpected tag:scheduler
WARNING: Found unexpected line in general information:
Calling Thread
WARNING: Found unexpected line in ETS info:
Chain Length Avg

# now it stalls in the GUI at "Processing ets"

This does not happen if you instead start crashdump_viewer:start/0.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Tuncer Ayaz | 24 Apr 17:32 2015
Picon

gcc 5.1 ubsan

Just built yesterday's otp.git master with amd64 gcc-5.1, and here's
the UBSan results. The previously reported int overflow with 4.9 are
naturally also there, but the diagnostics have changed a little.

Of course, this is just an excerpt, and the complete set of ubsan
errors for, say, one invocation of erlc would be too much to post.

If for some reason you don't have access to gcc-5.1, I've archived the
full build log for reference. Ask me if you need it.

------

beam/erl_thr_progress.c:422:8: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

sys/common/erl_poll.c:391:23: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

common/ethr_mutex.c:3003:7: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:3055:10: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:3056:13: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:3021:11: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:3063:7: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:3064:13: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:2077:16: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

common/ethr_mutex.c:2109:10: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/beam_load.c:5205:14: runtime error: left shift of 65535 by 16
places cannot be represented in type 'int'

beam/external.c:3064:13: runtime error: left shift of 255 by 24 places
cannot be represented in type 'int'

beam/erl_process.c:10912:20: runtime error: left shift of 268435455 by
4 places cannot be represented in type 'int'

beam/erl_process.c:10916:23: runtime error: left shift of 268435455 by
4 places cannot be represented in type 'int'

beam/erl_process.c:10749:33: runtime error: left shift of 268435455 by
4 places cannot be represented in type 'int'

beam/erl_process.c:10782:39: runtime error: left shift of 268435455 by
4 places cannot be represented in type 'int'

beam/erl_thr_progress.c:812:14: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/erl_thr_progress.c:741:18: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/erl_thr_progress.c:358:27: runtime error: left shift of 1 by 31
places cannot be represented in type 'in

beam/erl_thr_progress.c:366:27: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/erl_thr_progress.c:867:7: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/beam_emu.c:5588:15: runtime error: member access within
misaligned address 0x00000230676c for type 'struct StackTrace', which
requires 8 byte alignment
0x00000230676c: note: pointer points here
  22 72 91 25 00 00 00 00  00 00 00 00 00 00 [...]
              ^

sys/common/erl_check_io.c:1621:9: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

sys/common/erl_poll.c:2293:6: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

sys/common/erl_poll.c:2136:21: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

sys/common/erl_poll.c:2347:26: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

sys/common/erl_poll.c:2023:25: runtime error: left shift of 1 by 63
places cannot be represented in type 'long int'

beam/erl_bits.c:164:19: runtime error: member access within misaligned
address 0x000002306cbc for type 'struct ErlBinMatchState', which
requires 8 byte alignment
0x000002306cbc: note: pointer points here
  d5 08 c2 01 c4 02 00 00  00 00 00 00 52 6c 30 [...]
              ^

beam/erl_bits.c:157:11: runtime error: member access within misaligned
address 0x00000240095c for type 'struct ProcBin', which requires 8
byte alignment
0x00000240095c: note: pointer points here
  74 00 00 00 24 01 00 00  09 00 00 00 2d 70 72 6f [...]
              ^

beam/beam_emu.c:6387:22: runtime error: member access within
misaligned address 0x000002401a64 for type 'struct ErlFunThing', which
requires 8 byte alignment
0x000002401a64: note: pointer points here
  d5 0a 40 02 00 00 00 00  00 00 00 00 00 00 00 00 [...]
              ^

beam/io.c:5942:6: runtime error: null pointer passed as argument 2,
which is declared to never be null
/usr/include/bits/string3.h:53:10: runtime error: null pointer passed
as argument 2, which is declared to never be null

beam/erl_gc.c:2354:23: runtime error: member access within misaligned
address 0x0000024013ec for type 'struct erl_off_heap_header', which
requires 8 byte alignment
0x0000024013ec: note: pointer points here
  03 02 00 00 d4 01 00 00  00 00 00 00 50 2e 49 0e [...]
              ^

beam/erl_thr_progress.c:763:18: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/erl_thr_progress.c:779:13: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/erl_thr_progress.c:816:25: runtime error: left shift of 1 by 31
places cannot be represented in type 'int'

beam/binary.c:97:20: runtime error: member access within misaligned
address 0x00000240340c for type 'struct ProcBin', which requires 8
byte alignment
0x00000240340c: note: pointer points here
  87 09 00 00 00 00 00 00  21 40 40 02 00 00 00 00  11 [...]
              ^

beam/erl_bif_op.c:256:10: runtime error: member access within
misaligned address 0x00000240830c for type 'struct ErlFunThing', which
requires 8 byte alignment
0x00000240830c: note: pointer points here
  f1 82 40 02 d4 01 00 00  0f 07 00 00 30 3a 65 0f  56 03 00 [...]
              ^

beam/external.c:3280:14: runtime error: left shift of 245 by 24 places
cannot be represented in type 'int'

beam/beam_emu.c:5654:13: runtime error: member access within
misaligned address 0x00000241bafc for type 'struct StackTrace', which
requires 8 byte alignment
0x00000241bafc: note: pointer points here
  e5 ba 41 02 88 05 00 00  50 07 00 00 fd ba 41 02  fb ff ff ff [...]
              ^

x86_64-unknown-linux-gnu/opt/smp/beam_cold.h:142:5: runtime error:
member access within misaligned address 0x000002429b84 for type
'struct ErlBinMatchBuffer', which requires 8 byte alignment
0x000002429b84: note: pointer points here
  00 00 00 00 fa 9a 42 02  00 00 00 00 b0 4e 4c 0f  56 03 00 [...]
              ^
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Roberto Ostinelli | 22 Apr 16:34 2015

Cannot run CT tests multiple times

Dear list,
When I run CT tests multiple times I encounter a bug.

========
erl -pa apps/*/ebin -pa deps/*/ebin \
    -name myapp <at> 127.0.0.1 \
    +K true \
    +P 5000000 \
    +Q 1000000 \
    -env ERL_FULLSWEEP_AFTER 10 \
    -config myapp \
    -mnesia schema_location ram \
    -noshell \
    -eval 'ct_run:run_test([{dir, "apps/myapp/test"}, {logdir, "apps/myapp/logs"}]).' \
    -s erlang halt
=========


Running this the first 2/3 times will give:


=========
Common Test starting (cwd is /Users/roberto/workspace/myapp)


Common Test: Running make in test directories...

CWD set to: "/Users/roberto/workspace/myapp/apps/myapp/logs/ct_run.myapp <at> 127.0.0.1.2015-04-22_16.25.39"

TEST INFO: 1 test(s), 1 case(s) in 1 suite(s)

Testing apps.myapp: Starting test, 1 test cases
Testing apps.myapp: TEST COMPLETE, 1 ok, 0 failed of 1 test cases
=========


After the 3rd time or so (this happens randomly), I get:


=========
$ ./tests 

Common Test starting (cwd is /Users/roberto/workspace/myapp)


=ERROR REPORT==== 22-Apr-2015::16:26:00 ===
Error in process <0.42.0> on node 'myapp <at> 127.0.0.1' with exit value: {{badmatch,["ct_run","myapp <at> 127","0","0","1","2015-04-22_16","25","26"]},[{ct_logs,'-sort_ct_runs/1-fun-0-',2,[{file,"ct_logs.erl"},{line,1912}]},{lists,sort,2,[{file,"lists.erl"},{line,967}]},{ct_logs,make_all_suites_index,1,[{file,"ct_logs... 
=========


If I delete the directory where the CT logs are stored I can re-run the command, without issues.

Any ideas?

Best,
r.



_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Leo Liu | 20 Apr 09:06 2015
Face
Picon

Make it possible to link to unixODBC on darwin

Hi there,

I thought Erlang is linked to unixODBC on my mac since `brew info
erlang' prints:

  erlang: stable 17.5 (bottled), HEAD
  http://www.erlang.org
  /usr/local/Cellar/erlang/17.5 (7398 files, 283M) *
    Poured from bottle
  From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/erlang.rb
  ==> Dependencies
  Build: autoconf ✔, automake ✔, libtool ✔
  Required: openssl ✔, unixodbc ✔

Took me about 20 minutes to install mysql and mysql-connector-odbc,
configure and connect to mysql using odbc (via isql). but the Erlang
odbc app keeps failing:

        {error,"[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver
could not be loaded SQLSTATE IS: IM002 Connection to database failed."}

So now I am investigating this iodbc and discovered erlang actually
linked to /usr/lib/libiodbc.2.dylib which seems to be an awfully
outdated lib that apple no longer maintains. Besides that file I have no
idea what else are provided to work with iODBC.

I think it makes a lot of sense to allow compiling erlang with another
ODBC lib (unixODBC takes about 1.7 seconds to install on the mac).

Thanks,
Leo

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Loïc Hoguin | 16 Apr 11:45 2015
Picon

gen_server:init/1 is optional (18+)

Hello,

gen_server:init/1 is an optional callback and should be marked as such 
in Erlang 18+ now that it has -optional_callbacks.

It is optional because of enter_loop. It is currently not possible to 
use -behavior(gen_server) when you need to use enter_loop.

Cheers,

--

-- 
Loïc Hoguin
http://ninenines.eu
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Alexander Burkov | 9 Apr 12:27 2015
Picon

Cover transforms some binary comprehensions incorrectly

In some cases cover transforms binary comprehensions into non-working ones. Please consider example below:
---cut---
-module(wrong_transform).
-compile(export_all).

good() ->
    << <<$,, X/binary>> || X <- [ <<"a">>, <<"b">> ]>>.

bad() ->
    << <<",", X/binary>> || X <- [ <<"a">>, <<"b">> ]>>.
---cut---

With disabled cover, outputs of this functions are equal, `bad() =:= good()`. But if you do `cover:compile_beam/1` (see decompile.erl) it blows with `badarg` in `bad/0` function. Meanwhile `good/0` works well.

I've patched a bit `cover.erl` to dump AST forms before and after `cover:compile_beam/1` and found that for some reason it surrounds terms inside of comprehension with `begin ... end` pattern. It is wrong in case of list (I can't explain why, but it throws badarg, so I guess it is definitely an issue :)

Also I will appreciate if someone explain me why we do need this cover's trick with `begin .. end`.

Thank you!
Attachment (wrong_transform.after.erl): application/octet-stream, 615 bytes
Attachment (wrong_transform.after.ast): application/octet-stream, 3347 bytes
Attachment (wrong_transform.before.ast): application/octet-stream, 2054 bytes
Attachment (cover.erl.patch): application/octet-stream, 932 bytes
Attachment (decompile.erl): application/octet-stream, 745 bytes
Attachment (wrong_transform.before.erl): application/octet-stream, 251 bytes
Attachment (wrong_transform.erl): application/octet-stream, 247 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
José Valim | 8 Apr 00:44 2015
Picon

Erlang 18.0-rc1 is behaving slower than 17.4 (and 17.5)

I have first noticed this issue when compiling Elixir's grammar. Compiling yrl -> erl -> beam is about 20% slower in Erlang 18.0-rc1. The results are shown below:


To further verify the performance issues, I have decided to run Elixir's test suite with 18.0 and 17.4. Elixir test suite defines a lot of modules dynamically when loading so that would be a good test. The results are here:


It is interesting that the load/compile times are indeed higher in 18.0 but the test suite is also taking *longer*. This may imply it is not the compiler that is slower but Erlang itself. I have run the test suite of other projects in different Erlang versions (same Elixir version though) and seen similar slow down. About a 20% slow down on Erlang 18.0-rc1 overall.

Unfortunately, I don't have any idea why this is happening. I have asked others to compile the same .yrl file and they have seen similar performance hit. It is easy to reproduce it. Download the elixir_parser.yrl file:


And run both commands:

    $ time erlc +time elixir_parser.yrl
    $ time erlc +time elixir_parser.erl

I hope by posting this report others can be alert to similar issues in their projects.

Thoughts?

José Valim
Skype: jv.ptec
Founder and Lead Developer
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Gmane