From jani.j.hakala@REDACTED Thu Jan 2 15:47:28 2014 From: jani.j.hakala@REDACTED (Jani Hakala) Date: Thu, 02 Jan 2014 16:47:28 +0200 Subject: [erlang-bugs] Dependencies changed for building wx .so files? In-Reply-To: (Paul Dickson's message of "Mon, 30 Dec 2013 23:17:19 -0500") References: Message-ID: <87k3eiqw3j.fsf@pingviini.dyndns.org> Paul Dickson writes: > So that was fixed. But now in R16B03 the problem is back again: no wx > .so files. Even though the wxgtk dependencies are being used. The > bug report for that is here: https://bugs.archlinux.org/task/38302 > I could not reproduce this bug with a fresh install of 64bit arch linux (starting from archlinux-2013.12.01-dual.iso). wxe_driver.so and erl_gl.so were built and wx:demo() works (gl part was not tested properly since arch linux was run in a virtual machine). Jani Hakala From vinoski@REDACTED Thu Jan 2 18:32:23 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 2 Jan 2014 12:32:23 -0500 Subject: [erlang-bugs] Emacs-mode does not recognize functions with binary matching in the header. In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 5:19 AM, Daniel Mauritzson < daniel.mauritzson@REDACTED> wrote: > I recently noticed that the emacs-mode does not recognize functions that > have binary matching in the header, like this: > > function1(<>) -> > > Bin. > > > I would guess that it is a problem with the regex that is used for > functions but my knowlage about regex in lisp is lacking. > > Version of emacs-mode: 2.7 > I've created a pull request to fix this problem: https://github.com/erlang/otp/pull/185 Daniel was kind enough to test the patch for me, and he emailed me to report that it fixes the problem. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdtwonotes@REDACTED Fri Jan 3 21:57:38 2014 From: pdtwonotes@REDACTED (Paul Dickson) Date: Fri, 3 Jan 2014 15:57:38 -0500 Subject: [erlang-bugs] Dependencies changed for building wx .so files? In-Reply-To: <8761q2q8mg.fsf@pingviini.dyndns.org> References: <87k3eiqw3j.fsf@pingviini.dyndns.org> <8761q2q8mg.fsf@pingviini.dyndns.org> Message-ID: It has been confirmed that 'glu' was the new missing dependency and the Arch package procedure has been updated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanssv@REDACTED Fri Jan 10 12:12:42 2014 From: hanssv@REDACTED (Hans Svensson) Date: Fri, 10 Jan 2014 12:12:42 +0100 Subject: [erlang-bugs] Inconsistency in erl_syntax Message-ID: <52CFD5AA.3040408@gmail.com> Hi, I've struggled a bit with erl_syntax lately, and I find it confusing to say the least. I can't put my finger on exactly what is the error, but taken together the situation is weird. First the forms returned by the parser (for example what you get in a parse transform) differ a bit. If you have the statement: fun x/1 The form you get is: {'fun',10,{function,x,1}} However, the statement: fun m:x/1 gives you the form: {function,{atom,10,m},{atom,10,x},{integer,10,1}} I know that work has been done (with named funs) on M:F/A, and that these should not be concrete, but this asymmetry is not helping anyone?! Next problem I have is with erl_syntax:subtrees/1 in combination with erl_syntax:revert/1. subtrees expect the function and the arity to be concrete, while revert will no longer make them concrete. Thus if you create subtrees, revert, and then try to manipulate it (for example by again looking at the subtrees) things go horribly wrong (crash in erl_syntax:implicit_fun_name). My initial thought was that erl_syntax:implicit_fun_name/1 lacks the backward compatibility clause/logic. But since the forms returned by the parser are concrete, it could be that erl_syntax:revert_implicit_fun is doing the wrong thing instead?! Either way this is causing problems and confusion... If we can agree what is the preferred fix I'm happy to implement a patch! Cheers, Hans From morten.aasnes@REDACTED Fri Jan 10 13:41:13 2014 From: morten.aasnes@REDACTED (=?UTF-8?Q?Morten_Nygaard_=C3=85snes?=) Date: Fri, 10 Jan 2014 13:41:13 +0100 Subject: [erlang-bugs] ASN1 parsing bug Message-ID: Hi, I've encountered what I think is a bug in parsing asn1. Here is a testcase: Testcase DEFINITIONS IMPLICIT TAGS ::= BEGIN BaseType ::= ENUMERATED { foo, bar, buz, qux, ... } SubType ::= BaseType ( foo | bar ) END This gives the following error: 28> asn1ct:compile("Testcase", [ber,verbose]). Erlang ASN.1 version "2.0.4", compiling "Testcase.asn" Compiler Options: [ber,verbose,{i,"."}] asn1error:13:'Testcase':'SubType' {asn1,{undefined_type,bar}} {error,[{error,{type,13,'Testcase','SubType', {asn1,{undefined_type,bar}}}}]} If I remove the extension marker in BaseType, it compiles fine. This is using R16B03 on Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi@REDACTED Wed Jan 15 04:59:40 2014 From: ravi@REDACTED (ravi) Date: Wed, 15 Jan 2014 09:29:40 +0530 Subject: [erlang-bugs] Add support for new arch 'ppc64le' in "erlang" upstream package Message-ID: <52D607AC.9060405@linux.vnet.ibm.com> Hi, We are in the process of adding support for new arch 'ppc64le' (powerpc 64-bit Little Endian) and I was looking at building " erlang" package on ppc64le environment and found that "erlang" package require a patch to multiple config.guess files found in the erlang release tarball. Fortunately , automake >=1.13.4 has all the needed bits to support building on ppc64le arch. We would like to request you to upgrade "automake" in your build machine to >=1.13.4 and spin-off a new version of "erlang" and let us know the new tar availability. So that we can test it on ppc64le architecture for you. the release tarball that we picked is from "http://www.erlang.org/download/otp_src_R16B03.tar.gz", which doesn't have the ppc64le support. Your response is highly appreciated. -- Ravindran IBM LinuxTechnologyCenter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Wed Jan 15 09:31:48 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 15 Jan 2014 09:31:48 +0100 Subject: [erlang-bugs] Add support for new arch 'ppc64le' in "erlang" upstream package In-Reply-To: <52D607AC.9060405@linux.vnet.ibm.com> References: <52D607AC.9060405@linux.vnet.ibm.com> Message-ID: <21206.18292.23354.782642@gargle.gargle.HOWL> ravi writes: > Hi, > > We are in the process of adding support for new arch 'ppc64le' > (powerpc 64-bit Little Endian) and I was looking at building " erlang" > package on ppc64le environment and found that "erlang" package require a > patch to multiple config.guess files found in the erlang release tarball. > Fortunately , automake >=1.13.4 has all the needed bits to support > building on ppc64le arch. > > We would like to request you to upgrade "automake" in your build machine > to >=1.13.4 and spin-off a new version of "erlang" and let us know the > new tar availability. So that we can test it on ppc64le architecture for > you. How exactly does it fail currently without updated config.guess files? Does it work if you pass --build=ppc64le-unknown-linux-gnu to configure? /Mikael From s.seletskiy@REDACTED Wed Jan 15 09:17:50 2014 From: s.seletskiy@REDACTED (Stanislav Seletskiy) Date: Wed, 15 Jan 2014 15:17:50 +0700 Subject: [erlang-bugs] Incorrect line number in stacktrace when using atom as binary Message-ID: Recently I've stuck with error "** exception error: bad argument" while doing obviously wrong <> (A :: atom()), but I've noticed, that line number, that shows along with error message, was incorrect. Consider this code: -module(bug). -export([ test/1 ]). test(A) -> erlang:display(A), <>. Let's compile it and run in shell (R16B03, B02 is also affected): 1> bug:test(atom). atom ** exception error: bad argument in function bug:test/1 (src/bug.erl, line 8) So, as we can see, line 8 is pointed at "erlang:display(A)", but error was occured on line 9. It can be very confusing while debugging large modules. I think it's a bug because of it points on invalid line and with other errors there is no such behaviour. Thanks for attention. -- Stanislav Seletskiy From zl9d97p02@REDACTED Wed Jan 15 11:04:02 2014 From: zl9d97p02@REDACTED (Simon Cornish) Date: Wed, 15 Jan 2014 00:04:02 -1000 Subject: [erlang-bugs] R16B03 ssh client is broken for keyboard-interactive Message-ID: <23991-1389780243-279673@sneakemail.com> Hi, It seems like OTP-11363 breaks keyboard-interactive authentication by introducing the ssh_message module. The following messages will always be decoded as #ssh_msg_userauth_pk_ok{} SSH2_MSG_USERAUTH_PK_OK SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ SSH2_MSG_USERAUTH_INFO_REQUEST Which, when the server has keyboard-interactive as a preferred authentication method results in an error like the one shown below. Attached is the patch I used as a workaround. It's probably not the best solution. Really, the decode should be aware of what messages are expected from the current state of the connection. Regards, Simon Error: 4> catch ssh:shell("localhost", 22, [{user, "x123"}, {password,"x123"}, {user_dir, "/tmp/simon/xxhd"}]). {error,"Internal error"} 5> =ERROR REPORT==== 14-Jan-2014::16:15:04 === Erlang ssh connection handler failed with reason: function_clause , Stacktace: [{ssh_connection_handler,userauth, [{ssh_msg_userauth_pk_ok,<<>>, <<0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,9,80,97,115,115,119, 111,114,100,58,0>>}, {state,client,undefined,<0.32.0>,"x123", {connection,[],28690,[],0,undefined,undefined, undefined, [{user_pid,<0.32.0>}, {host,"localhost"}, {idle_time,infinity}, {user_dir,"/tmp/simon/xxhd"}, {password,"x123"}, {user,"x123"}], undefined,undefined,undefined,undefined}, 0,infinity,tcp,gen_tcp,tcp_closed, {ssh,client, {"localhost",{{127,0,0,1},22}}, {2,0}, {2,0}, "SSH-2.0-Erlang","SSH-2.0-OpenSSH_5.6", .... undefined,"x123","ssh-connection",false, "publickey,keyboard-interactive,password", ["publickey","keyboard-interactive"], [], ["ssh-rsa","ssh-dss"], false}, #Port<0.1188>,<<>>,<<>>,undefined, {ssh_msg_kexinit, <<176,81,33,95,58,180,129,224,145,127,117,133,160, 53,16,241>>, ["diffie-hellman-group1-sha1"], ["ssh-rsa","ssh-dss"], ["aes128-cbc","3des-cbc"], ["aes128-cbc","3des-cbc"], ["hmac-sha1"], ["hmac-sha1"], ["none","zlib"], ["none","zlib"], [],[],false,0}, false,undefined,undefined,undefined, [{user_pid,<0.32.0>}, {host,"localhost"}, {idle_time,infinity}, {user_dir,"/tmp/simon/xxhd"}, {password,"x123"}, {user,"x123"}]}], [{file,"ssh_connection_handler.erl"},{line,393}]}, {ssh_connection_handler,event,3, [{file,"ssh_connection_handler.erl"},{line,1126}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] please report this to erlang-bugs@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-kbd-interactive.patch Type: application/octet-stream Size: 1181 bytes Desc: not available URL: From ravi@REDACTED Wed Jan 15 11:28:10 2014 From: ravi@REDACTED (ravi) Date: Wed, 15 Jan 2014 15:58:10 +0530 Subject: [erlang-bugs] Add support for new arch 'ppc64le' in "erlang" upstream package In-Reply-To: <21206.18292.23354.782642@gargle.gargle.HOWL> References: <52D607AC.9060405@linux.vnet.ibm.com> <21206.18292.23354.782642@gargle.gargle.HOWL> Message-ID: <52D662BA.2020308@linux.vnet.ibm.com> Hi Mikael, On 01/15/2014 02:01 PM, Mikael Pettersson wrote: > ravi writes: > > Hi, > > > > We are in the process of adding support for new arch 'ppc64le' > > (powerpc 64-bit Little Endian) and I was looking at building " erlang" > > package on ppc64le environment and found that "erlang" package require a > > patch to multiple config.guess files found in the erlang release tarball. > > Fortunately , automake >=1.13.4 has all the needed bits to support > > building on ppc64le arch. > > > > We would like to request you to upgrade "automake" in your build machine > > to >=1.13.4 and spin-off a new version of "erlang" and let us know the > > new tar availability. So that we can test it on ppc64le architecture for > > you. > > How exactly does it fail currently without updated config.guess files? without updated config.guess files, configure script exits with below error: /configure: error: cannot guess build type; you must specify one/ > Does it work if you pass --build=ppc64le-unknown-linux-gnu to configure? yes, ./configure --build=ppc64le-unknown-linux-gnu worked fine. > > /Mikael > -- Ravindran IBM LinuxTechnologyCenter -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Jan 16 09:59:22 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 16 Jan 2014 09:59:22 +0100 Subject: [erlang-bugs] Incorrect line number in stacktrace when using atom as binary In-Reply-To: References: Message-ID: On Wed, Jan 15, 2014 at 9:17 AM, Stanislav Seletskiy wrote: > > So, as we can see, line 8 is pointed at "erlang:display(A)", but error > was occured on line 9. It can be very confusing while debugging large > modules. I think it's a bug because of it points on invalid line and > with other errors there is no such behaviour. > > Yes, it is a bug. The correction will be included in R17. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jan 16 16:09:07 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 16 Jan 2014 16:09:07 +0100 Subject: [erlang-bugs] Possible Dialyzer bug (reproducible test case) Message-ID: I may be totally off here, but I have a strange bug which I have seen twice now on R16B03, OSX for the Dialyzer. To reproduce it, execute the following steps: # Clone repository and force a specific version ; git clone https://github.com/jlouis/msgpack-erlang.git ; cd msgpack-erlang ; git checkout origin/dialyzer-failure ; make ; make build_plt # Takes about 2 minutes ; make dialyzer Gives the following: =ERROR REPORT==== 16-Jan-2014::15:52:18 === Error in process <0.67.0> with exit value: {function_clause,[{erl_types,unify_lists,[[{c,tuple,[{c,atom,[ext],unknown},{c,atom,[msgpack_term],unknown}],{2,{c,atom,[ext],unknown}}}],[],[],[{c,tuple,[{c,atom,[enable_str],unknown},{c,atom,[true],unknown}],{2,{c,atom... dialyzer: Analysis failed with error: {function_clause,[{erl_types,unify_lists, [[{c,tuple,[...],...}],[],[],[{...}|...],[]], [{file,"erl_types.erl"},{line,2695}]}, {erl_types,t_unify,4,[{file,[...]},{line,...}]}, {erl_types,t_unify,4,[{file,...},{...}]}, {erl_types,t_unify,3,[{...}|...]}, {dialyzer_typesig,solve_subtype,4,[...]}, {dialyzer_typesig,mk_constraint,3,...}, {dialyzer_typesig,state__store_conj,...}, {dialyzer_typesig,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 0.27 secs Removing edges... done in 0.04 secs =ERROR REPORT==== 16-Jan-2014::15:52:18 === Error in process <0.69.0> with exit value: {badarg,[{ets,insert,[790562,[{{msgpack,pack,1},{{c,binary,[8,8],unknown},[{c,union,[none,{c,binary,[8,0],unknown},none,none,{c,list,[{c,union,[none,{c,binary,[8,0],unknown},none,none,{c,list,[any,{c,nil,[],unknown}],unknown... make: *** [dialyzer] Error 1 If you run `git show origin/dialyzer-failure` you have the following patch chunk: diff --git a/include/msgpack.hrl b/include/msgpack.hrl index 6ef046d..4796492 100644 --- a/include/msgpack.hrl +++ b/include/msgpack.hrl @@ -63,8 +63,8 @@ impl = erlang :: erlang | nif, allow_atom = none :: none | pack, %% allows atom when packing enable_str = false :: boolean(), %% true for new spec - ext_packer = undefined :: msgpack_ext_packer(), - ext_unpacker = undefined :: msgpack_ext_unpacker(), + ext_packer = undefined :: undefined | msgpack_ext_packer(), + ext_unpacker = undefined :: undefined | msgpack_ext_unpacker(), original_list = [] :: msgpack_list_options() }). Undoing this patch chunk makes the dialyzer report a slew of warnings, but not fail. Is it possible that someone can try doing the same on another setup to verify the presence/absence of the error? Also preferable on older releases to make a target for bisection. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Fri Jan 17 12:44:43 2014 From: me@REDACTED (Xiao Jia) Date: Fri, 17 Jan 2014 19:44:43 +0800 Subject: [erlang-bugs] internal error in lint_module Message-ID: Hi, I am writing a parse_transform module using erl_syntax_lib:mapfold, but encountered a mysterious error message: z.erl:none: internal error in lint_module; crash reason: {badarg,[{erl_scan,set_attr, [line,function,#Fun], [{file,"erl_scan.erl"},{line,418}]}, {erl_lint,modify_line1,2, [{file,"erl_lint.erl"},{line,3352}]}, {erl_lint,eval_file_attr,2, [{file,"erl_lint.erl"},{line,650}]}, {erl_lint,eval_file_attr,2, [{file,"erl_lint.erl"},{line,651}]}, {erl_lint,eval_file_attr,2, [{file,"erl_lint.erl"},{line,648}]}, {erl_lint,forms,2,[{file,"erl_lint.erl"},{line,608}]}, {erl_lint,module,3,[{file,"erl_lint.erl"},{line,472}]}, {compile,lint_module,1, [{file,"compile.erl"},{line,912}]}]} File z.erl: -module(z). -compile({parse_transform, zt}). -export([f/1]). f(_) -> z. However, this error still occurs even if the module does nothing: -module(zt). -export([parse_transform/2]). parse_transform(AST, _Options) -> [parse(T) || T <- AST]. parse({function, _, _, _, _} = T) -> case erl_syntax_lib:mapfold(fun foobar/2, something, T) of {T1, _} -> T1; _ -> T end; parse(T) -> T. foobar(T, S) -> {T, S}. The two files are compiled as follows $ erlc zt.erl $ erlc -pa . z.erl I am using Mac OS 10.9 and installed Erlang via Homebrew. Both R16B03 and R15B03-1 give this error. I also created a Gist on GitHub with exactly the same information listed above. https://gist.github.com/stfairy/8471800 -- Regards, Xiao Jia From zambal@REDACTED Fri Jan 17 14:08:18 2014 From: zambal@REDACTED (Vincent Siliakus) Date: Fri, 17 Jan 2014 14:08:18 +0100 Subject: [erlang-bugs] Possible bug in file:sendfile/5 In-Reply-To: References: Message-ID: I was wondering if anybody had the time to look in to this, as this seems to be a bug, or at least unexpected behaviour to me and I don't have enough knowledge of BEAM's internals to dive deeper in to this myself? This was my first post to the erlang-bugs mailing list, so if I missed some guidelines how to properly report an issue to this list, please let me know. -vincent On Thu, Dec 12, 2013 at 3:00 PM, Vincent Siliakus wrote: > Hi, > > It seems that file:sendfile/5 in some situations corrupts or unexpectedly > closes the socket it uses. I stumbled up on this while using Elli, a small > but flexible http server (https://github.com/knutin/elli). > > The issue manifests itself when some clients are making single requests (ie. > they close the socket after receiving a response) in a short timespan, where > the response is a file send back to the clients, using file:sendfile/5. Once > in a while, after an acceptor has responded and tries to reuse the > connection and calls gen_tcp:recv/3 again, instead of receiving {error, > closed}, it receives {error, ebadf} > > I created a small example, that imitates Elli's tcp acceptor loop, without > all the http parsing stuff. When running this example I can reliably > reproduce this issue on two systems. > > System one is a dual core Mac Book Pro, running Ubuntu 13.10 and Erlang > 16B03. System two is single core VMWare VM, running Ubuntu 12.04 LTS and > Erlang 15B03. I tried different async-thread settings on both systems (also > disabling async-threads altogether, by using +A 0), which doesn't seem to > make a difference. > > I published the example as a gist at github, which can be found here: > https://gist.github.com/zambal/7927631 > > In my example, sendfile:server/0 creates a listener, with {active, false} > and spawns 10 processes as acceptors on that listening socket. > sendfile:clients/0 spawns 50 clients that are all performing a single > request, after which they close the connection. > > If you run the example and no {error, ebadf} manifests itself, you can > uncomment the timer:sleep(100) call on line 34, as that seems to make it > more likely that the error will popup. Note also that you can replace the > sendfile call with an alternative implementation that uses file:read_file > and gen_tcp:send, by changing the sendfile(Socket, Path) call with > sendfile2(Socket, Path) on line 32. Using the alternative implementation, I > can not reproduce the issue and everything seems to work as expected. > > > -vincent From lukas@REDACTED Fri Jan 17 14:24:52 2014 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 17 Jan 2014 14:24:52 +0100 Subject: [erlang-bugs] Possible bug in file:sendfile/5 In-Reply-To: References: Message-ID: <52D92F24.4060505@erlang.org> Hello, Sorry for not replying before, I thought I had, but apparently not. I will have a look at this before the next release and try to get a fix in. I think that I just have to mask the error from ebadf to closed in this scenario which should be simple enough. Thanks for a great and very thorough bug report! Lukas On 17/01/14 14:08, Vincent Siliakus wrote: > I was wondering if anybody had the time to look in to this, as this > seems to be a bug, or at least unexpected behaviour to me and I don't > have enough knowledge of BEAM's internals to dive deeper in to this > myself? > > This was my first post to the erlang-bugs mailing list, so if I missed > some guidelines how to properly report an issue to this list, please > let me know. > > -vincent > > On Thu, Dec 12, 2013 at 3:00 PM, Vincent Siliakus wrote: >> Hi, >> >> It seems that file:sendfile/5 in some situations corrupts or unexpectedly >> closes the socket it uses. I stumbled up on this while using Elli, a small >> but flexible http server (https://github.com/knutin/elli). >> >> The issue manifests itself when some clients are making single requests (ie. >> they close the socket after receiving a response) in a short timespan, where >> the response is a file send back to the clients, using file:sendfile/5. Once >> in a while, after an acceptor has responded and tries to reuse the >> connection and calls gen_tcp:recv/3 again, instead of receiving {error, >> closed}, it receives {error, ebadf} >> >> I created a small example, that imitates Elli's tcp acceptor loop, without >> all the http parsing stuff. When running this example I can reliably >> reproduce this issue on two systems. >> >> System one is a dual core Mac Book Pro, running Ubuntu 13.10 and Erlang >> 16B03. System two is single core VMWare VM, running Ubuntu 12.04 LTS and >> Erlang 15B03. I tried different async-thread settings on both systems (also >> disabling async-threads altogether, by using +A 0), which doesn't seem to >> make a difference. >> >> I published the example as a gist at github, which can be found here: >> https://gist.github.com/zambal/7927631 >> >> In my example, sendfile:server/0 creates a listener, with {active, false} >> and spawns 10 processes as acceptors on that listening socket. >> sendfile:clients/0 spawns 50 clients that are all performing a single >> request, after which they close the connection. >> >> If you run the example and no {error, ebadf} manifests itself, you can >> uncomment the timer:sleep(100) call on line 34, as that seems to make it >> more likely that the error will popup. Note also that you can replace the >> sendfile call with an alternative implementation that uses file:read_file >> and gen_tcp:send, by changing the sendfile(Socket, Path) call with >> sendfile2(Socket, Path) on line 32. Using the alternative implementation, I >> can not reproduce the issue and everything seems to work as expected. >> >> >> -vincent > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From jesper.louis.andersen@REDACTED Fri Jan 17 15:51:41 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 17 Jan 2014 15:51:41 +0100 Subject: [erlang-bugs] Possible Dialyzer bug (reproducible test case) In-Reply-To: References: Message-ID: I posted this as a gist as well, https://gist.github.com/jlouis/8456179 There are many valuable comments in there. It turns out that this is a proper dialyzer error where it crashes, on different environments. It also crashes in R16B02, so the regression is older than that. On Thu, Jan 16, 2014 at 4:09 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > I may be totally off here, but I have a strange bug which I have seen > twice now on R16B03, OSX for the Dialyzer. To reproduce it, execute the > following steps: > > # Clone repository and force a specific version > ; git clone https://github.com/jlouis/msgpack-erlang.git > ; cd msgpack-erlang > ; git checkout origin/dialyzer-failure > ; make > ; make build_plt # Takes about 2 minutes > ; make dialyzer > > Gives the following: > > =ERROR REPORT==== 16-Jan-2014::15:52:18 === > Error in process <0.67.0> with exit value: > {function_clause,[{erl_types,unify_lists,[[{c,tuple,[{c,atom,[ext],unknown},{c,atom,[msgpack_term],unknown}],{2,{c,atom,[ext],unknown}}}],[],[],[{c,tuple,[{c,atom,[enable_str],unknown},{c,atom,[true],unknown}],{2,{c,atom... > > > dialyzer: Analysis failed with error: > {function_clause,[{erl_types,unify_lists, > [[{c,tuple,[...],...}],[],[],[{...}|...],[]], > [{file,"erl_types.erl"},{line,2695}]}, > {erl_types,t_unify,4,[{file,[...]},{line,...}]}, > {erl_types,t_unify,4,[{file,...},{...}]}, > {erl_types,t_unify,3,[{...}|...]}, > {dialyzer_typesig,solve_subtype,4,[...]}, > {dialyzer_typesig,mk_constraint,3,...}, > {dialyzer_typesig,state__store_conj,...}, > {dialyzer_typesig,...}]} > Last messages in the log cache: > Reading files and computing callgraph... done in 0.27 secs > Removing edges... done in 0.04 secs > > =ERROR REPORT==== 16-Jan-2014::15:52:18 === > Error in process <0.69.0> with exit value: > {badarg,[{ets,insert,[790562,[{{msgpack,pack,1},{{c,binary,[8,8],unknown},[{c,union,[none,{c,binary,[8,0],unknown},none,none,{c,list,[{c,union,[none,{c,binary,[8,0],unknown},none,none,{c,list,[any,{c,nil,[],unknown}],unknown... > > make: *** [dialyzer] Error 1 > > If you run `git show origin/dialyzer-failure` you have the following patch > chunk: > > diff --git a/include/msgpack.hrl b/include/msgpack.hrl > index 6ef046d..4796492 100644 > --- a/include/msgpack.hrl > +++ b/include/msgpack.hrl > @@ -63,8 +63,8 @@ > impl = erlang :: erlang | nif, > allow_atom = none :: none | pack, %% allows atom when packing > enable_str = false :: boolean(), %% true for new spec > - ext_packer = undefined :: msgpack_ext_packer(), > - ext_unpacker = undefined :: msgpack_ext_unpacker(), > + ext_packer = undefined :: undefined | msgpack_ext_packer(), > + ext_unpacker = undefined :: undefined | msgpack_ext_unpacker(), > original_list = [] :: msgpack_list_options() > }). > > Undoing this patch chunk makes the dialyzer report a slew of warnings, but > not fail. > > Is it possible that someone can try doing the same on another setup to > verify the presence/absence of the error? Also preferable on older releases > to make a target for bisection. > > > -- > J. > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile@REDACTED Tue Jan 21 17:09:37 2014 From: emile@REDACTED (Emile Joubert) Date: Tue, 21 Jan 2014 16:09:37 +0000 Subject: [erlang-bugs] SSL secure renegotiation not advertised Message-ID: <52DE9BC1.6020209@rabbitmq.com> Hi, A RabbitMQ customer has reported an issue with secure renegotiation of SSL connections on versions of Erlang from R16B02. On earlier versions the server advertises support for secure connections with the relevant extension, e.g. OpenSSL reports TLS server extension "renegotiation info" (id=65281), len=1 ... Secure Renegotiation IS supported On R16B02 and R16B03 the extension is missing, end OpenSSL reports: TLS server extension "elliptic curves" (id=10), len=52 TLS server extension "EC point formats" (id=11), len=2 ... Secure Renegotiation IS NOT supported Setting {secure_renegotiate, boolean()} makes no difference. Is this a bug or is there another way to get the server to be recognised as RFC5746-compliant? Emile RabbitMQ From kostis@REDACTED Tue Jan 21 20:30:45 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 21 Jan 2014 21:30:45 +0200 Subject: [erlang-bugs] Possible Dialyzer bug (reproducible test case) In-Reply-To: References: Message-ID: <52DECAE5.8010300@cs.ntua.gr> On 01/16/2014 05:09 PM, Jesper Louis Andersen wrote: > I may be totally off here, but I have a strange bug which I have seen > twice now on R16B03, OSX for the Dialyzer. To reproduce it, execute the > following steps: > > # Clone repository and force a specific version > ; git clone https://github.com/jlouis/msgpack-erlang.git > ; cd msgpack-erlang Thanks for the bug report. It's caused by a call in msgpack_term with options defined by -define(TERM_OPTION, [{enable_str,true},{ext,?MODULE},{allow_atom,none}]). but the msgpack:options() type does not include an {ext,module()} type in its specification. So this should be fixed in the code. However, dialyzer should of course not crash, even (especially?) on erroneous code. > Gives the following: > > =ERROR REPORT==== 16-Jan-2014::15:52:18 === > Error in process <0.67.0> with exit value: > {function_clause,[{erl_types,unify_lists,[[{c,tuple,[{c,atom,[ext],unknown},{c,atom,[msgpack_term],unknown}],{2,{c,atom,[ext],unknown}}}],[],[],[{c,tuple,[{c,atom,[enable_str],unknown},{c,atom,[true],unknown}],{2,{c,atom... > > > > dialyzer: Analysis failed with error: > {function_clause,[{erl_types,unify_lists, > [[{c,tuple,[...],...}],[],[],[{...}|...],[]], > [{file,"erl_types.erl"},{line,2695}]}, > {erl_types,t_unify,4,[{file,[...]},{line,...}]}, A preliminary patch which fixes this problem and avoids the crash is attached below. A more complete patch will hopefully make it in R17B. Thanks again for reporting the bug, Kostis -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_types.patch Type: text/x-patch Size: 1131 bytes Desc: not available URL: From ingela.anderton.andin@REDACTED Wed Jan 22 12:34:49 2014 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Wed, 22 Jan 2014 12:34:49 +0100 Subject: [erlang-bugs] SSL secure renegotiation not advertised In-Reply-To: <52DE9BC1.6020209@rabbitmq.com> References: <52DE9BC1.6020209@rabbitmq.com> Message-ID: <52DFACD9.8080503@erix.ericsson.se> Hi! Thank you for reporting this, the following patch should solve the problem! Regards Ingela Erlang/OTP team - Ericsson AB diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl index f5c0034..1a5bcee 100644 --- a/lib/ssl/src/ssl_handshake.erl +++ b/lib/ssl/src/ssl_handshake.erl @@ -56,7 +56,7 @@ %% Extensions handling -export([client_hello_extensions/6, - handle_client_hello_extensions/8, %% Returns server hello extensions + handle_client_hello_extensions/9, %% Returns server hello extensions handle_server_hello_extensions/9, select_curve/2 ]). @@ -1088,7 +1088,7 @@ certificate_authorities_from_db(CertDbHandle, CertDbRef) -> %%-------------Extension handling -------------------------------- -handle_client_hello_extensions(RecordCB, Random, +handle_client_hello_extensions(RecordCB, Random, CipherSuites, #hello_extensions{renegotiation_info = Info, srp = SRP, ec_point_formats = ECCFormat, @@ -1098,7 +1098,7 @@ handle_client_hello_extensions(RecordCB, Random, ConnectionStates0, Renegotiation) -> Session = handle_srp_extension(SRP, Session0), ConnectionStates = handle_renegotiation_extension(server, RecordCB, Version, Info, - Random, CipherSuite, Compression, + Random, CipherSuite, CipherSuites, Compression, ConnectionStates0, Renegotiation, SecureRenegotation), ProtocolsToAdvertise = handle_next_protocol_extension(NextProtocolNegotiation, Renegotiation, Opts), @@ -1117,7 +1117,8 @@ handle_server_hello_extensions(RecordCB, Random, CipherSuite, Compression, #ssl_options{secure_renegotiate = SecureRenegotation, next_protocol_selector = NextProtoSelector}, ConnectionStates0, Renegotiation) -> - ConnectionStates = handle_renegotiation_extension(client, RecordCB, Version, Info, Random, CipherSuite, + ConnectionStates = handle_renegotiation_extension(client, RecordCB, Version, Info, Random, + CipherSuite, undefined, Compression, ConnectionStates0, Renegotiation, SecureRenegotation), case handle_next_protocol(NextProtocolNegotiation, NextProtoSelector, Renegotiation) of @@ -1415,11 +1416,11 @@ calc_master_secret({3,0}, _PrfAlgo, PremasterSecret, ClientRandom, ServerRandom) calc_master_secret({3,_}, PrfAlgo, PremasterSecret, ClientRandom, ServerRandom) -> tls_v1:master_secret(PrfAlgo, PremasterSecret, ClientRandom, ServerRandom). -handle_renegotiation_extension(Role, RecordCB, Version, Info, Random, CipherSuite, Compression, +handle_renegotiation_extension(Role, RecordCB, Version, Info, Random, CipherSuite, CipherSuites, Compression, ConnectionStates0, Renegotiation, SecureRenegotation) -> case handle_renegotiation_info(RecordCB, Role, Info, ConnectionStates0, Renegotiation, SecureRenegotation, - [CipherSuite]) of + CipherSuites) of {ok, ConnectionStates} -> hello_pending_connection_states(RecordCB, Role, Version, diff --git a/lib/ssl/src/tls_handshake.erl b/lib/ssl/src/tls_handshake.erl index 003614b..1ec1e67 100644 --- a/lib/ssl/src/tls_handshake.erl +++ b/lib/ssl/src/tls_handshake.erl @@ -52,9 +52,9 @@ client_hello(Host, Port, ConnectionStates, Pending = ssl_record:pending_connection_state(ConnectionStates, read), SecParams = Pending#connection_state.security_parameters, CipherSuites = ssl_handshake:available_suites(UserSuites, Version), - - Extensions = ssl_handshake:client_hello_extensions(Host, Version, CipherSuites, - SslOpts, ConnectionStates, Renegotiation), + Extensions = ssl_handshake:client_hello_extensions(Host, Version, + CipherSuites, + SslOpts, ConnectionStates, Renegotiation), Id = ssl_session:client_id({Host, Port, SslOpts}, Cache, CacheCb, OwnCert), @@ -87,8 +87,8 @@ hello(#server_hello{server_version = Version, random = Random, ConnectionStates0, Renegotiation) -> case tls_record:is_acceptable_version(Version, SupportedVersions) of true -> - handle_hello_extensions(Version, SessionId, Random, CipherSuite, - Compression, HelloExt, SslOpt, ConnectionStates0, Renegotiation); + handle_server_hello_extensions(Version, SessionId, Random, CipherSuite, + Compression, HelloExt, SslOpt, ConnectionStates0, Renegotiation); false -> ?ALERT_REC(?FATAL, ?PROTOCOL_VERSION) end; @@ -113,9 +113,9 @@ hello(#client_hello{client_version = ClientVersion, no_suite -> ?ALERT_REC(?FATAL, ?INSUFFICIENT_SECURITY); _ -> - handle_hello_extensions(Version, Type, Random, HelloExt, - SslOpts, Session1, ConnectionStates0, - Renegotiation) + handle_client_hello_extensions(Version, Type, Random, CipherSuites, HelloExt, + SslOpts, Session1, ConnectionStates0, + Renegotiation) end; false -> ?ALERT_REC(?FATAL, ?PROTOCOL_VERSION) @@ -217,8 +217,10 @@ enc_handshake(HandshakeMsg, Version) -> ssl_handshake:encode_handshake(HandshakeMsg, Version). -handle_hello_extensions(Version, Type, Random, HelloExt, SslOpts, Session0, ConnectionStates0, Renegotiation) -> - try ssl_handshake:handle_client_hello_extensions(tls_record, Random, HelloExt, Version, SslOpts, +handle_client_hello_extensions(Version, Type, Random, CipherSuites, + HelloExt, SslOpts, Session0, ConnectionStates0, Renegotiation) -> + try ssl_handshake:handle_client_hello_extensions(tls_record, Random, CipherSuites, + HelloExt, Version, SslOpts, Session0, ConnectionStates0, Renegotiation) of {Session, ConnectionStates, ServerHelloExt} -> {Version, {Type, Session}, ConnectionStates, ServerHelloExt} @@ -227,7 +229,7 @@ handle_hello_extensions(Version, Type, Random, HelloExt, SslOpts, Session0, Conn end. -handle_hello_extensions(Version, SessionId, Random, CipherSuite, +handle_server_hello_extensions(Version, SessionId, Random, CipherSuite, Compression, HelloExt, SslOpt, ConnectionStates0, Renegotiation) -> case ssl_handshake:handle_server_hello_extensions(tls_record, Random, CipherSuite, Compression, HelloExt, Version, diff --git a/lib/ssl/test/ssl_basic_SUITE.erl b/lib/ssl/test/ssl_basic_SUITE.erl index bc7e68a..1006b23 100644 On 01/21/2014 05:09 PM, Emile Joubert wrote: > > Hi, > > A RabbitMQ customer has reported an issue with secure renegotiation of > SSL connections on versions of Erlang from R16B02. On earlier versions > the server advertises support for secure connections with the relevant > extension, e.g. OpenSSL reports > > TLS server extension "renegotiation info" (id=65281), len=1 > ... > Secure Renegotiation IS supported > > On R16B02 and R16B03 the extension is missing, end OpenSSL reports: > > TLS server extension "elliptic curves" (id=10), len=52 > TLS server extension "EC point formats" (id=11), len=2 > ... > Secure Renegotiation IS NOT supported > > Setting {secure_renegotiate, boolean()} makes no difference. Is this a > bug or is there another way to get the server to be recognised as > RFC5746-compliant? > > > > > Emile > RabbitMQ > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Ken.Fuchs@REDACTED Wed Jan 22 21:02:01 2014 From: Ken.Fuchs@REDACTED (Ken.Fuchs@REDACTED) Date: Wed, 22 Jan 2014 14:02:01 -0600 Subject: [erlang-bugs] Documentation error: doc/getting_started/seq_prog.html Message-ID: file:///C:/Program%20Files/erl5.10.4/doc/getting_started/seq_prog.html The last paragraph of section 2.5 contains the phrase "string date type". This phrase should be "string data type". date -> data. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Thu Jan 23 23:41:22 2014 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Thu, 23 Jan 2014 23:41:22 +0100 Subject: [erlang-bugs] Compiler internal error on "case {}" Message-ID: <52E19A92.8050604@trifork.com> Hi all, I'd like to report a bug in the Erlang (R16B) compiler - it crashes on code like foo(X) -> case {X+1} of 1 -> ok end. (not that that code makes any sense anyway, of course). The error message is: Function: foo/1 erlcbug.erl:none: internal error in beam_except; crash reason: {{case_clause, {'EXIT', {{badmatch, [{set,[],[],{line,[{location,"erlcbug.erl",4}]}}, {set, [{x,0}], [{x,0},{integer,1}], {alloc,1,{gc_bif,'+',{f,0}}}}, {set,[],[],{alloc,1,{nozero,nostack,5,[]}}}, {set,[{x,1}],[],{put_tuple,1}}, {set,[],[{x,0}],put}]}, [{beam_except,fix_block,2, [{file,"beam_except.erl"},{line,138}]}, {beam_except,translate_exception,4, [{file,"beam_except.erl"},{line,130}]}, {beam_except,dig_out,2, [{file,"beam_except.erl"},{line,98}]}, {beam_except,translate_1,5, [{file,"beam_except.erl"},{line,78}]}, {beam_except,function,1, [{file,"beam_except.erl"},{line,41}]}, {beam_except,'-module/2-lc$^0/1-0-',1, [{file,"beam_except.erl"},{line,36}]}, {beam_except,module,2, [{file,"beam_except.erl"},{line,36}]}, {compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,469}]}]}}}, [{compile,'-select_passes/2-anonymous-2-',2, [{file,"compile.erl"},{line,469}]}, {compile,'-internal_comp/4-anonymous-1-',2, [{file,"compile.erl"},{line,269}]}, {compile,fold_comp,3,[{file,"compile.erl"},{line,287}]}, {compile,internal_comp,4,[{file,"compile.erl"},{line,271}]}, {compile,internal,3,[{file,"compile.erl"},{line,246}]}]} As for narrowing down the cause and extent, I can report that all of the variants bar(X) -> case {X} of 1 -> ok end. baz(X) -> case {X+1} of {1} -> ok end. quux(X) -> case {ext:f(X)} of 1 -> ok end. supercalifragilisticexpialidocious(X) -> case {[X]} of 1 -> ok end. compile just fine, while antidisestablishmentarianism(X) -> case {-X} of 1 -> ok end. baz2(X) -> case {X+1} of {1,2} -> ok end. also trigger the bug. (So apart from a tuple type mismatch, apparently a unary or binary operation must be included; the original triggering example featured "band".) Regards, Erik S?e S?rensen -- Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C | www.trifork.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.zegenhagen@REDACTED Fri Jan 24 10:41:27 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Fri, 24 Jan 2014 10:41:27 +0100 Subject: [erlang-bugs] Error in SNMP TAddress type handling Message-ID: <1390556487.30672.16.camel@ax-sze> Dear all, Erlang's SNMP implementation errorneously handles the TAddress type used in, e.g. SNMP-TARGET-MIB::snmpTargetAddrTAddress and SNMP-COMMUNITY-MIB::snmpTargetAddrTMask for IPv6 addresses. The MIB says that TAddress is of base type OCTET STRING. For IPv6 addresses, however, the current implementation in erlang expects a list of 8 integers in range 0 ... 0xFFFF as IP address (plus 2 bytes for the port number) instead of the required list of 16 integers in range 0 ... 0xFF. Since snmpTargetAddrTable and snmpTargetAddrExtTable (which include the mentioned objects) are used for managing SNMP trap receivers, this bug is particularly nasty as it prevents managing the trap receiver table via SNMP for IPv6. Any attempt to read from or write to snmpTargetAddrTable with IPv6 addresses result in errors due to the datatype mismatch. Functions that need fixing are: * snmpa_mpd.erl:transform_taddr() which transforms the MIB values to IP addresses when sending traps * snmp_conf:check_taddress() which is used to validate TAddress types received via SNMP set requests * snmp_conf:check_ip() which is used to validate snmpTargetAddrTable data from config files. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From stefan.zegenhagen@REDACTED Fri Jan 24 10:45:06 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Fri, 24 Jan 2014 10:45:06 +0100 Subject: [erlang-bugs] Bug in SNMP-COMMUNITY-MIB implementation Message-ID: <1390556706.31834.1.camel@ax-sze> Dear all, there is a bug in SNMP-COMMUNITY-MIB that prevents IPv6 address masks to be configured in snmpTargetAddrTMask via SNMP. The current implementation of the function that verifies set requests to snmpTargetAddrTMask calls snmp_conf:check_taddress/1 which forces a check for a valid IP address. The function should instead respect snmpTargetAddrTDomain from the same table row and call snmp_conf:check_taddress/2 instead, which would allow it to be used with IPv6 addresses as well. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From stefan.zegenhagen@REDACTED Fri Jan 24 11:10:55 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Fri, 24 Jan 2014 11:10:55 +0100 Subject: [erlang-bugs] IPv6 problems in erlang's SNMP stack Message-ID: <1390558255.31834.17.camel@ax-sze> Dear all, First problem: I found no easy way to pass the "inet6" socket option into erlang's snmpa_net_if implementation to open the UDP socket in IPv6 mode. Such an option would be required to convince erlang's SNMP stack to talk IPv6. Second problem: when a socket is opened in IPv6 mode on real dual-stack operating systems, it is possible to query the SNMP agent via IPv4 *AND* IPv6 simultaneously. Sending traps to IPv6 trap receivers works as well, but trap receivers that are configured with IPv4 addresses always fail with an eafnosupport error. SNMP-TARGET-MIB explicitly allows trap receivers to have different IP address types, so I would expect such a feature to be supported. I know that it is possible (the Linux kernel sends out IPv6 packets addressed to "::FFFF:A.B.C.D" via IPv4). I also know that there is a portability problem, since operating systems may behave differently when it comes to dual-stack operation details (its probably best being fixed in the socket driver). Still, this is an important issue for us at the moment and I guess others will face the same problem when IPv6 spreads wider. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From bjorn@REDACTED Fri Jan 24 16:03:05 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 24 Jan 2014 16:03:05 +0100 Subject: [erlang-bugs] Compiler internal error on "case {}" In-Reply-To: <52E19A92.8050604@trifork.com> References: <52E19A92.8050604@trifork.com> Message-ID: On Thu, Jan 23, 2014 at 11:41 PM, Erik S?e S?rensen wrote: > Hi all, > I'd like to report a bug in the Erlang (R16B) compiler - it crashes on > code like > > foo(X) -> > case {X+1} of > 1 -> ok > end. > > Thanks! We will fix it in R17. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Fuchs@REDACTED Fri Jan 24 23:55:19 2014 From: Ken.Fuchs@REDACTED (Ken.Fuchs@REDACTED) Date: Fri, 24 Jan 2014 16:55:19 -0600 Subject: [erlang-bugs] Documentation error: file:///C:/Program%20Files/erl5.10.4/doc/getting_started/seq_prog.html: Section 2.12 Message-ID: Section 2.12 begins with the sentence: Built in functions BIFs are functions which for some reason is built in to the Erlang virtual machine. BIFs often implement functionality that is impossible to implement in Erlang or is to inefficient to implement in Erlang. The phrase "to inefficient" should be "too inefficient"; to -> too. From lukas@REDACTED Mon Jan 27 11:09:00 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 27 Jan 2014 11:09:00 +0100 Subject: [erlang-bugs] Documentation error: file:///C:/Program%20Files/erl5.10.4/doc/getting_started/seq_prog.html: Section 2.12 In-Reply-To: References: Message-ID: <52E6303C.4000801@erlang.org> Thank you for reporting this bug. It will be fixed in the next release. Lukas On 24/01/14 23:55, Ken.Fuchs@REDACTED wrote: > Section 2.12 begins with the sentence: > > Built in functions BIFs are functions which for some reason is built in to the Erlang virtual machine. BIFs often implement functionality that is impossible to implement in Erlang or is to inefficient to implement in Erlang. > > The phrase "to inefficient" should be "too inefficient"; to -> too. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From lukas@REDACTED Mon Jan 27 11:11:53 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 27 Jan 2014 11:11:53 +0100 Subject: [erlang-bugs] Possible bug in file:sendfile/5 In-Reply-To: <52D92F24.4060505@erlang.org> References: <52D92F24.4060505@erlang.org> Message-ID: <52E630E9.30502@erlang.org> This issue has been identified and a fix will be in place for the next release. The bug only triggers if you have the socket in passive mode, so as a workaround for older releases you can set the socket in active mode before calling file:sendfile. Lukas On 17/01/14 14:24, Lukas Larsson wrote: > Hello, > > Sorry for not replying before, I thought I had, but apparently not. > > I will have a look at this before the next release and try to get a > fix in. I think that I just have to mask the error from ebadf to > closed in this scenario which should be simple enough. > > Thanks for a great and very thorough bug report! > > Lukas > > On 17/01/14 14:08, Vincent Siliakus wrote: >> I was wondering if anybody had the time to look in to this, as this >> seems to be a bug, or at least unexpected behaviour to me and I don't >> have enough knowledge of BEAM's internals to dive deeper in to this >> myself? >> >> This was my first post to the erlang-bugs mailing list, so if I missed >> some guidelines how to properly report an issue to this list, please >> let me know. >> >> -vincent >> >> On Thu, Dec 12, 2013 at 3:00 PM, Vincent Siliakus >> wrote: >>> Hi, >>> >>> It seems that file:sendfile/5 in some situations corrupts or >>> unexpectedly >>> closes the socket it uses. I stumbled up on this while using Elli, a >>> small >>> but flexible http server (https://github.com/knutin/elli). >>> >>> The issue manifests itself when some clients are making single >>> requests (ie. >>> they close the socket after receiving a response) in a short >>> timespan, where >>> the response is a file send back to the clients, using >>> file:sendfile/5. Once >>> in a while, after an acceptor has responded and tries to reuse the >>> connection and calls gen_tcp:recv/3 again, instead of receiving {error, >>> closed}, it receives {error, ebadf} >>> >>> I created a small example, that imitates Elli's tcp acceptor loop, >>> without >>> all the http parsing stuff. When running this example I can reliably >>> reproduce this issue on two systems. >>> >>> System one is a dual core Mac Book Pro, running Ubuntu 13.10 and Erlang >>> 16B03. System two is single core VMWare VM, running Ubuntu 12.04 LTS >>> and >>> Erlang 15B03. I tried different async-thread settings on both >>> systems (also >>> disabling async-threads altogether, by using +A 0), which doesn't >>> seem to >>> make a difference. >>> >>> I published the example as a gist at github, which can be found here: >>> https://gist.github.com/zambal/7927631 >>> >>> In my example, sendfile:server/0 creates a listener, with {active, >>> false} >>> and spawns 10 processes as acceptors on that listening socket. >>> sendfile:clients/0 spawns 50 clients that are all performing a single >>> request, after which they close the connection. >>> >>> If you run the example and no {error, ebadf} manifests itself, you can >>> uncomment the timer:sleep(100) call on line 34, as that seems to >>> make it >>> more likely that the error will popup. Note also that you can >>> replace the >>> sendfile call with an alternative implementation that uses >>> file:read_file >>> and gen_tcp:send, by changing the sendfile(Socket, Path) call with >>> sendfile2(Socket, Path) on line 32. Using the alternative >>> implementation, I >>> can not reproduce the issue and everything seems to work as expected. >>> >>> >>> -vincent >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From lukas@REDACTED Mon Jan 27 11:13:08 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 27 Jan 2014 11:13:08 +0100 Subject: [erlang-bugs] Documentation error: doc/getting_started/seq_prog.html In-Reply-To: References: Message-ID: <52E63134.9000205@erlang.org> Thank you for reporting this bug. It will be fixed in the next release. Lukas On 22/01/14 21:02, Ken.Fuchs@REDACTED wrote: > _file:///C:/Program%20Files/erl5.10.4/doc/getting_started/seq_prog.html_ > The last paragraph of section 2.5 contains the phrase "string date > type". This phrase should be "string data type". date -> data. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Jan 27 15:22:14 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 27 Jan 2014 15:22:14 +0100 Subject: [erlang-bugs] file:sendfile/5 bug and possible DOS attack In-Reply-To: <52662867.7000600@erlang.org> References: <526525CF.5020202@capflam.org> <52662867.7000600@erlang.org> Message-ID: <52E66B96.2070407@erlang.org> I've now implemented the fix I proposed for this. You can view the fix here: https://github.com/garazdawi/otp/tree/lukas/erts/sendfile_no_async_pool. If the tests pass I will merge it asap. Lukas On 22/10/13 09:25, Lukas Larsson wrote: > Hello Christopher, > > The reason behind favoring the async threads is that non-blocking > sendfile calls on some OSs sometimes behave incorrectly. Unfortunately > at the moment I cannot remember which OS it was, but it is none of the > majorly used ones. > > It is of course not good that this feature opens up the VM for that > kind of attack. > > My suggestion of a fix would be to add an option to sendfile/5 that > specifies whether async threads should be used or not, and default > this to false. This leaves the choice up to the user of sendfile/5 and > defaults to be safe from attacks. > > Thanks for reporting this quite serious flaw in the sendfile > implementation! > > Lukas > > On 21/10/13 15:02, Christopher Faulet wrote: >> Hi, >> >> This summer, at my company, we encountered a problem that leads to the >> VM hanging. After some painful investigation, we found that the problem >> came from thefile:sendfile/5 function. >> >> When async threads are enabled, during a call tofile:sendfile/5 the >> efile driver sets the TCP socket in blocking mode. So an unresponsive >> client can block the sendfile() syscall, thus blocking an async thread. >> With few unresponsive clients, all async threads can be blocked and the >> VM hangs (no more I/O are possible). >> >> I attached 2 escripts to reproduce the bug: >> >> * server - listen on a socket and wait a client connection to send a >> large file using gen_tcp:send orfile:sendfile: >> >> $> ./server 1234 /path/to/bigfile send >> or >> $> ./server 1234 /path/to/bigfile sendfile >> >> * slow_client - open a connection on the server and read incoming data >> with a sleep of 10 seconds between each read: >> >> $> ./slow_client 127.0.0.1 1234 >> >> The server is started with 1 async thread. Every 2 seconds the server >> tries to read the file info. When "sendfile" method is used, the call to >> file:read_file_info/1 is blocked; all I/O are blocked, the VM is out. >> When async threads are disabled or when the "send" method is used, there >> is no problem. The file is sent (slowly) and the VM is still responsive. >> >> So it is very easy to do a DOS attack on systems that use >> file:sendfile/5 with async threads enabled. The problem comes from a >> design choice of the efile driver. I have no solution to propose, but it >> could be a good idea to add a warning in the documentation of >> file:sendfile/5 (especially that the documentation encourages the use of >> async threads). >> >> Regards, >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From argos83@REDACTED Mon Jan 27 12:10:13 2014 From: argos83@REDACTED (Seba) Date: Mon, 27 Jan 2014 12:10:13 +0100 Subject: [erlang-bugs] FTP command injection vulnerability in module "ftp" Message-ID: Hi! There is an FTP Command Injection vulnerability in the "ftp" module. All those functions that write any string argument in the control socket seem to be vulnerable: user/3 user/4 account/2 cd/2 ls/2 nlist/2 rename/3 delete/2 mkdir/2 rmdir/2 recv/2 recv/3 recv_bin/2, recv_chunk_start/2 send/3 send_bin/3 send_chunk_start/2 append_chunk_start/2 append/2 append/3 append_bin/3 Vulnerability Description ------------------------- An FTP communication consists of two channels: * A TCP control channel: Text-based, and served by the FTP Server. * A TCP data channel: Which is created either by the FTP Client or the FTP Server depending on data being transmitted using active or passive mode. The control channel works in a request-response fashion. Each command is issued by the client in a single line (ending with a carriage return and a new line: \r\n). By injecting a \r\n sequence followed by a new command in a function argument you get the ftp module to write the whole string in the socket. E.g. the following erlang shell session: 1> inets:start(). ok 2> {ok, Pid} = inets:start(ftpc, [{host, "127.0.0.1"}]). {ok,<0.46.0>} 3> ftp:user(Pid, "anonymous", "password\r\nCWD pub\r\nMKD new_dir"). ok 4> ftp:cd(Pid, "/pub\r\nRMD new_dir\r\nPASV"). ok Generates the following FTP session: FTP command: Client "127.0.0.1", "USER anonymous" FTP response: Client "127.0.0.1", "331 Please specify the password." FTP command: Client "127.0.0.1", "PASS " FTP response: Client "127.0.0.1", "230 Login successful." FTP command: Client "127.0.0.1", "CWD pub" FTP response: Client "127.0.0.1", "250 Directory successfully changed." FTP command: Client "127.0.0.1", "MKD new_dir" FTP response: Client "127.0.0.1", "257 "/pub/new_dir" created" FTP command: Client "127.0.0.1", "CWD /pub" FTP response: Client "127.0.0.1", "250 Directory successfully changed." FTP command: Client "127.0.0.1", "RMD new_dir" FTP response: Client "127.0.0.1", "250 Remove directory operation successful." FTP command: Client "127.0.0.1", "PASV" FTP response: Client "127.0.0.1", "227 Entering Passive Mode (127,0,0,1,130,161)." Attack Scenario Example ----------------------- A web server allow users to navigate and download documents. Internally the web server connects to a private ftp server using OTP "ftp" module. An attacker might take advantage of the vulnerability to execute actions that aren't supposed to be exposed. E.g. delete a directory by requesting: http://www.example.com/list_dir.yaws?dir=/docs/%0d%0aRMD+/docs Tested on --------- - R15B03 - Ubuntu 12.04 x86_64 - FTP Sever: vsftpd Fixing ------ String arguments used to create the command request should be sanitized first (by removing "\r" and "\n"). Sebasti?n Tello From watson.timothy@REDACTED Mon Jan 27 17:24:03 2014 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 27 Jan 2014 16:24:03 +0000 Subject: [erlang-bugs] Strange application shutdown deadlock In-Reply-To: References: <20130524144546.GB14817@ferdair.local> <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> Message-ID: Hi Siri, Did this bug make it into the latest release? I didn't see anything in the release notes. Cheers, Tim On 19 June 2013 10:47, Siri Hansen wrote: > Hi Tim - I'm so sorry for the long delay here. I agree that this is a bug > in the application master and I have written a ticket for it so it will be > prioritized into out backlog. > Thanks for the report! > Regards > /siri > > > 2013/5/29 Tim Watson > >> Any word from the OTP folks on this one? >> >> On 24 May 2013, at 18:41, Tim Watson wrote: >> >> > Gah, sorry folks - this has nothing to do with release handling, that >> was a red herring. Someone just pointed out that the call to get_child >> originates in a status check in our code. >> > >> > This still looks like a bug to me though, since if you're going to >> handle "other" messages in terminate_loop you ought to ensure they can't >> deadlock the vm's shutdown sequence. >> > >> > Cheers, >> > Tim >> > >> > On 24 May 2013, at 15:45, Fred Hebert wrote: >> > >> >> Quick question: are you running a release? >> >> >> >> If so, last time I've seen deadlocks like that was solved by making >> sure >> >> *all* my applications did depend on stdlib and kernel in their app >> file. >> >> When I skipped them, sometimes I'd find that things would lock up. >> >> >> >> My guess was that dependencies from stdlib or kernel got unloaded >> before >> >> my app and broke something, but I'm not sure -- In my case, I wasn't >> >> able to inspect the node as it appeared to be 100% blocked. >> >> >> >> Adding the apps ended up fixing the problem on the next shutdown. I'm >> >> not sure if it might be a good fix for you, but it's a stab in the >> dark, >> >> >> >> Regards, >> >> Fred. >> >> >> >> On 05/24, Tim Watson wrote: >> >>> We came across this at a customer's site, where one of the nodes was >> apparently in the process of stopping and had been in that state for at >> least 24 hours. The short version is that an application_master appears to >> be stuck waiting for a child pid (is that the X process, or the root >> supervisor?) which is *not* linked to it... >> >>> >> >>> The application controller is in the process of stopping an >> application, during which process a `get_child' message appears to have >> come in to that application's application_master from somewhere - we are >> *not* running appmon, so I'm really confused how this can happen, as the >> only other place where I see (indirect) calls are via the sasl >> release_handler!? At the bottom of this email is a dump for the >> application_controller and the application_master for the app it is trying >> to shut down. I can verify that the pid which the application_master is >> waiting on is definitely not linked to it - i.e., process_info(links, >> AppMasterPid) doesn't contain the process <0.256.0> that the master appears >> to be waiting on. >> >>> >> >>> My reading of the code is that the application_master cannot end up >> in get_child_i unless a get_child request was made which arrives whilst it >> is in its terminate loop. As I said, we're not using appmon, therefore I >> assume this originated in the sasl application's release_handler_1, though >> I'm not sure quite which route would take us there. The relevant bit of >> code in application_master appears to be: >> >>> >> >>> get_child_i(Child) -> >> >>> Child ! {self(), get_child}, >> >>> receive >> >>> {Child, GrandChild, Mod} -> {GrandChild, Mod} >> >>> end. >> >>> >> >>> This in turn originates, I'd guess, in the third receive clause of >> terminate_loop/2. Anyway, should that code not be dealing with a >> potentially dead pid for Child, either by handling links effectively - >> perhaps there is an EXIT signal in the mailbox already which is being >> ignored here in get_child_i/1 - or by some other means? >> >>> >> >>> What follows below is the trace/dump output. Feel free to poke me for >> more info as needed. >> >>> >> >>> Cheers, >> >>> Tim >> >>> >> >>> [TRACE/DUMP] >> >>> >> >>> pid: <6676.7.0> >> >>> registered name: application_controller >> >>> stacktrace: [{application_master,call,2, >> >>> >> [{file,"application_master.erl"},{line,75}]}, >> >>> {application_controller,stop_appl,3, >> >>> >> [{file,"application_controller.erl"}, >> >>> {line,1393}]}, >> >>> {application_controller,handle_call,3, >> >>> >> [{file,"application_controller.erl"}, >> >>> {line,810}]}, >> >>> >> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}] >> >>> ------------------------- >> >>> Program counter: 0x00007f9bf9a53720 (application_master:call/2 + 288) >> >>> CP: 0x0000000000000000 (invalid) >> >>> arity = 0 >> >>> >> >>> 0x00007f9bd7948360 Return addr 0x00007f9bfb97de40 >> (application_controller:stop_appl/3 + 176) >> >>> y(0) #Ref<0.0.20562.258360> >> >>> y(1) #Ref<0.0.20562.258361> >> >>> y(2) [] >> >>> >> >>> 0x00007f9bd7948380 Return addr 0x00007f9bfb973c68 >> (application_controller:handle_call/3 + 1392) >> >>> y(0) temporary >> >>> y(1) rabbitmq_web_dispatch >> >>> >> >>> 0x00007f9bd7948398 Return addr 0x00007f9bf9a600c8 >> (gen_server:handle_msg/5 + 272) >> >>> y(0) >> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >> bytes>>},{default_pass,<<8 >> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >> >>> y(1) rabbitmq_web_dispatch >> >>> y(2) >> [{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}] >> >>> y(3) >> [{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}] >> >>> >> >>> 0x00007f9bd79483c0 Return addr 0x00000000008827d8 (> normally>) >> >>> y(0) application_controller >> >>> y(1) >> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >> bytes>>},{default_pass,<<8 >> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >> >>> y(2) application_controller >> >>> y(3) <0.2.0> >> >>> y(4) {stop_application,rabbitmq_web_dispatch} >> >>> y(5) {<0.5864.275>,#Ref<0.0.20562.258345>} >> >>> y(6) Catch 0x00007f9bf9a600c8 (gen_server:handle_msg/5 + 272) >> >>> ------------------------- >> >>> >> >>> pid: <6676.255.0> >> >>> registered name: none >> >>> stacktrace: [{application_master,get_child_i,1, >> >>> >> [{file,"application_master.erl"},{line,392}]}, >> >>> {application_master,handle_msg,2, >> >>> >> [{file,"application_master.erl"},{line,216}]}, >> >>> {application_master,terminate_loop,2, >> >>> >> [{file,"application_master.erl"},{line,206}]}, >> >>> {application_master,terminate,2, >> >>> >> [{file,"application_master.erl"},{line,227}]}, >> >>> {application_master,handle_msg,2, >> >>> >> [{file,"application_master.erl"},{line,219}]}, >> >>> {application_master,main_loop,2, >> >>> >> [{file,"application_master.erl"},{line,194}]}, >> >>> >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >> >>> ------------------------- >> >>> Program counter: 0x00007f9bf9a570e0 (application_master:get_child_i/1 >> + 120) >> >>> CP: 0x0000000000000000 (invalid) >> >>> arity = 0 >> >>> >> >>> 0x00007f9c1adc3dc8 Return addr 0x00007f9bf9a54eb0 >> (application_master:handle_msg/2 + 280) >> >>> y(0) <0.256.0> >> >>> >> >>> 0x00007f9c1adc3dd8 Return addr 0x00007f9bf9a54d20 >> (application_master:terminate_loop/2 + 520) >> >>> y(0) #Ref<0.0.20562.258362> >> >>> y(1) <0.9596.275> >> >>> y(2) >> {state,<0.256.0>,{appl_data,rabbitmq_web_dispatch,[],undefined,{rabbit_web_dispatch_app,[]},[rabbit_web_dispatch,rabbit_web_dispatch_app,rabbit_web_dispatch_registry,rabbit_web_dispatch_sup,rabbit_web_dispatch_util,rabbit_webmachine],[],infinity,infinity},[],0,<0.29.0>} >> >>> >> >>> 0x00007f9c1adc3df8 Return addr 0x00007f9bf9a55108 >> (application_master:terminate/2 + 192) >> >>> y(0) <0.256.0> >> >>> >> >>> 0x00007f9c1adc3e08 Return addr 0x00007f9bf9a54f70 >> (application_master:handle_msg/2 + 472) >> >>> y(0) [] >> >>> y(1) normal >> >>> >> >>> 0x00007f9c1adc3e20 Return addr 0x00007f9bf9a54a60 >> (application_master:main_loop/2 + 1600) >> >>> y(0) <0.7.0> >> >>> y(1) #Ref<0.0.20562.258360> >> >>> y(2) Catch 0x00007f9bf9a54f70 (application_master:handle_msg/2 + >> 472) >> >>> >> >>> 0x00007f9c1adc3e40 Return addr 0x00007f9bfb969420 >> (proc_lib:init_p_do_apply/3 + 56) >> >>> y(0) <0.7.0> >> >>> >> >>> 0x00007f9c1adc3e50 Return addr 0x00000000008827d8 (> normally>) >> >>> y(0) Catch 0x00007f9bfb969440 (proc_lib:init_p_do_apply/3 + 88) >> >>> ------------------------- >> >>> >> >> >> >> >> >> >> >>> _______________________________________________ >> >>> erlang-bugs mailing list >> >>> erlang-bugs@REDACTED >> >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Tue Jan 28 08:50:10 2014 From: vances@REDACTED (Vance Shipley) Date: Tue, 28 Jan 2014 13:20:10 +0530 Subject: [erlang-bugs] Module attribute `callback' undocumented Message-ID: <20140128075010.GA379@aluminium.local> STDLIB 1.18 deprecated the 'behaviour_info' module attribute in favour of a 'callback' module attribute which is used as a type specification (see OTP-9621). The current documentation doesn't include the new functionality. The Erlang Reference Manual should be updated to reflect the change: http://www.erlang.org/doc/reference_manual/modules.html -- -Vance From erlangsiri@REDACTED Tue Jan 28 11:00:47 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 28 Jan 2014 11:00:47 +0100 Subject: [erlang-bugs] Strange application shutdown deadlock In-Reply-To: References: <20130524144546.GB14817@ferdair.local> <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> Message-ID: Hi Tim, I'm sorry, but this has not made it into the latest release. The reason is that there has been too many other tasks with higher priority. Regards /siri 2014/1/27 Tim Watson > Hi Siri, > > Did this bug make it into the latest release? I didn't see anything in the > release notes. > > Cheers, > Tim > > > > On 19 June 2013 10:47, Siri Hansen wrote: > >> Hi Tim - I'm so sorry for the long delay here. I agree that this is a bug >> in the application master and I have written a ticket for it so it will be >> prioritized into out backlog. >> Thanks for the report! >> Regards >> /siri >> >> >> 2013/5/29 Tim Watson >> >>> Any word from the OTP folks on this one? >>> >>> On 24 May 2013, at 18:41, Tim Watson wrote: >>> >>> > Gah, sorry folks - this has nothing to do with release handling, that >>> was a red herring. Someone just pointed out that the call to get_child >>> originates in a status check in our code. >>> > >>> > This still looks like a bug to me though, since if you're going to >>> handle "other" messages in terminate_loop you ought to ensure they can't >>> deadlock the vm's shutdown sequence. >>> > >>> > Cheers, >>> > Tim >>> > >>> > On 24 May 2013, at 15:45, Fred Hebert wrote: >>> > >>> >> Quick question: are you running a release? >>> >> >>> >> If so, last time I've seen deadlocks like that was solved by making >>> sure >>> >> *all* my applications did depend on stdlib and kernel in their app >>> file. >>> >> When I skipped them, sometimes I'd find that things would lock up. >>> >> >>> >> My guess was that dependencies from stdlib or kernel got unloaded >>> before >>> >> my app and broke something, but I'm not sure -- In my case, I wasn't >>> >> able to inspect the node as it appeared to be 100% blocked. >>> >> >>> >> Adding the apps ended up fixing the problem on the next shutdown. I'm >>> >> not sure if it might be a good fix for you, but it's a stab in the >>> dark, >>> >> >>> >> Regards, >>> >> Fred. >>> >> >>> >> On 05/24, Tim Watson wrote: >>> >>> We came across this at a customer's site, where one of the nodes was >>> apparently in the process of stopping and had been in that state for at >>> least 24 hours. The short version is that an application_master appears to >>> be stuck waiting for a child pid (is that the X process, or the root >>> supervisor?) which is *not* linked to it... >>> >>> >>> >>> The application controller is in the process of stopping an >>> application, during which process a `get_child' message appears to have >>> come in to that application's application_master from somewhere - we are >>> *not* running appmon, so I'm really confused how this can happen, as the >>> only other place where I see (indirect) calls are via the sasl >>> release_handler!? At the bottom of this email is a dump for the >>> application_controller and the application_master for the app it is trying >>> to shut down. I can verify that the pid which the application_master is >>> waiting on is definitely not linked to it - i.e., process_info(links, >>> AppMasterPid) doesn't contain the process <0.256.0> that the master appears >>> to be waiting on. >>> >>> >>> >>> My reading of the code is that the application_master cannot end up >>> in get_child_i unless a get_child request was made which arrives whilst it >>> is in its terminate loop. As I said, we're not using appmon, therefore I >>> assume this originated in the sasl application's release_handler_1, though >>> I'm not sure quite which route would take us there. The relevant bit of >>> code in application_master appears to be: >>> >>> >>> >>> get_child_i(Child) -> >>> >>> Child ! {self(), get_child}, >>> >>> receive >>> >>> {Child, GrandChild, Mod} -> {GrandChild, Mod} >>> >>> end. >>> >>> >>> >>> This in turn originates, I'd guess, in the third receive clause of >>> terminate_loop/2. Anyway, should that code not be dealing with a >>> potentially dead pid for Child, either by handling links effectively - >>> perhaps there is an EXIT signal in the mailbox already which is being >>> ignored here in get_child_i/1 - or by some other means? >>> >>> >>> >>> What follows below is the trace/dump output. Feel free to poke me >>> for more info as needed. >>> >>> >>> >>> Cheers, >>> >>> Tim >>> >>> >>> >>> [TRACE/DUMP] >>> >>> >>> >>> pid: <6676.7.0> >>> >>> registered name: application_controller >>> >>> stacktrace: [{application_master,call,2, >>> >>> >>> [{file,"application_master.erl"},{line,75}]}, >>> >>> {application_controller,stop_appl,3, >>> >>> >>> [{file,"application_controller.erl"}, >>> >>> {line,1393}]}, >>> >>> {application_controller,handle_call,3, >>> >>> >>> [{file,"application_controller.erl"}, >>> >>> {line,810}]}, >>> >>> >>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}] >>> >>> ------------------------- >>> >>> Program counter: 0x00007f9bf9a53720 (application_master:call/2 + 288) >>> >>> CP: 0x0000000000000000 (invalid) >>> >>> arity = 0 >>> >>> >>> >>> 0x00007f9bd7948360 Return addr 0x00007f9bfb97de40 >>> (application_controller:stop_appl/3 + 176) >>> >>> y(0) #Ref<0.0.20562.258360> >>> >>> y(1) #Ref<0.0.20562.258361> >>> >>> y(2) [] >>> >>> >>> >>> 0x00007f9bd7948380 Return addr 0x00007f9bfb973c68 >>> (application_controller:handle_call/3 + 1392) >>> >>> y(0) temporary >>> >>> y(1) rabbitmq_web_dispatch >>> >>> >>> >>> 0x00007f9bd7948398 Return addr 0x00007f9bf9a600c8 >>> (gen_server:handle_msg/5 + 272) >>> >>> y(0) >>> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >>> bytes>>},{default_pass,<<8 >>> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >>> >>> y(1) rabbitmq_web_dispatch >>> >>> y(2) >>> [{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}] >>> >>> y(3) >>> [{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}] >>> >>> >>> >>> 0x00007f9bd79483c0 Return addr 0x00000000008827d8 (>> process normally>) >>> >>> y(0) application_controller >>> >>> y(1) >>> {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 >>> bytes>>},{default_pass,<<8 >>> bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} >>> >>> y(2) application_controller >>> >>> y(3) <0.2.0> >>> >>> y(4) {stop_application,rabbitmq_web_dispatch} >>> >>> y(5) {<0.5864.275>,#Ref<0.0.20562.258345>} >>> >>> y(6) Catch 0x00007f9bf9a600c8 (gen_server:handle_msg/5 + 272) >>> >>> ------------------------- >>> >>> >>> >>> pid: <6676.255.0> >>> >>> registered name: none >>> >>> stacktrace: [{application_master,get_child_i,1, >>> >>> >>> [{file,"application_master.erl"},{line,392}]}, >>> >>> {application_master,handle_msg,2, >>> >>> >>> [{file,"application_master.erl"},{line,216}]}, >>> >>> {application_master,terminate_loop,2, >>> >>> >>> [{file,"application_master.erl"},{line,206}]}, >>> >>> {application_master,terminate,2, >>> >>> >>> [{file,"application_master.erl"},{line,227}]}, >>> >>> {application_master,handle_msg,2, >>> >>> >>> [{file,"application_master.erl"},{line,219}]}, >>> >>> {application_master,main_loop,2, >>> >>> >>> [{file,"application_master.erl"},{line,194}]}, >>> >>> >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >>> >>> ------------------------- >>> >>> Program counter: 0x00007f9bf9a570e0 >>> (application_master:get_child_i/1 + 120) >>> >>> CP: 0x0000000000000000 (invalid) >>> >>> arity = 0 >>> >>> >>> >>> 0x00007f9c1adc3dc8 Return addr 0x00007f9bf9a54eb0 >>> (application_master:handle_msg/2 + 280) >>> >>> y(0) <0.256.0> >>> >>> >>> >>> 0x00007f9c1adc3dd8 Return addr 0x00007f9bf9a54d20 >>> (application_master:terminate_loop/2 + 520) >>> >>> y(0) #Ref<0.0.20562.258362> >>> >>> y(1) <0.9596.275> >>> >>> y(2) >>> {state,<0.256.0>,{appl_data,rabbitmq_web_dispatch,[],undefined,{rabbit_web_dispatch_app,[]},[rabbit_web_dispatch,rabbit_web_dispatch_app,rabbit_web_dispatch_registry,rabbit_web_dispatch_sup,rabbit_web_dispatch_util,rabbit_webmachine],[],infinity,infinity},[],0,<0.29.0>} >>> >>> >>> >>> 0x00007f9c1adc3df8 Return addr 0x00007f9bf9a55108 >>> (application_master:terminate/2 + 192) >>> >>> y(0) <0.256.0> >>> >>> >>> >>> 0x00007f9c1adc3e08 Return addr 0x00007f9bf9a54f70 >>> (application_master:handle_msg/2 + 472) >>> >>> y(0) [] >>> >>> y(1) normal >>> >>> >>> >>> 0x00007f9c1adc3e20 Return addr 0x00007f9bf9a54a60 >>> (application_master:main_loop/2 + 1600) >>> >>> y(0) <0.7.0> >>> >>> y(1) #Ref<0.0.20562.258360> >>> >>> y(2) Catch 0x00007f9bf9a54f70 (application_master:handle_msg/2 + >>> 472) >>> >>> >>> >>> 0x00007f9c1adc3e40 Return addr 0x00007f9bfb969420 >>> (proc_lib:init_p_do_apply/3 + 56) >>> >>> y(0) <0.7.0> >>> >>> >>> >>> 0x00007f9c1adc3e50 Return addr 0x00000000008827d8 (>> process normally>) >>> >>> y(0) Catch 0x00007f9bfb969440 (proc_lib:init_p_do_apply/3 + 88) >>> >>> ------------------------- >>> >>> >>> >> >>> >> >>> >> >>> >>> _______________________________________________ >>> >>> erlang-bugs mailing list >>> >>> erlang-bugs@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Jan 28 13:32:56 2014 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 28 Jan 2014 12:32:56 +0000 Subject: [erlang-bugs] Strange application shutdown deadlock In-Reply-To: References: <20130524144546.GB14817@ferdair.local> <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> Message-ID: Hi Siri. Ok thanks for confirming that. Do you reckon it'll make a bugfix/patch release or are we looking at R17 now? Thanks, Tim On 28 Jan 2014, at 10:00, Siri Hansen wrote: > Hi Tim, I'm sorry, but this has not made it into the latest release. The reason is that there has been too many other tasks with higher priority. > Regards > /siri > > > 2014/1/27 Tim Watson > Hi Siri, > > Did this bug make it into the latest release? I didn't see anything in the release notes. > > Cheers, > Tim > > > > On 19 June 2013 10:47, Siri Hansen wrote: > Hi Tim - I'm so sorry for the long delay here. I agree that this is a bug in the application master and I have written a ticket for it so it will be prioritized into out backlog. > Thanks for the report! > Regards > /siri > > > 2013/5/29 Tim Watson > Any word from the OTP folks on this one? > > On 24 May 2013, at 18:41, Tim Watson wrote: > > > Gah, sorry folks - this has nothing to do with release handling, that was a red herring. Someone just pointed out that the call to get_child originates in a status check in our code. > > > > This still looks like a bug to me though, since if you're going to handle "other" messages in terminate_loop you ought to ensure they can't deadlock the vm's shutdown sequence. > > > > Cheers, > > Tim > > > > On 24 May 2013, at 15:45, Fred Hebert wrote: > > > >> Quick question: are you running a release? > >> > >> If so, last time I've seen deadlocks like that was solved by making sure > >> *all* my applications did depend on stdlib and kernel in their app file. > >> When I skipped them, sometimes I'd find that things would lock up. > >> > >> My guess was that dependencies from stdlib or kernel got unloaded before > >> my app and broke something, but I'm not sure -- In my case, I wasn't > >> able to inspect the node as it appeared to be 100% blocked. > >> > >> Adding the apps ended up fixing the problem on the next shutdown. I'm > >> not sure if it might be a good fix for you, but it's a stab in the dark, > >> > >> Regards, > >> Fred. > >> > >> On 05/24, Tim Watson wrote: > >>> We came across this at a customer's site, where one of the nodes was apparently in the process of stopping and had been in that state for at least 24 hours. The short version is that an application_master appears to be stuck waiting for a child pid (is that the X process, or the root supervisor?) which is *not* linked to it... > >>> > >>> The application controller is in the process of stopping an application, during which process a `get_child' message appears to have come in to that application's application_master from somewhere - we are *not* running appmon, so I'm really confused how this can happen, as the only other place where I see (indirect) calls are via the sasl release_handler!? At the bottom of this email is a dump for the application_controller and the application_master for the app it is trying to shut down. I can verify that the pid which the application_master is waiting on is definitely not linked to it - i.e., process_info(links, AppMasterPid) doesn't contain the process <0.256.0> that the master appears to be waiting on. > >>> > >>> My reading of the code is that the application_master cannot end up in get_child_i unless a get_child request was made which arrives whilst it is in its terminate loop. As I said, we're not using appmon, therefore I assume this originated in the sasl application's release_handler_1, though I'm not sure quite which route would take us there. The relevant bit of code in application_master appears to be: > >>> > >>> get_child_i(Child) -> > >>> Child ! {self(), get_child}, > >>> receive > >>> {Child, GrandChild, Mod} -> {GrandChild, Mod} > >>> end. > >>> > >>> This in turn originates, I'd guess, in the third receive clause of terminate_loop/2. Anyway, should that code not be dealing with a potentially dead pid for Child, either by handling links effectively - perhaps there is an EXIT signal in the mailbox already which is being ignored here in get_child_i/1 - or by some other means? > >>> > >>> What follows below is the trace/dump output. Feel free to poke me for more info as needed. > >>> > >>> Cheers, > >>> Tim > >>> > >>> [TRACE/DUMP] > >>> > >>> pid: <6676.7.0> > >>> registered name: application_controller > >>> stacktrace: [{application_master,call,2, > >>> [{file,"application_master.erl"},{line,75}]}, > >>> {application_controller,stop_appl,3, > >>> [{file,"application_controller.erl"}, > >>> {line,1393}]}, > >>> {application_controller,handle_call,3, > >>> [{file,"application_controller.erl"}, > >>> {line,810}]}, > >>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}] > >>> ------------------------- > >>> Program counter: 0x00007f9bf9a53720 (application_master:call/2 + 288) > >>> CP: 0x0000000000000000 (invalid) > >>> arity = 0 > >>> > >>> 0x00007f9bd7948360 Return addr 0x00007f9bfb97de40 (application_controller:stop_appl/3 + 176) > >>> y(0) #Ref<0.0.20562.258360> > >>> y(1) #Ref<0.0.20562.258361> > >>> y(2) [] > >>> > >>> 0x00007f9bd7948380 Return addr 0x00007f9bfb973c68 (application_controller:handle_call/3 + 1392) > >>> y(0) temporary > >>> y(1) rabbitmq_web_dispatch > >>> > >>> 0x00007f9bd7948398 Return addr 0x00007f9bf9a600c8 (gen_server:handle_msg/5 + 272) > >>> y(0) {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 bytes>>},{default_pass,<<8 bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} > >>> y(1) rabbitmq_web_dispatch > >>> y(2) [{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}] > >>> y(3) [{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}] > >>> > >>> 0x00007f9bd79483c0 Return addr 0x00000000008827d8 () > >>> y(0) application_controller > >>> y(1) {state,[],[],[],[{ssl,<0.507.0>},{public_key,undefined},{crypto,<0.501.0>},{rabbitmq_web_dispatch,<0.255.0>},{webmachine,<0.250.0>},{mochiweb,undefined},{xmerl,undefined},{inets,<0.237.0>},{amqp_client,<0.233.0>},{mnesia,<0.60.0>},{sasl,<0.34.0>},{stdlib,undefined},{kernel,<0.9.0>}],[],[{ssl,temporary},{public_key,temporary},{crypto,temporary},{rabbitmq_web_dispatch,temporary},{webmachine,temporary},{mochiweb,temporary},{xmerl,temporary},{inets,temporary},{amqp_client,temporary},{mnesia,temporary},{sasl,permanent},{stdlib,permanent},{kernel,permanent}],[],[{rabbit,[{ssl_listeners,[5671]},{ssl_options,[{cacertfile,"/etc/rabbitmq/server.cacrt"},{certfile,"/etc/rabbitmq/server.crt"},{keyfile,"/etc/rabbitmq/server.key"},{verify,verify_none},{fail_if_no_peer_cert,false}]},{default_user,<<2 bytes>>},{default_pass,<<8 bytes>>},{vm_memory_high_watermark,5.000000e-01}]},{rabbitmq_management,[{listener,[{port,15672},{ssl,true}]}]}]} > >>> y(2) application_controller > >>> y(3) <0.2.0> > >>> y(4) {stop_application,rabbitmq_web_dispatch} > >>> y(5) {<0.5864.275>,#Ref<0.0.20562.258345>} > >>> y(6) Catch 0x00007f9bf9a600c8 (gen_server:handle_msg/5 + 272) > >>> ------------------------- > >>> > >>> pid: <6676.255.0> > >>> registered name: none > >>> stacktrace: [{application_master,get_child_i,1, > >>> [{file,"application_master.erl"},{line,392}]}, > >>> {application_master,handle_msg,2, > >>> [{file,"application_master.erl"},{line,216}]}, > >>> {application_master,terminate_loop,2, > >>> [{file,"application_master.erl"},{line,206}]}, > >>> {application_master,terminate,2, > >>> [{file,"application_master.erl"},{line,227}]}, > >>> {application_master,handle_msg,2, > >>> [{file,"application_master.erl"},{line,219}]}, > >>> {application_master,main_loop,2, > >>> [{file,"application_master.erl"},{line,194}]}, > >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] > >>> ------------------------- > >>> Program counter: 0x00007f9bf9a570e0 (application_master:get_child_i/1 + 120) > >>> CP: 0x0000000000000000 (invalid) > >>> arity = 0 > >>> > >>> 0x00007f9c1adc3dc8 Return addr 0x00007f9bf9a54eb0 (application_master:handle_msg/2 + 280) > >>> y(0) <0.256.0> > >>> > >>> 0x00007f9c1adc3dd8 Return addr 0x00007f9bf9a54d20 (application_master:terminate_loop/2 + 520) > >>> y(0) #Ref<0.0.20562.258362> > >>> y(1) <0.9596.275> > >>> y(2) {state,<0.256.0>,{appl_data,rabbitmq_web_dispatch,[],undefined,{rabbit_web_dispatch_app,[]},[rabbit_web_dispatch,rabbit_web_dispatch_app,rabbit_web_dispatch_registry,rabbit_web_dispatch_sup,rabbit_web_dispatch_util,rabbit_webmachine],[],infinity,infinity},[],0,<0.29.0>} > >>> > >>> 0x00007f9c1adc3df8 Return addr 0x00007f9bf9a55108 (application_master:terminate/2 + 192) > >>> y(0) <0.256.0> > >>> > >>> 0x00007f9c1adc3e08 Return addr 0x00007f9bf9a54f70 (application_master:handle_msg/2 + 472) > >>> y(0) [] > >>> y(1) normal > >>> > >>> 0x00007f9c1adc3e20 Return addr 0x00007f9bf9a54a60 (application_master:main_loop/2 + 1600) > >>> y(0) <0.7.0> > >>> y(1) #Ref<0.0.20562.258360> > >>> y(2) Catch 0x00007f9bf9a54f70 (application_master:handle_msg/2 + 472) > >>> > >>> 0x00007f9c1adc3e40 Return addr 0x00007f9bfb969420 (proc_lib:init_p_do_apply/3 + 56) > >>> y(0) <0.7.0> > >>> > >>> 0x00007f9c1adc3e50 Return addr 0x00000000008827d8 () > >>> y(0) Catch 0x00007f9bfb969440 (proc_lib:init_p_do_apply/3 + 88) > >>> ------------------------- > >>> > >> > >> > >> > >>> _______________________________________________ > >>> erlang-bugs mailing list > >>> erlang-bugs@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-bugs > >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.faulet@REDACTED Tue Jan 28 16:04:00 2014 From: christopher.faulet@REDACTED (Christopher Faulet) Date: Tue, 28 Jan 2014 16:04:00 +0100 Subject: [erlang-bugs] file:sendfile/5 bug and possible DOS attack In-Reply-To: <52E66B96.2070407@erlang.org> References: <526525CF.5020202@capflam.org> <52662867.7000600@erlang.org> <52E66B96.2070407@erlang.org> Message-ID: <52E7C6E0.4060303@capflam.org> On 27/01/2014 15:22, Lukas Larsson wrote: > I've now implemented the fix I proposed for this. You can view the fix > here: > https://github.com/garazdawi/otp/tree/lukas/erts/sendfile_no_async_pool. > If the tests pass I will merge it asap. > Hi Lukas, Nice! I made some test from my side (not the Erlang testsuite) and your fix works for me. Great job. -- Christopher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 242 bytes Desc: OpenPGP digital signature URL: From lukas@REDACTED Tue Jan 28 16:51:16 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 28 Jan 2014 16:51:16 +0100 Subject: [erlang-bugs] file:sendfile/5 bug and possible DOS attack In-Reply-To: <52E7C6E0.4060303@capflam.org> References: <526525CF.5020202@capflam.org> <52662867.7000600@erlang.org> <52E66B96.2070407@erlang.org> <52E7C6E0.4060303@capflam.org> Message-ID: <52E7D1F4.3020802@erlang.org> Great thanks for testing it! The tests have gone well on all the OSs we test so I will merge this to be part of the next release. Lukas On 28/01/14 16:04, Christopher Faulet wrote: > On 27/01/2014 15:22, Lukas Larsson wrote: >> I've now implemented the fix I proposed for this. You can view the fix >> here: >> https://github.com/garazdawi/otp/tree/lukas/erts/sendfile_no_async_pool. >> If the tests pass I will merge it asap. >> > Hi Lukas, > > Nice! I made some test from my side (not the Erlang testsuite) and your > fix works for me. Great job. > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Jan 29 10:37:24 2014 From: erlang@REDACTED (Erlang) Date: Wed, 29 Jan 2014 09:37:24 +0000 Subject: [erlang-bugs] Segmentation fault when destroying a wx_object Message-ID: <2640F898-792B-4769-A51F-034332E5A7FE@not2cool.com> Hi Operating system: OSX 10.9.1 Erlang version: R16B03 Configure flags: ?enable-darwin-64bit I?m getting a seg fault when the XRC dialog is destroyed. This also occurs on the 32bit pre-built binary of R16B03 from erlang-solutions (it does not occur on previous 32bit versions). It only occurs when event handlers are attached, and isn?t specifically related to XRC as I get the same error when I destroy a wx_object contained within a wxAuiNotebook (the XRC sample was easier to reproduce). Run xrc:test/0 and simply close the dialog in the provided sample to reproduce the bug (it might require a few attempts). Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: xrc_segfault.zip Type: application/zip Size: 21437 bytes Desc: not available URL: From vances@REDACTED Wed Jan 29 15:27:32 2014 From: vances@REDACTED (Vance Shipley) Date: Wed, 29 Jan 2014 19:57:32 +0530 Subject: [erlang-bugs] code:lib_dir/1 fails with ERL_LIBS set Message-ID: <20140129142732.GC367@aluminium.local> There appears to be a bug where code:lib_dir/1 fails with applications appearing in an extra lib directory declared with ERL_LIBS. The following shows the problem: $ ERL_LIBS=/Users/vances/foo erl Erlang R16B03 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> application:load(bar). ok 2> code:which(bar). "/Users/vances/foo/ebin/bar.beam" 3> code:where_is_file("bar.app"). "/Users/vances/foo/ebin/bar.app" 4> code:lib_dir(bar). {error,bad_name} -- -Vance From essen@REDACTED Wed Jan 29 15:32:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 29 Jan 2014 15:32:23 +0100 Subject: [erlang-bugs] code:lib_dir/1 fails with ERL_LIBS set In-Reply-To: <20140129142732.GC367@aluminium.local> References: <20140129142732.GC367@aluminium.local> Message-ID: <52E910F7.6040904@ninenines.eu> Two issues with your test. ERL_LIBS is for specifying lib directories, that is, a directory that contains directories of applications. What you specify is a directory of an application directly. In your example the correct directory would be ERL_LIBS=/Users/vances. "/Users/vances/foo/ebin/bar.beam" should be "/Users/vances/bar/ebin/bar.beam", the bar application is expected to reside in a folder of the same name. On 01/29/2014 03:27 PM, Vance Shipley wrote: > There appears to be a bug where code:lib_dir/1 fails with applications > appearing in an extra lib directory declared with ERL_LIBS. The following > shows the problem: > > $ ERL_LIBS=/Users/vances/foo erl > Erlang R16B03 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.4 (abort with ^G) > 1> application:load(bar). > ok > 2> code:which(bar). > "/Users/vances/foo/ebin/bar.beam" > 3> code:where_is_file("bar.app"). > "/Users/vances/foo/ebin/bar.app" > 4> code:lib_dir(bar). > {error,bad_name} > > -- Lo?c Hoguin http://ninenines.eu From dgud@REDACTED Wed Jan 29 17:00:43 2014 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 29 Jan 2014 17:00:43 +0100 Subject: [erlang-bugs] Segmentation fault when destroying a wx_object In-Reply-To: <2640F898-792B-4769-A51F-034332E5A7FE@not2cool.com> References: <2640F898-792B-4769-A51F-034332E5A7FE@not2cool.com> Message-ID: Can not reproduce with linux and wxWidgets-2.8.12 or wxWidgets-3.1 (i.e. master branch on github) nor on darwin with erlang-r17-rc (coming soon) and wxWidgets-3.0 What wxWidgets is included in Mac R16B03 (32b) from erlang solutions? Is that still wxWidgets-2.8 or is it wxWidgets-3.0? I fixed some wx bugs in R16B03-1 and even more in the coming 17-rc so hopefully it should be fixed now. Regards /Dan On Wed, Jan 29, 2014 at 10:37 AM, Erlang wrote: > Hi > > Operating system: OSX 10.9.1 > Erlang version: R16B03 > Configure flags: --enable-darwin-64bit > > I'm getting a seg fault when the XRC dialog is destroyed. This also occurs > on the 32bit pre-built binary of R16B03 from erlang-solutions (it does not > occur on previous 32bit versions). It only occurs when event handlers are > attached, and isn't specifically related to XRC as I get the same error > when I destroy a wx_object contained within a wxAuiNotebook (the XRC sample > was easier to reproduce). > > Run xrc:test/0 and simply close the dialog in the provided sample to > reproduce the bug (it might require a few attempts). > > Tom > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Jan 30 04:56:16 2014 From: vances@REDACTED (Vance Shipley) Date: Thu, 30 Jan 2014 09:26:16 +0530 Subject: [erlang-bugs] code:lib_dir/1 fails with ERL_LIBS set In-Reply-To: <52E910F7.6040904@ninenines.eu> References: <20140129142732.GC367@aluminium.local> <52E910F7.6040904@ninenines.eu> Message-ID: <20140130035616.GF367@aluminium.local> On Wed, Jan 29, 2014 at 03:32:23PM +0100, Lo?c Hoguin wrote: } "/Users/vances/foo/ebin/bar.beam" should be } "/Users/vances/bar/ebin/bar.beam", the bar application is expected } to reside in a folder of the same name. Yeah, that's it. I was struggling to get autoconf's AC_ERLANG_CHECK_LIB macro to work in a subproject folder where the to level directory can't be known. -- -Vance From argos83@REDACTED Thu Jan 30 08:59:34 2014 From: argos83@REDACTED (Seba) Date: Thu, 30 Jan 2014 08:59:34 +0100 Subject: [erlang-bugs] FTP command injection vulnerability in module "ftp" In-Reply-To: <52E7D862.2090405@erix.ericsson.se> References: <52E7D862.2090405@erix.ericsson.se> Message-ID: Thanks! FYI, this issue has been assigned with the following CVE id (common vulnerabilities and exposures) by cve.mitre.org: CVE-2014-1693 -Sebasti?n. 2014-01-28 Hans Nilsson : > > Hi! > > Thanks for the report! I have written a ticket about it. > > It is however not highly prioritized, because it does not really solve a > security hole. Everything that comes from a client must be regarded as > "evil" by the server and sanitized by the server. Many bad users could write > a client that misbehaves... > > But since a client is supposed to send correct data, we will fix this in the > future. > > - Hans Nilsson > > > > > On 01/27/2014 12:10 PM, Seba wrote: >> >> Hi! >> >> There is an FTP Command Injection vulnerability in the "ftp" module. >> >> All those functions that write any string argument in the control >> socket seem to be vulnerable: >> >> >> user/3 >> user/4 >> account/2 >> cd/2 >> ls/2 >> nlist/2 >> rename/3 >> delete/2 >> mkdir/2 >> rmdir/2 >> recv/2 >> recv/3 >> recv_bin/2, >> recv_chunk_start/2 >> send/3 >> send_bin/3 >> send_chunk_start/2 >> append_chunk_start/2 >> append/2 >> append/3 >> append_bin/3 >> >> >> Vulnerability Description >> ------------------------- >> >> An FTP communication consists of two channels: >> * A TCP control channel: Text-based, and served by the FTP Server. >> * A TCP data channel: Which is created either by the FTP Client or >> the FTP Server depending on data being transmitted using active or >> passive mode. >> The control channel works in a request-response fashion. Each command >> is issued by the client in a single line (ending with a carriage >> return and a new line: \r\n). >> >> By injecting a \r\n sequence followed by a new command in a function >> argument you get the ftp module to write the whole string in the >> socket. >> >> E.g. the following erlang shell session: >> >> 1> inets:start(). >> ok >> 2> {ok, Pid} = inets:start(ftpc, [{host, "127.0.0.1"}]). >> {ok,<0.46.0>} >> 3> ftp:user(Pid, "anonymous", "password\r\nCWD pub\r\nMKD new_dir"). >> ok >> 4> ftp:cd(Pid, "/pub\r\nRMD new_dir\r\nPASV"). >> ok >> >> >> Generates the following FTP session: >> >> FTP command: Client "127.0.0.1", "USER anonymous" >> FTP response: Client "127.0.0.1", "331 Please specify the password." >> FTP command: Client "127.0.0.1", "PASS " >> FTP response: Client "127.0.0.1", "230 Login successful." >> FTP command: Client "127.0.0.1", "CWD pub" >> FTP response: Client "127.0.0.1", "250 Directory successfully changed." >> FTP command: Client "127.0.0.1", "MKD new_dir" >> FTP response: Client "127.0.0.1", "257 "/pub/new_dir" created" >> FTP command: Client "127.0.0.1", "CWD /pub" >> FTP response: Client "127.0.0.1", "250 Directory successfully changed." >> FTP command: Client "127.0.0.1", "RMD new_dir" >> FTP response: Client "127.0.0.1", "250 Remove directory operation >> successful." >> FTP command: Client "127.0.0.1", "PASV" >> FTP response: Client "127.0.0.1", "227 Entering Passive Mode >> (127,0,0,1,130,161)." >> >> >> Attack Scenario Example >> ----------------------- >> >> A web server allow users to navigate and download documents. >> Internally the web server connects to a private ftp server using OTP >> "ftp" module. >> An attacker might take advantage of the vulnerability to execute >> actions that aren't supposed to be exposed. E.g. delete a directory by >> requesting: >> >> http://www.example.com/list_dir.yaws?dir=/docs/%0d%0aRMD+/docs >> >> Tested on >> --------- >> - R15B03 >> - Ubuntu 12.04 x86_64 >> - FTP Sever: vsftpd >> >> Fixing >> ------ >> >> String arguments used to create the command request should be >> sanitized first (by removing "\r" and "\n"). >> >> >> >> Sebasti?n Tello >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > From jan_kowalski6669@REDACTED Thu Jan 30 11:04:29 2014 From: jan_kowalski6669@REDACTED (jan_kowalski6669) Date: Thu, 30 Jan 2014 11:04:29 +0100 Subject: [erlang-bugs] httpc keep-alive bug Message-ID: <62864128-379c4315a16cef0e97632d2760f8e439@pmq5.m5r2.onet> I have function: ? some_function(Url, Cookie, Command, Command2) -> httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command}, [], [{socket_opts, [{keepalive, true}]}]), httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command2}, [], [{socket_opts, [{keepalive, true}]}]). ? which sends two request to same Url with different command, one after another. ? Screenshot from wireshark: http://tinypic.com/view.php?pic=9s8m03&s=8 ? As you can see, in last call of some_function, first request is ok, but second is send to nowhere, and i got no response because first result was without keep-alive header, so second request should open new connection, but it didn't -------------- next part -------------- An HTML attachment was scrubbed... URL: From hm@REDACTED Thu Jan 30 13:12:10 2014 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 30 Jan 2014 13:12:10 +0100 Subject: [erlang-bugs] dets deletes non-dets files Message-ID: <52EA419A.9070807@tail-f.com> I run into a dets bug the other day. If dets tries to open a file that not is a dets file, it simply deletes it. It even deletes the file when access is set to read and repair is false. Scary. The bug is easy to reproduce: % erl Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> file:write_file("foo",<<"foo">>). ok 2> file:read_file("foo"). {ok,<<"foo">>} 3> dets:open_file("foo",[{access,read},{repair,false}]). {error,{file_error,"foo",enoent}} 4> file:read_file("foo"). {error,enoent} 5> /H?kan From hm@REDACTED Thu Jan 30 14:15:54 2014 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 30 Jan 2014 14:15:54 +0100 Subject: [erlang-bugs] dets leaks open file descriptors Message-ID: <52EA508A.3070000@tail-f.com> dets:is_dets_file/1 leaks open file descriptors. It is easy to reproduce. In the printout below you can see that the number of open file descriptors grows for each call to dets:is_dets_file/1. /H?kan #!/usr/bin/env escript %% This is an -*- erlang -*- file. main([Dir]) -> {ok, Files} = file:list_dir(Dir), Fun = fun(Fname0) -> Fname = filename:join([Dir, Fname0]), IsDetsFile = dets:is_dets_file(Fname) =:= true, LsOf = os:cmd("lsof -p "++os:getpid()), OpenFiles = string:tokens(LsOf, "\n"), io:format("~p: ~p ~s\n", [length(OpenFiles), IsDetsFile, Fname]) end, lists:foreach(Fun, Files), halt(0). cd /usr/local/pgm/otp_R16B03-1/lib/erlang/lib/stdlib-1.19.4/src/ ~/dets_files . 21: false ./dets.hrl 22: false ./erl_parse.yrl 23: false ./zip.erl 24: false ./win32reg.erl 25: false ./unicode.erl 26: false ./timer.erl 27: false ./sys.erl 28: false ./supervisor_bridge.erl 29: false ./supervisor.erl 30: false ./string.erl 31: false ./sofs.erl 32: false ./slave.erl 33: false ./shell_default.erl 34: false ./shell.erl 35: false ./sets.erl 36: false ./random.erl 37: false ./queue.erl 38: false ./qlc_pt.erl 39: false ./qlc.erl 40: false ./proplists.erl 41: false ./proc_lib.erl 42: false ./pool.erl 43: false ./re.erl 44: false ./pg.erl 45: false ./ordsets.erl 46: false ./orddict.erl 47: false ./otp_internal.erl 48: false ./ms_transform.erl 49: false ./math.erl 50: false ./log_mf_h.erl 51: false ./lists.erl 52: false ./lib.erl 53: false ./io_lib_pretty.erl 54: false ./io_lib_fread.erl 55: false ./io_lib_format.erl 56: false ./io_lib.erl 57: false ./io.erl 58: false ./gen_server.erl 59: false ./gen_fsm.erl 60: false ./gen_event.erl 61: false ./gen.erl 62: false ./gb_sets.erl 63: false ./gb_trees.erl 64: false ./filename.erl 65: false ./filelib.erl 66: false ./file_sorter.erl 67: false ./eval_bits.erl 68: false ./ets.erl 69: false ./escript.erl 70: false ./error_logger_tty_h.erl 71: false ./error_logger_file_h.erl 72: false ./erl_tar.erl 73: false ./erl_scan.erl 74: false ./erl_pp.erl 75: false ./erl_posix_msg.erl 76: false ./erl_parse.erl 77: false ./erl_lint.erl 78: false ./erl_internal.erl 79: false ./erl_expand_records.erl 80: false ./erl_eval.erl 81: false ./erl_compile.erl 82: false ./erl_bits.erl 83: false ./epp.erl 84: false ./edlin_expand.erl 85: false ./edlin.erl 86: false ./digraph_utils.erl 87: false ./digraph.erl 88: false ./dict.erl 89: false ./dets_v9.erl 90: false ./dets_v8.erl 91: false ./dets_utils.erl 92: false ./dets_sup.erl 93: false ./dets_server.erl 94: false ./dets.erl 95: false ./calendar.erl 96: false ./c.erl 97: false ./binary.erl 98: false ./beam_lib.erl 99: false ./base64.erl 100: false ./array.erl From hans.bolinder@REDACTED Fri Jan 31 09:53:08 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 31 Jan 2014 08:53:08 +0000 Subject: [erlang-bugs] dets leaks open file descriptors In-Reply-To: <52EA508A.3070000@tail-f.com> References: <52EA508A.3070000@tail-f.com> Message-ID: <56466BD70414EA48969B4064696CF28C037A3D4C@ESESSMB207.ericsson.se> [H?kan Mattsson:] > dets:is_dets_file/1 leaks open file descriptors. Thanks. I'll look into it. Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Fri Jan 31 09:54:31 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 31 Jan 2014 08:54:31 +0000 Subject: [erlang-bugs] dets deletes non-dets files In-Reply-To: <52EA419A.9070807@tail-f.com> References: <52EA419A.9070807@tail-f.com> Message-ID: <56466BD70414EA48969B4064696CF28C037A3D5A@ESESSMB207.ericsson.se> [H?kan Mattsson:] > If dets tries to open a file that not is a dets file, it simply deletes it. > It even deletes the file when access is set to read and repair is false. Thanks. I'll look into it. Hans Bolinder, Erlang/OTP team, Ericsson From morten.aasnes@REDACTED Fri Jan 31 09:58:17 2014 From: morten.aasnes@REDACTED (=?UTF-8?Q?Morten_Nygaard_=C3=85snes?=) Date: Fri, 31 Jan 2014 09:58:17 +0100 Subject: [erlang-bugs] ASN1 parsing bug In-Reply-To: References: Message-ID: Any chance of this getting fixed? Cheers, Morten On Jan 10, 2014 1:41 PM, "Morten Nygaard ?snes" wrote: > Hi, > I've encountered what I think is a bug in parsing asn1. Here is a testcase: > > Testcase DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > > BaseType ::= ENUMERATED { > foo, > bar, > buz, > qux, > ... > } > SubType ::= BaseType ( foo | bar ) > > END > > This gives the following error: > > 28> asn1ct:compile("Testcase", [ber,verbose]). > Erlang ASN.1 version "2.0.4", compiling "Testcase.asn" > Compiler Options: [ber,verbose,{i,"."}] > asn1error:13:'Testcase':'SubType' > {asn1,{undefined_type,bar}} > {error,[{error,{type,13,'Testcase','SubType', > {asn1,{undefined_type,bar}}}}]} > > If I remove the extension marker in BaseType, it compiles fine. > > This is using R16B03 on Windows > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Fri Jan 31 10:41:30 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 31 Jan 2014 10:41:30 +0100 Subject: [erlang-bugs] Module attribute `callback' undocumented In-Reply-To: <20140128075010.GA379@aluminium.local> References: <20140128075010.GA379@aluminium.local> Message-ID: Thank you! I have written a ticket for this. /siri 2014-01-28 Vance Shipley : > STDLIB 1.18 deprecated the 'behaviour_info' module attribute in > favour of a 'callback' module attribute which is used as a type > specification (see OTP-9621). > > The current documentation doesn't include the new functionality. > The Erlang Reference Manual should be updated to reflect the change: > > http://www.erlang.org/doc/reference_manual/modules.html > > > -- > -Vance > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Fri Jan 31 12:21:05 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 31 Jan 2014 12:21:05 +0100 Subject: [erlang-bugs] app file documentation of included_applications In-Reply-To: <5286E66F.3020400@gmail.com> References: <5286E66F.3020400@gmail.com> Message-ID: Hi Michael, I'm very sorry for the late response! I just had a look at this, and I'm wondering in which context you see this? If you call application:start, it will surely not start any dependencies at all - it might, however, complain if any dependencies of the given application are not already started. application:ensure_all_started, on the other hand, will start all dependencies of the given application (recursively), but as far as I can see it will not start any dependencies of included_applications. Could you please give an example? Thanks /siri@REDACTED 2013-11-16 Michael Truog : > Hi, > > The documentation at: http://www.erlang.org/doc/man/app.html > > For included_applications says: "All applications which are included by > this application. When this application is started, all included > application will automatically be loaded, but not started, by the > application controller. It is assumed that the topmost supervisor of the > included application is started by a supervisor of this application." > > What it does not say, is that all the application dependencies of the > included_applications are started automatically for you. While that > handling of included_applications makes sense, it would be good to make > explicit in the documentation, so people aren't led to believe they must > start included_application dependencies manually (or so that they don't use > included_applications if they do want to start the whole application > manually). > > Thanks, > Michael > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Fri Jan 31 12:31:35 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 31 Jan 2014 12:31:35 +0100 Subject: [erlang-bugs] ct should depend on sasl In-Reply-To: <527BE59E.9060208@gmail.com> References: <527BE59E.9060208@gmail.com> Message-ID: Hi Michal, again - sorry for the late reply! Please correct me if I'm wrong, but as far as I can see there is no real need for sasl to be started in order for common_test to run. In cth_log_redirect, there is specific code handling the case when sasl is not started. Could you please exemplify when a stated dependency towards sasl is a problem in common_test? Regards /siri@REDACTED 2013-11-07 Michael Truog : > Hi, > > sasl is a missing dependency here > https://github.com/erlang/otp/blob/maint/lib/common_test/src/common_test.app.src#L64 > due to the usage of error_logger from here > https://github.com/erlang/otp/blob/maint/lib/common_test/src/ct_hooks.erl#L39 > > Thanks, > Michael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtsiour@REDACTED Fri Jan 31 13:58:35 2014 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Fri, 31 Jan 2014 14:58:35 +0200 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? Message-ID: <52EB9DFB.4090503@softlab.ntua.gr> Hey, While trying to locate a bug in our x86 backend that caused a segfault at load-time, we came at something that we think is a bug in the final address calculation. In functions hipe_patch_load_fe and hipe_patch_insn in erts/emulator/hipe/hipe_x86.c file we think that the final address should always be calculated as the sum of "address" and "value". We base this on our observation that "address" seems to be the offset and "value" seems to be the base address. The patch that works for us is attached. If any developer can confirm that this is a bug (and that the patch is the correct way to fix it) I can submit it properly (if needed). :-) Thanks, Yiannis (as member of the ErLLVM team) -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed... Name: address-patching-in-x86.diff Type: text/x-patch Size: 769 bytes Desc: not available URL: From erlangsiri@REDACTED Fri Jan 31 14:28:29 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 31 Jan 2014 14:28:29 +0100 Subject: [erlang-bugs] eunit_surefire doesn't ensure proper UTF-8 encoding In-Reply-To: References: <87r4ak1noc.fsf@mia.config> Message-ID: Thanks for the report - I have written a ticket for this. A contribution will of course speed up the handling... :) /siri@REDACTED 2013-11-15 Samuel : > We have seen this in the past, but we fixed it in our own surefire > rebar plugin. If I remember right, the problem is not in > eunit_surefire.erl but in eunit itself. Below some information I dug > out of my emal (unfortunately I never found time to produce a proper > patch for this: > > ------ > I am pretty sure the patch > > https://github.com/richcarl/eunit/commit/9f505f1b8881f44c1e5d37df005533b2af6d6a7e > does not solve the right problem. > > As far as I can understand, the output is already in binary state when > it reaches the eunit_surefile code, which means that it is already > encoded. The patch seems to work because the encoding happened to be > latin1 (by coincidence) and then re-encoding to UTF8 works. > > The root issue seems to be in eunit_proc, that ignores the encoding of > the io_requests and then buffer_to_binary just does list_to_binary. > > The patch seems to work because it does the right thing for codepoints > between 127 and 255, as they are the same as the latin1 encoding for > them. Thus they get properly encoded to utf-8 when writing the xml > file, but will probably fail if the binary passed to eunit_surefile > were properly encoded in utf-8. > > There is a major issue with that, and is that eunit_proc will crash if > any test outputs a codepoint higher than 255, I think I have a proper > fix for that but I haven't had the time to test it thoroughly yet. > When fixed, the surefile report must be written in raw again, as the > binaries should be utf8 encoded already. > > Next patch makes it work again, but is a hack, as it assumes the > strings to be unicode in the list form and utf8 in the binary form > (which I guess is true in current OTP implementation): > > -buffer_to_binary(Buf) -> list_to_binary(lists:reverse(Buf)). > +buffer_to_binary(Buf) -> unicode:characters_to_binary(lists:reverse(Buf)). > > > As an example, the attached suite causes this when run: > > > eunit_unicode_crash:test(). > > =ERROR REPORT==== 27-Aug-2012::14:26:49 === > Error in process <0.78.0> with exit value: > > {badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]},{eunit_proc,buffer_to_binary,1,[{file,"eunit_proc.erl"},{line,276}]},{eunit_proc,group_leader_loop,3,[{file,"eunit_proc.erl"},{line,600}]}]} > > eunit_unicode_crash: unicode_test (module > 'eunit_unicode_crash')...*skipped* > undefined > *unexpected termination of test process* > ::{badarg,[{erlang,list_to_binary,[[[[1013],"\n"]]],[]}, > {eunit_proc,buffer_to_binary,1, > [{file,"eunit_proc.erl"},{line,276}]}, > {eunit_proc,group_leader_loop,3, > [{file,"eunit_proc.erl"},{line,600}]}]} > > On 13 November 2013 13:38, Magnus Henoch > wrote: > > Compile the following module and run eunit_xml_encoding_bug:doit() from > > an Erlang shell: > > > > -module(eunit_xml_encoding_bug). > > > > -compile(export_all). > > > > -include_lib("eunit/include/eunit.hrl"). > > > > doit() -> > > eunit:test(?MODULE, [{report, {eunit_surefire,[]}}]). > > > > my_test_() -> > > ?_test(io:format([128,10])). > > > > This creates a file called TEST-eunit_xml_encoding_bug.xml which claims > > to be in UTF-8 (its first line is ' ?>') > > but contains an improperly encoded character. Most XML tools will > > refuse to do anything with such an XML file. For example xmllint says: > > > > $ xmllint /tmp/TEST-eunit_xml_encoding_bug.xml > > /tmp/TEST-eunit_xml_encoding_bug.xml:4: parser error : Input is not > proper UTF-8, indicate encoding ! > > > > And opening the file in Firefox yields: > > > > XML Parsing Error: not well-formed > > Location: file:///tmp/TEST-eunit_xml_encoding_bug.xml > > Line Number 4, Column 17: > > > > I came across this problem when running a Quickcheck property inside > > Eunit. The Quickcheck property would output random binary data with > > io:format("~p"), and sometimes that would end up being high bytes which > > were valid Latin-1 but invalid UTF-8. > > > > As eunit_surefire declares its output files to be in UTF-8 encoding, I > > think it should check that the contents of etc are properly > > encoded, and if not do something about it, e.g. convert from Latin-1 to > > UTF-8 or insert replacement characters (U+FFFD). > > > > Regards, > > Magnus > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > -- > Samuel > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Fri Jan 31 15:29:34 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 31 Jan 2014 15:29:34 +0100 Subject: [erlang-bugs] ASN1 parsing bug In-Reply-To: References: Message-ID: On Fri, Jan 31, 2014 at 9:58 AM, Morten Nygaard ?snes < morten.aasnes@REDACTED> wrote: > Any chance of this getting fixed? > > Yes, we hope to fix it before the final release of OTP 17. It will probably be included in the next release candidate. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ingela.Anderton.Andin@REDACTED Fri Jan 31 17:45:07 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 31 Jan 2014 17:45:07 +0100 Subject: [erlang-bugs] httpc keep-alive bug In-Reply-To: <62984067-d0eb271ae4128a30179c98cdda54827b@pmq1v.m5r2.onet> References: <62984067-d0eb271ae4128a30179c98cdda54827b@pmq1v.m5r2.onet> Message-ID: <52EBD313.5070405@ericsson.com> Hi! Could you check if this is a problem even in the latest version, inets-5.9.8? The code handling this has been changed since inets-5.9.5. Regards Ingela Erlang/OTP team - Ericsson AB On 01/30/2014 12:14 PM, jan_kowalski6669 wrote: > Hi, > > Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] > > ls /usr/lib/erlang/lib/ | grep inets > inets-5.9.5 > > W dniu 2014-01-30 12:01:45 u?ytkownik Ingela Anderton Andin napisa?: >> Hi! >> >> Please state what version of inets application that you are using. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> On 01/30/2014 11:04 AM, jan_kowalski6669 wrote: >>> I have function: >>> some_function(Url, Cookie, Command, Command2) -> >>> httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command}, >>> [], [{socket_opts, [{keepalive, true}]}]), >>> httpc:request(post, {Url, [{"Cookie", Cookie}], "text/xml", Command2}, >>> [], [{socket_opts, [{keepalive, true}]}]). >>> which sends two request to same Url with different command, one after >>> another. >>> Screenshot from wireshark: http://tinypic.com/view.php?pic=9s8m03&s=8 >>> As you can see, in last call of some_function, first request is ok, but >>> second is send to nowhere, and i got no response because first result >>> was without keep-alive header, so second request should open new >>> connection, but it didn't >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> > > > From sverker.eriksson@REDACTED Fri Jan 31 18:20:52 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 31 Jan 2014 18:20:52 +0100 Subject: [erlang-bugs] A bug in address patching in hipe_x86.c? In-Reply-To: <52EB9DFB.4090503@softlab.ntua.gr> References: <52EB9DFB.4090503@softlab.ntua.gr> Message-ID: <52EBDB74.5040308@erix.ericsson.se> On 01/31/2014 01:58 PM, Yiannis Tsiouris wrote: > Hey, > > While trying to locate a bug in our x86 backend that caused a segfault > at load-time, we came at something that we think is a bug in the final > address calculation. In functions hipe_patch_load_fe and > hipe_patch_insn in erts/emulator/hipe/hipe_x86.c file we think that > the final address should always be calculated as the sum of "address" > and "value". We base this on our observation that "address" seems to > be the offset and "value" seems to be the base address. > > The patch that works for us is attached. > > If any developer can confirm that this is a bug (and that the patch is > the correct way to fix it) I can submit it properly (if needed). :-) > > Thanks, > Yiannis (as member of the ErLLVM team) > Thank for the patch, Yiannis (comments below) diff --git a/erts/emulator/hipe/hipe_x86.c b/erts/emulator/hipe/hipe_x86.c index 327c74e..6c233cb 100644 --- a/erts/emulator/hipe/hipe_x86.c +++ b/erts/emulator/hipe/hipe_x86.c @@ -36,7 +36,7 @@ void hipe_patch_load_fe(Uint32 *address, Uint32 value) { /* address points to a disp32 or imm32 operand */ - *address = value; + *address += value; } int hipe_patch_insn(void *address, Uint32 value, Eterm type) @@ -46,14 +46,12 @@ int hipe_patch_insn(void *address, Uint32 value, Eterm type) case am_constant: case am_atom: case am_c_const: - break; case am_x86_abs_pcrel: - value += (Uint)address; break; default: return -1; } - *(Uint32*)address = value; + *(Uint32*)address += value; return 0; } If this has worked before (which it has) then the old value of *address must always have been zero. But it looks like hipe_patch_insn() can be called in a module upgrade scenario (see hipe_bifs_redirect_referred_from_1 in hipe_bif0.c) and then the old value of *address must (I guess?) refer to something in the old module instance. Adding old and new values can not be right (whatever "value" may be). Have you tried this patch with the existing x86 backend? And have you tried upgrading a module and verified that it is reachable after the upgrade? /Sverker, Erlang/OTP