Leo Liu | 27 Mar 16:09 2015
Face
Picon

observer crash in ERLANG/OTP 18.0rc1

I just built erlang/otp from git repo and could crash observer by:

1. Fire up erl
2. Eval observer:start(). in the REPL
3. Click `Trace Overview' in the observer window.

I am on Darwin iMac 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26
19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64

=ERROR REPORT==== 27-Mar-2015::17:29:42 ===
** wx object server <0.43.0> terminating 
** Last message in was {create_menus,
                           [{"File",
                             [{create_menu,306,"Load settings",[],append,
                                  false},
                              {create_menu,305,"Save settings",[],append,
                                  false}]},
                            {"Options",
                             [{create_menu,310,"Output",[],append,false},
                              {create_menu,311,"Match Specifications",[],
                                  append,false},
                              {create_menu,312,"Default Process Options",[],
                                  append,false}]}]}
** When Server state == {state,
                            {wx_ref,35,wxFrame,[]},
                            {wx_ref,37,wxMenuBar,[]},
                            [{"View",
                              [{create_menu,101,"Refresh\tCtrl-R",[],append,
                                   false},
                               {create_menu,102,"Refresh interval",[],append,
(Continue reading)

jim rosenblum | 27 Mar 16:32 2015
Picon

httpc / http 1.1. closes socket

and elsewhere, users observed that httpc would occasionally encounter
`{error,socket_closed_remotely}` when querying a web service of some sort.
The workaround was to use http 1.0, as opposed to 1.1, which is somewhat
of an unsatisfying resolution.

I have encountered this same problem and have tried to create a minimal
example that reproduces the issue using a public url to post a simple JSON
body. I am hoping that the following provides enough information to 
constitute a useful bug report.

The following code will quickly cause the problem to appear; however,
the problem *disappears* when  {"connection", "close"} is added to
the header. In fact I cannot reproduce the problem ever when this
header is used.

My code is as follows:

-module(httpc_bug).
-export([test/0]).

test()->
    httpc:set_options([{max_keep_alive_length, 0},
                                 {max_pipeline_length, 0},
                                 {max_sessions, 0}]),
    test_put(0).

test_put(N) ->
    ContentType= "application/json",
    Body = <<"{\"type\":\"body type\",\"value\":2}">>,
    Header = [],
    HttpOptions = [],
    Options = [],

    case httpc:request(post, {Url, Header, ContentType, Body},
                                  HttpOptions,
                                  Options) of
        {ok, {{_V, _Cd, _R}, _RespHeader, B }} ->
                io:format("~p[~p]:~p~n”, [self(), N, B]),
                test_put(N+1);
        {error, Reason} ->
                io:format("~p: died after ~p iterations with: ~p. ~n.",
                               [self(), N, Reason])
        end.


A typical run looks like this:

Erlang/OTP 17 [erts-6.2] [source-aaaefb3] [64-bit] [smp:8:8]
[async-threads:10] [hipe] [kernel-poll:false]


Eshell V6.2  (abort with ^G)
1> inets:start().
ok
2> ssl:start().
ok
3> code:load_file(httpc_bug).
{module,httpc_bug}
4> httpc_bug:test(1).
[<0.15201.0>]
<0.15201.0>[0]:"Successfully dumped 0 post variables.\nView it at
was 30 chars long."
<0.15201.0>[1]:"Successfully dumped 0 post variables.\nView it at
was 30 chars long."
.
. SNIP
.
<0.15201.0>: died after 102 iterations with: socket_closed_remotely.


I just did five runs, four died in under 410 iterations, and the fifth took
809 iterations.


Again, adding {"connection", "close"} to the header causes the problem to
disappear.

By examining the contents of the http_manager__session_db before each call
to the httpc:request, I am pretty sure that the flow goes:


httpc_manager.erl line 759 — within a handle_request clause

handle_request(Request, State = #state{options = Options}) ->
    NewRequest = handle_cookies(generate_request_id(Request), State),
    SessionType = session_type(Options),
    case select_session(Request#request.method,
                        Request#request.address,
                        Request#request.scheme, SessionType, State) of
    {ok, HandlerPid} ->
        -> pipeline_or_keep_alive(NewRequest, HandlerPid, State); <-
        .
        . SNIP
        .

To

httpc_handler.erl line 323 — within a handle_call where keep_alive requests
are handled.

Hope this is useful.

Thanks

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Matwey V. Kornilov | 26 Mar 20:41 2015
Picon

18.0-rc1 HIPE build failed at ARM


Hi,

I am facing the following issue when trying to build 18.0-rc1 on armv6
and armv7 respectively.

ARMv6:

[ 1934s] make[5]: Entering directory
'/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/lib_src'
[ 1934s]  CC	obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o
[ 1934s]  CC	obj/armv6hl-suse-linux-gnueabi/opt/r/ethr_aux.o
[ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler
messages:
[ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569:
Error: bad instruction
`standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)'
[ 1935s] armv6hl-suse-linux-gnueabi/Makefile:949: recipe for target
'obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed
[ 1935s] make[3]: ***
[obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1
[ 1935s] make[3]: *** Waiting for unfinished jobs....

Configure was:

./configure --host=armv6hl-suse-linux-gnueabi
--build=armv6hl-suse-linux-gnueabi --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info
--disable-dependency-tracking --enable-systemd --with-ssl=/usr
--enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe
--enable-shared-zlib

ARMv7:

[  761s]  M4	armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S
[  761s]  CC	obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o
[  761s] armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler
messages:
[  761s] armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569:
Error: bad instruction
`standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)'
[  761s] armv7hl-suse-linux-gnueabi/Makefile:949: recipe for target
'obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed
[  761s] make[3]: ***
[obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1
[  761s] make[3]: Leaving directory
'/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/emulator'
[  761s]
/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/make/run_make.mk:34: recipe
for target 'opt' failed

Configure was:

./configure --host=armv7hl-suse-linux-gnueabi
--build=armv7hl-suse-linux-gnueabi --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info
--disable-dependency-tracking --enable-systemd --with-ssl=/usr
--enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe
--enable-shared-zlib

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

Alexander Pozdneev | 26 Mar 09:52 2015
Picon

Building on IBM POWER8 running in little endian

Hello,

When I try to configure Erlang 17.4 on IBM POWER8 running RHEL 7.1 little 
endian, I get the following message

This script, last modified 2013-02-12, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
...

I confirm that with the latest versions of config.guess and config.sub I 
was able to build the code successfully.

Best regards,
Alexander Pozdneev

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

Jesper Louis Andersen | 24 Mar 15:16 2015
Picon

Maps equality failure / Maps merge failure

Hi OTP team (and other readers),

Over the weekend, I've been building up a QuickCheck model of Erlang/OTP maps(). This is to be able to properly test the HAMT maps of the up-and-coming 18.0 release for correctness, but I'm testing on 17.4.1 as well. The following problem occurs for release 17.4.1. (for the curious, 18.0 currently segfaults on these tests):

Erlang/OTP 17 [erts-6.3.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]

Eshell V6.3.1  (abort with ^G)
1> Map = #{0 => 0,2147483648 => 0}.
#{0 => 0,2147483648 => 0}
2> Bin = term_to_binary(M).
* 1: variable 'M' is unbound
3> Bin = term_to_binary(Map).
<<131,116,0,0,0,2,97,0,97,0,110,4,0,0,0,0,128,97,0>>
4> Map2 = binary_to_term(Bin).
#{2147483648 => 0,0 => 0}
5> Map =:= Map2.
false

(copied verbatim, including my error in 2>)

The problem is that if I convert the map to a binary and then back again, the two maps are not equal. Furthermore, they print differently:

6> Map.
#{0 => 0,2147483648 => 0}
7> Map2.
#{2147483648 => 0,0 => 0}
8> 

The value 2147483648 seems important and it is 2^31. However, the problem also occurs at 2^31 + 1. Only testing with "small" integers poses no problem at all. I have yet to test against floating point numbers and this requires some additional attention to detail as they have fun equality rules :)

A second problem occurs in merges, which may be related or may not be related. In the second problem, we are merging maps

[#{-2147483649 => 0,
   0 => 0,
   97 => 0,
   false => 0,
   flower => 0,
   #Fun<eqc_gen.133.121384563> => 0,
   #Fun<eqc_gen.133.121384563> => 0,
   <<>> => 0},
 #{0 => 1}]

where the #Fun's are generated functions of 0 and 2 parameters respectively. Lets see how to create such a map (one might note that direct creation through #{ ... } syntax would make the keys which are functions illegal, but I am an experiened Erlang programmer and have a way around such petty limitations :P)

9> F1 = fun(_, _) -> 0 end,
9> F2 = fun(_, _) -> 1 end.

This defines two functions:

11> maps:from_list(
11> [{-2147483649, 0},
11>    {0,0}, {97, 0}, {false, 0}, {flower, 0}, {F1, 0}, {F2, 0}, {<<>>, 0}]).
#{-2147483649 => 0,
  0 => 0,
  97 => 0,
  false => 0,
  flower => 0,
  #Fun<erl_eval.12.90072148> => 0,
  #Fun<erl_eval.12.90072148> => 0,
  <<>> => 0}

Remarkably, this is well-defined, now lets merge:

12> maps:merge(v(11), #{0 => 1}).                                             
#{0 => 1,
  -2147483649 => 0,
  0 => 0,
  97 => 0,
  false => 0,
  flower => 0,
  #Fun<erl_eval.12.90072148> => 0,
  #Fun<erl_eval.12.90072148> => 0,
  <<>> => 0}
13> 

The resulting map now has to '0' keys! Rejoice!

The model I am using is the following:


(maps_iso_eqc are simple stateless tests, whereas maps_eqc is a more complicated stateful test which also verifies properties about copying maps between processes and that maps are persistent data structures).

To run:

make:all([load]).
eqc:module({testing_budget, 20}, maps_iso_eqc).

Two test runs of mine:


Note the latter merge test which managed to shrink over 1200 times!


--
J.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Roberto Aloi | 23 Mar 15:32 2015
Picon

Compile attribute and module_info

Hi,

given the following module test.erl:

-module(test).
-export([test/0]).
test() -> ok.

if I compile it with the 'native' option, I can see the option in the list of compile
options returned by test:module_info/0:

1> c(test, [native]).
{ok,test}
2> test:module_info().
[{exports,[{test,0},{module_info,0},{module_info,1}]},
 {imports,[]},
 {attributes,[{vsn,[...]}]},
 {compile,[{options,[native]},
           {version,"4.9.4"},
           {time,{2015,3,23,14,26,9}},
           {source,"/tmp/test.erl"}]}]

But if I use the 'native compile attribute, instead:

-module(test).
-compile([native]).
-export([test/0]).
test() -> ok.

If I compile the module, the option is not returned by test:module_info/0, either as a compile option or as an attribute:

3> c(test).
{ok,test}
4> test:module_info().
[{exports,[{test,0},{module_info,0},{module_info,1}]},
 {imports,[]},
 {attributes,[{vsn,[...]}]},
 {compile,[{options,[]},
           {version,"4.9.4"},
           {time,{2015,3,23,14,28,28}},
           {source,"/tmp/test.erl"}]}]

Is this the intended behaviour?

R

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Adam Lindberg | 23 Mar 12:58 2015

Segfault when using Observer

When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it segfaults when inspecting a process
from the Applications tab. This does not happen when inspecting a process from the Processes tab.

    $ erl
    Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

    Eshell V6.3  (abort with ^G)
    1> observer:start().
    ok
    2> [1]    52545 segmentation fault  erl
    $

Full stack trace from OS X can be found here: https://gist.github.com/eproxus/3d517e895c3e05f93bcb

Cheers,
Adam

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Alvaro Videla | 23 Mar 10:22 2015
Picon

TLS Distribution doesn't honour distribution arguments

Hi,

It seems distribution over TLS doesn't honour the inet_dist_listen_* parameters.



Regards,

Alvaro
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Anton Ryabkov | 17 Mar 09:12 2015
Picon

xmerl trouble with validation anyURI type

Hello,

I have a trouble with validating xml document by xsd schema with attribute's type anyURI and value = "alerting.wav". According to RFC 3986 (Uniform Resource Identifier)
"alerting.wav" is valid value for anyURI type. I've tried on Erlang R16B03, 17.4.

I attached simple sample, where you can see this problem. To run it, compile xml_test and invoke "test" method.

I've analyzed xmerl source code, and have found that in xmerl_xsd_type.erl file make validation anyURI type. According source code anyURI must contains SCHEME section, but by RFC 3986
this section is optional. I've made fix, that validate anyURI type according regular expression from RFC 3986, Appendix B.

Attachment (xmerl_anyURI_bug.tar.gz): application/x-gzip, 3570 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
James Fish | 13 Mar 00:56 2015

Dialyzer can yield false positives and false negatives after checking PLT

Hi,

If a function is removed from a module and the module has previously been added to a PLT, the function will not be removed from PLT when the PLT is checked. This results in dialyzer failing to produce a callgraph warning when doing success typings analysis if the remove function is still called in another module

As the function is not removed from the PLT a prior warning, such as a contract types warning, might be emitted when the removed function nolonger exists.

I have attached an archive with a minimal example, which prints a contract types warning instead of a callgraph warning. This example has been tested on OTP R15B03 and 17.4.

Regards,

James
Attachment (plt_gc.tar.gz): application/x-gzip, 1021 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Magnus Ottenklinger | 13 Mar 10:54 2015

Invalid section on test suite line numbers in test_server reference manual

Hey List,

 

The parse_transform and macro for adding line numbers has been removed in 2011 [1]. Should the section ‘TEST SUITE LINE NUMBERS’ [1] on using the parse_transform be removed from be removed? Also, the reference to the line macro in ‘TEST SUITE SUPPORT MACROS’ should be invalid by now as well.

 

 

Regards, Magnus

 

[1] https://github.com/erlang/otp/commit/f43c0a51cd15b2b0f8adba4bb9ec5531dd9d8820

[2] http://www.erlang.org/doc/man/test_server.html

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

Gmane