From sdl.web@REDACTED Mon Oct 5 17:15:49 2015 From: sdl.web@REDACTED (Leo Liu) Date: Mon, 05 Oct 2015 23:15:49 +0800 Subject: [erlang-bugs] dbg:dhandler1/3 missing newline? Message-ID: Hi, I am seeing dbg trace outputs looking like this: -------------------------------- (<0.6690.1>) returned from observer_html_lib:expandable_term/3 -> [["\n", [snipped 22 lines] ["\n", [["", ["
",
                                                                            ["'0x0000000017857b50'"],
                                                                            "
"], ""], ...... -------------------------------- Is this a bug? I wonder if it looks better with the following tweak. --- dbg.erl +++ # @@ -1006,7 +1006,7 @@ return_from -> MFA = element(4, Trace), Ret = element(5, Trace), - io:format(Out, "(~p) returned from ~s -> ~p~n", [From,ffunc(MFA),Ret]); + io:format(Out, "(~p) returned from ~s ->~n ~p~n", [From,ffunc(MFA),Ret]); return_to -> MFA = element(4, Trace), io:format(Out, "(~p) returning to ~s~n", [From,ffunc(MFA)]); Diff finished. Mon Oct 5 23:02:46 2015 Leo From aronisstav@REDACTED Tue Oct 6 15:12:38 2015 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 6 Oct 2015 15:12:38 +0200 Subject: [erlang-bugs] erlang:is_builtin(erlang,apply,3) = false In-Reply-To: References: Message-ID: Bump? On Wed, Apr 9, 2014 at 7:06 PM, Stavros Aronis wrote: > Hello! > > Title says everything. Is this intentional? > > 1> erlang:is_builtin(erlang,apply,3). > false > > Regards, > > Stavros > > PS: Apologies for just reporting this and not attempting a fix, but this > seems to go deeper into C code than I am comfortable patching. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Tue Oct 6 21:22:31 2015 From: sdl.web@REDACTED (Leo Liu) Date: Wed, 07 Oct 2015 03:22:31 +0800 Subject: [erlang-bugs] [PATCH] Correct field name in cdv_ets_cb:info_fields/0 Message-ID: A non-text attachment was scrubbed... Name: 0001-Correct-field-name-in-cdv_ets_cb-info_fields-0.patch Type: text/x-patch Size: 770 bytes Desc: 0001-Correct-field-name-in-cdv_ets_cb-info_fields-0.patch URL: From rvirding@REDACTED Wed Oct 7 03:00:10 2015 From: rvirding@REDACTED (Robert Virding) Date: Tue, 6 Oct 2015 18:00:10 -0700 Subject: [erlang-bugs] Strange behaviour of exit(kill) Message-ID: I am giving an Erlang course and we are looking at the error handling. When showing examples I found a very strange behaviour (to me) of doing exit(kill). The linked process gets the 'kill' but it is trappable. However, if I use exit(P, kill) to send the kill signal it is, as it should be, not trappable. Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> process_flag(trap_exit, true). false 2> spawn_link(fun () -> exit(normal) end). <0.36.0> 3> flush(). Shell got {'EXIT',<0.36.0>,normal} ok 4> spawn_link(fun () -> exit(die) end). <0.39.0> 5> flush(). Shell got {'EXIT',<0.39.0>,die} ok 6> S = self(). <0.33.0> 7> spawn_link(fun () -> exit(S, die) end). <0.43.0> 8> flush(). Shell got {'EXIT',<0.43.0>,die} Shell got {'EXIT',<0.43.0>,normal} ok 9> spawn_link(fun () -> exit(kill) end). <0.46.0> 10> flush(). Shell got {'EXIT',<0.46.0>,kill} ok 11> spawn_link(fun () -> exit(S, kill) end). ** exception exit: killed The shell evaluator process traps exits and then spawn_links a number of processes which exit/1 and exit/2 with different reasons. Everything behaves normally until 9> where I spawn_link a process which does an exit(kill). I get the 'kill' signal, but it is a trappable 'kill' signal! If I send the 'kill' signal with exit/2 it is not trappable, as it shouldn't be. What gives? So just receiving a 'kill' signal is not what kills me but it has to be sent in a certain way. So the process receiving a signal knows how the signal was sent. This is really inconsistent! It should be the signal itself which determines what the receiving process does. I would definitely class this as a bug. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.hueras@REDACTED Wed Oct 7 03:20:13 2015 From: zachary.hueras@REDACTED (Soup) Date: Tue, 6 Oct 2015 21:20:13 -0400 Subject: [erlang-bugs] Strange behaviour of exit(kill) In-Reply-To: References: Message-ID: At 9, the spawned process is killing itself with reason kill, and the shell received a trappable exit message. At 11, the spawned process is killing the *shell* with reason kill. That's not a trappable signal coming from another process: it's an emulator command to kill the specified process, and the reason kill makes it untrappable. It's a little nuanced, but pretty straightforward otherwise. When a process dies, it informs linked processes by way of message, which forces exit unless the receiving process is trapping exits. *exit/2 does not produce a message*, it tries to terminate the process. It's only converted into a message if the process is trapping exits, and reason kill bypasses the trapping logic. On Oct 6, 2015 9:00 PM, "Robert Virding" wrote: > I am giving an Erlang course and we are looking at the error handling. > When showing examples I found a very strange behaviour (to me) of doing > exit(kill). The linked process gets the 'kill' but it is trappable. > However, if I use exit(P, kill) to send the kill signal it is, as it should > be, not trappable. > > Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1> process_flag(trap_exit, true). > false > 2> spawn_link(fun () -> exit(normal) end). > <0.36.0> > 3> flush(). > Shell got {'EXIT',<0.36.0>,normal} > ok > 4> spawn_link(fun () -> exit(die) end). > <0.39.0> > 5> flush(). > Shell got {'EXIT',<0.39.0>,die} > ok > 6> S = self(). > <0.33.0> > 7> spawn_link(fun () -> exit(S, die) end). > <0.43.0> > 8> flush(). > Shell got {'EXIT',<0.43.0>,die} > Shell got {'EXIT',<0.43.0>,normal} > ok > 9> spawn_link(fun () -> exit(kill) end). > <0.46.0> > 10> flush(). > Shell got {'EXIT',<0.46.0>,kill} > ok > 11> spawn_link(fun () -> exit(S, kill) end). > ** exception exit: killed > > The shell evaluator process traps exits and then spawn_links a number of > processes which exit/1 and exit/2 with different reasons. Everything > behaves normally until 9> where I spawn_link a process which does an > exit(kill). I get the 'kill' signal, but it is a trappable 'kill' signal! > If I send the 'kill' signal with exit/2 it is not trappable, as it > shouldn't be. > > What gives? So just receiving a 'kill' signal is not what kills me but it > has to be sent in a certain way. So the process receiving a signal knows > how the signal was sent. This is really inconsistent! It should be the > signal itself which determines what the receiving process does. I would > definitely class this as a bug. > > Robert > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Wed Oct 7 03:47:33 2015 From: rvirding@REDACTED (Robert Virding) Date: Tue, 6 Oct 2015 18:47:33 -0700 Subject: [erlang-bugs] Fwd: [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> Message-ID: ---------- Forwarded message ---------- From: Robert Virding Date: 6 October 2015 at 18:46 Subject: Re: [erlang-questions] Strange behaviour of exit(kill) To: zxq9 Cc: erlang-questions It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is trapping exits unless it is the 'kill' which is untrappable and the process always dies. Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'. In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the other it is untrappable. My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent. Robert On 6 October 2015 at 18:33, zxq9 wrote: > On Wednesday 07 October 2015 10:25:38 zxq9 wrote: > > > or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically > untrappable by way of matching on self()? > > That was too much to hope for: > > 1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), Loop() > end end). > <0.1889.0> > 2> P ! {'EXIT', P, kill}. > Got {'EXIT',<0.1889.0>,kill} > {'EXIT',<0.1889.0>,kill} > 3> P ! {'EXIT', P, blam}. > Got {'EXIT',<0.1889.0>,blam} > {'EXIT',<0.1889.0>,blam} > 4> exit(P, kill). > true > 5> P ! {'EXIT', P, blam}. > {'EXIT',<0.1889.0>,blam} > > If it *did* turn out that matching {'EXIT', self(), kill} was untrappable > I would just say "ah, that makes sense -- now I can understand the > mechanism behind this without thinking about VM details". Instead it > appears to be a case of mysterious activity underlying a message form that > is semantically overloaded. And that stinks. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Wed Oct 7 08:20:24 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 7 Oct 2015 08:20:24 +0200 Subject: [erlang-bugs] erlang:is_builtin(erlang,apply,3) = false In-Reply-To: References: Message-ID: On Wed, Apr 9, 2014 at 7:06 PM, Stavros Aronis wrote: > Hello! > > Title says everything. Is this intentional? > > 1> erlang:is_builtin(erlang,apply,3). > false > May not be intentional, but erlang:apply/3 is a strange creature which is not implemented in the same way as all other BIFs. Part of apply/3 is in implemented in erlang.erl: apply(Mod, Name, Args) -> erlang:apply(Mod, Name, Args). (This Erlang code will be called if you apply apply/3.) What do you think? Should erlang:is_builtin(erlang, apply, 3) return true? If so, why? /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kostis@REDACTED Wed Oct 7 10:09:06 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 07 Oct 2015 10:09:06 +0200 Subject: [erlang-bugs] erlang:is_builtin(erlang,apply,3) = false In-Reply-To: References: Message-ID: <5614D322.1080806@cs.ntua.gr> On 10/07/2015 08:20 AM, Bj?rn Gustavsson wrote: > On Wed, Apr 9, 2014 at 7:06 PM, Stavros Aronis wrote: >> >Hello! >> > >> >Title says everything. Is this intentional? >> > >> >1> erlang:is_builtin(erlang,apply,3). >> >false >> > > May not be intentional, but erlang:apply/3 is a strange > creature which is not implemented in the same way > as all other BIFs. Part of apply/3 is in implemented > in erlang.erl: > > apply(Mod, Name, Args) -> > erlang:apply(Mod, Name, Args). > > (This Erlang code will be called if you apply apply/3.) > > What do you think? Should erlang:is_builtin(erlang, apply, 3) > return true? If so, why? Unless I fail to see the point, to me this code is sufficient proof alone that erlang:apply/3 is a BIF, i.e., a built-in of the language that is not/cannot not be defined using some other construct of the language. What does the call in the body of the clause call if not the erlang:apply/3 BIF? (*) Kostis (*) Surely not the head of the clause, because then this code would have no semantics as Erlang code and a compiler/code transformation program would be allowed to change a call to erlang:apply/3 with a call to e.g. the loop() -> loop(). function. From rvirding@REDACTED Wed Oct 7 12:27:24 2015 From: rvirding@REDACTED (Robert Virding) Date: Wed, 7 Oct 2015 03:27:24 -0700 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> Message-ID: I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great. I would personally go the other way and say that kill is kill however it is sent. But I agree with you, I'm not holding my breath waiting for it to be fixed. Robert P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1. On 7 October 2015 at 00:51, H?kan Huss wrote: > 2015-10-07 3:46 GMT+02:00 Robert Virding : > >> It's all about signals and not messages. Sending a message to a process >> should *NEVER* by default kill it even if it has the same format as an >> 'EXIT' message. NEVER!. A signal is converted to a message when it arrives >> at a process which is trapping exits unless it is the 'kill' which is >> untrappable and the process always dies. >> >> Yes, but the 'kill' signal is not an exit signal with reason kill. The > 'kill' signal can only be sent by calling exit/2 with Reason = kill, which > is documented to have the effect that "an untrappable exit signal is sent > to Pid which will unconditionally exit with exit reason killed." There is > no mention of how the exit reason in that exit signal, and since it is not > trappable there is no way to observe it. > > >> Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally >> kill the process >> > Yes. > > as should dying with the reason 'kill' in exit(kill) which also sends the >> SIGNAL 'kill'. >> > No, this sends an exit signal with reason kill, but that is not the same > ass the signal sent using exit(Pid, kill). > > >> In both cases the process receives the SIGNAL 'kill', as shown in my >> example, but in one case it is trappable and in the other it is untrappable. >> > No, in one case it receives an exit signal with reason kill, in the other > case it receives the special untrappable exit signal which causes > unconditional termination. > > >> My point is that the *same* signal results in different behaviour >> depending on how it was sent. That's incocnsistent. >> > I agree that it is inconsistent. I would have preferred that the exit(Pid, > kill) was a separate function, e.g., kill(Pid) and that exit(Pid, kill) > would be handled as any other exit/2 call. But I won't hold my breath in > anticipation of that being changed... > > /H?kan > > >> Robert >> >> >> On 6 October 2015 at 18:33, zxq9 wrote: >> >>> On Wednesday 07 October 2015 10:25:38 zxq9 wrote: >>> >>> > or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically >>> untrappable by way of matching on self()? >>> >>> That was too much to hope for: >>> >>> 1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), >>> Loop() end end). >>> <0.1889.0> >>> 2> P ! {'EXIT', P, kill}. >>> Got {'EXIT',<0.1889.0>,kill} >>> {'EXIT',<0.1889.0>,kill} >>> 3> P ! {'EXIT', P, blam}. >>> Got {'EXIT',<0.1889.0>,blam} >>> {'EXIT',<0.1889.0>,blam} >>> 4> exit(P, kill). >>> true >>> 5> P ! {'EXIT', P, blam}. >>> {'EXIT',<0.1889.0>,blam} >>> >>> If it *did* turn out that matching {'EXIT', self(), kill} was >>> untrappable I would just say "ah, that makes sense -- now I can understand >>> the mechanism behind this without thinking about VM details". Instead it >>> appears to be a case of mysterious activity underlying a message form that >>> is semantically overloaded. And that stinks. >>> >>> -Craig >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Wed Oct 7 16:39:36 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 07 Oct 2015 14:39:36 +0000 Subject: [erlang-bugs] [PATCH] Correct field name in cdv_ets_cb:info_fields/0 In-Reply-To: References: Message-ID: Thanks, will fix. /Dan On Tue, Oct 6, 2015 at 9:22 PM Leo Liu wrote: > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco.lattanzio@REDACTED Wed Oct 7 14:27:25 2015 From: francesco.lattanzio@REDACTED (Francesco Lattanzio) Date: Wed, 7 Oct 2015 14:27:25 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> Message-ID: <20151007122725.GB3459@wagner.intra.a-tono.com> I always thought that when a process dies because it was sent a 'kill' message it would broadcast to the linked processes a 'killed' EXIT message (see Concurrent Programming in Erlang - Part I, D.3 Exit signals, p. 193 ). However for some reason recent implementations of the VM broadcasts a 'kill' EXIT message (I could only test it on Erlang VMs as old as R13B04). I'm not asking to revert this behaviour (I bet such a change would impact a lot of code), however it would be nice to know why it was chosen a two-semantics kill message instead of more obvious two one-semantic kill and killed message (if someone knows). On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote: > I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other > which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great. > > I would personally go the other way and say that kill is kill however it is sent. But I agree with you, I'm not holding my breath > waiting for it to be fixed. > > Robert > > P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1. > > > On 7 October 2015 at 00:51, H?kan Huss wrote: > > 2015-10-07 3:46 GMT+02:00 Robert Virding : > > It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has > the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is > trapping exits unless it is the 'kill' which is untrappable and the process always dies. > > > Yes, but the 'kill' signal is not an exit signal with reason kill. The 'kill' signal can only be sent by calling exit/2 with > Reason = kill, which is documented to have the effect that "an untrappable exit signal is sent to Pid which will > unconditionally exit with exit reason killed." There is no mention of how the exit reason in that exit signal, and since it is > not trappable there is no way to observe it. > ? > > Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process > > Yes. > > > as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'. > > No, this sends an exit signal with reason kill, but that is not the same ass the signal sent using exit(Pid, kill). > ? > > In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the > other it is untrappable. > > No, in one case it receives an exit signal with reason kill, in the other case it receives the special untrappable exit signal > which causes unconditional termination. > ? > > My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent. > > I agree that it is inconsistent. I would have preferred that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and > that exit(Pid, kill) would be handled as any other exit/2 call. But I won't hold my breath in anticipation of that being > changed... > > /H?kan > ? > > Robert > > > On 6 October 2015 at 18:33, zxq9 wrote: > > On Wednesday 07 October 2015 10:25:38 zxq9 wrote: > > > or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically untrappable by way of matching on self()? > > That was too much to hope for: > > 1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), Loop() end end). > <0.1889.0> > 2> P ! {'EXIT', P, kill}. > Got {'EXIT',<0.1889.0>,kill} > {'EXIT',<0.1889.0>,kill} > 3> P ! {'EXIT', P, blam}. > Got {'EXIT',<0.1889.0>,blam} > {'EXIT',<0.1889.0>,blam} > 4> exit(P, kill). > true > 5> P ! {'EXIT', P, blam}. > {'EXIT',<0.1889.0>,blam} > > If it *did* turn out that matching {'EXIT', self(), kill} was untrappable I would just say "ah, that makes sense -- now > I can understand the mechanism behind this without thinking about VM details". Instead it appears to be a case of > mysterious activity underlying a message form that is semantically overloaded. And that stinks. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- FRANCESCO LATTANZIO : SYSTEM & SOFTWARE A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39 02 32069314 : SKYPE franz.lattanzio a-tono.com : twitter.com/ATonoOfficial : facebook.com/ATonoOfficial Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. From alovedalongthe@REDACTED Thu Oct 8 04:42:25 2015 From: alovedalongthe@REDACTED (David Whitlock) Date: Thu, 8 Oct 2015 09:42:25 +0700 Subject: [erlang-bugs] crypto:rand_bytes using deprecated function Message-ID: Hi, The rand_bytes function in the crypto module is using the openssl RAND_pseudo_bytes function, which is deprecated. This raises three issues / questions: 1. Should he function rand_bytes be deprecated? 2. Should the documentation state that it should not be used for cryptographic purposes (this is the openssl recommendation)? 3. In otp/lib/ssl/src/ssl.erl (starting line 595) and in otp/lib/crypto/src/crypto.erl (starting line 643) there are functions which fall back to rand_bytes if strong_rand_bytes cannot be used. It is therefore possible that rand_bytes might be used to generate keys. Should these functions return an error instead? If you need any more info, please let me know, David Whitlock -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Oct 8 13:34:33 2015 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 8 Oct 2015 13:34:33 +0200 Subject: [erlang-bugs] erlang:is_builtin(erlang,apply,3) = false In-Reply-To: <5614D322.1080806@cs.ntua.gr> References: <5614D322.1080806@cs.ntua.gr> Message-ID: On Wed, Oct 7, 2015 at 10:09 AM, Kostis Sagonas wrote: > On 10/07/2015 08:20 AM, Bj?rn Gustavsson wrote: >> >> On Wed, Apr 9, 2014 at 7:06 PM, Stavros Aronis >> wrote: >>> >>> >Hello! >>> > >>> >Title says everything. Is this intentional? >>> > >>> >1> erlang:is_builtin(erlang,apply,3). >>> >false >>> > >> >> May not be intentional, but erlang:apply/3 is a strange >> creature which is not implemented in the same way >> as all other BIFs. Part of apply/3 is in implemented >> in erlang.erl: >> >> apply(Mod, Name, Args) -> >> erlang:apply(Mod, Name, Args). >> >> (This Erlang code will be called if you apply apply/3.) >> >> What do you think? Should erlang:is_builtin(erlang, apply, 3) >> return true? If so, why? > > > Unless I fail to see the point, to me this code is sufficient proof alone > that erlang:apply/3 is a BIF, i.e., a built-in of the language that is > not/cannot not be defined using some other construct of the language. What > does the call in the body of the clause call if not the erlang:apply/3 BIF? That seems reasonable. I will change erlang:builtin(erlang, apply, 3) to return 'true'. I will do the change in the master branch. /Bjorn > > Kostis > > (*) Surely not the head of the clause, because then this code would have no > semantics as Erlang code and a compiler/code transformation program would be > allowed to change a call to erlang:apply/3 with a call to e.g. the loop() -> > loop(). function. > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From essen@REDACTED Thu Oct 8 14:37:19 2015 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 8 Oct 2015 14:37:19 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <20151007122725.GB3459@wagner.intra.a-tono.com> References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> Message-ID: <5616637F.4010102@ninenines.eu> On 10/07/2015 02:27 PM, Francesco Lattanzio wrote: > I always thought that when a process dies because it was sent a 'kill' > message it would broadcast to the linked processes a 'killed' EXIT > message (see Concurrent Programming in Erlang - Part I, D.3 Exit > signals, p. 193 ). > However for some reason recent implementations of the VM broadcasts a > 'kill' EXIT message (I could only test it on Erlang VMs as old as > R13B04). 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end). <0.36.0> 2> exit(Pid, kill). ** exception exit: killed 3> f(). ok 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end). <0.41.0> 5> process_flag(trap_exit, true). false 6> exit(Pid, kill). true 7> flush(). Shell got {'EXIT',<0.41.0>,killed} ok Cheers, > I'm not asking to revert this behaviour (I bet such a change would > impact a lot of code), however it would be nice to know why it was > chosen a two-semantics kill message instead of more obvious two > one-semantic kill and killed message (if someone knows). > > On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote: >> I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other >> which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great. >> >> I would personally go the other way and say that kill is kill however it is sent. But I agree with you, I'm not holding my breath >> waiting for it to be fixed. >> >> Robert >> >> P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1. >> >> >> On 7 October 2015 at 00:51, H?kan Huss wrote: >> >> 2015-10-07 3:46 GMT+02:00 Robert Virding : >> >> It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has >> the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is >> trapping exits unless it is the 'kill' which is untrappable and the process always dies. >> >> >> Yes, but the 'kill' signal is not an exit signal with reason kill. The 'kill' signal can only be sent by calling exit/2 with >> Reason = kill, which is documented to have the effect that "an untrappable exit signal is sent to Pid which will >> unconditionally exit with exit reason killed." There is no mention of how the exit reason in that exit signal, and since it is >> not trappable there is no way to observe it. >> >> >> Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process >> >> Yes. >> >> >> as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'. >> >> No, this sends an exit signal with reason kill, but that is not the same ass the signal sent using exit(Pid, kill). >> >> >> In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the >> other it is untrappable. >> >> No, in one case it receives an exit signal with reason kill, in the other case it receives the special untrappable exit signal >> which causes unconditional termination. >> >> >> My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent. >> >> I agree that it is inconsistent. I would have preferred that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and >> that exit(Pid, kill) would be handled as any other exit/2 call. But I won't hold my breath in anticipation of that being >> changed... >> >> /H?kan >> >> >> Robert >> >> >> On 6 October 2015 at 18:33, zxq9 wrote: >> >> On Wednesday 07 October 2015 10:25:38 zxq9 wrote: >> >> > or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically untrappable by way of matching on self()? >> >> That was too much to hope for: >> >> 1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), Loop() end end). >> <0.1889.0> >> 2> P ! {'EXIT', P, kill}. >> Got {'EXIT',<0.1889.0>,kill} >> {'EXIT',<0.1889.0>,kill} >> 3> P ! {'EXIT', P, blam}. >> Got {'EXIT',<0.1889.0>,blam} >> {'EXIT',<0.1889.0>,blam} >> 4> exit(P, kill). >> true >> 5> P ! {'EXIT', P, blam}. >> {'EXIT',<0.1889.0>,blam} >> >> If it *did* turn out that matching {'EXIT', self(), kill} was untrappable I would just say "ah, that makes sense -- now >> I can understand the mechanism behind this without thinking about VM details". Instead it appears to be a case of >> mysterious activity underlying a message form that is semantically overloaded. And that stinks. >> >> -Craig >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> > >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From rvirding@REDACTED Fri Oct 9 02:28:07 2015 From: rvirding@REDACTED (Robert Virding) Date: Thu, 8 Oct 2015 17:28:07 -0700 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <20151008125730.GA1012@wagner.intra.a-tono.com> References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> <20151008125730.GA1012@wagner.intra.a-tono.com> Message-ID: I think to realise here is that exit(kill) sends a 'kill' SIGNAL not a message. It is the fact that the shell process is trapping exits which means that the signal is converted to a message when it arrives at the shell process. Sending a message, irrespective of it format, will never kill a process. My point was just that if the same 'kill' signal is sent by exit/1 or exit/2 it will result in different behaviour in the process which receives the signal. So it is not just the signal itself which causes the behaviour but how it was sent. I find this inconsistent. Should a word on the screen look different whether I write with the left hand or the right hand? Robert On 8 October 2015 at 05:57, Francesco Lattanzio < francesco.lattanzio@REDACTED> wrote: > But: > > 1> Pid = spawn_link(fun() -> exit(kill) end). > ** exception exit: killed > 2> f(). > ok > 3> process_flag(trap_exit, true). > false > 4> Pid = spawn_link(fun() -> exit(kill) end). > <0.40.0> > 5> flush(). > Shell got {'EXIT',<0.40.0>,kill} > ok > > Regards. > > On Thu, Oct 08, 2015 at 02:37:19PM +0200, Lo?c Hoguin wrote: > > On 10/07/2015 02:27 PM, Francesco Lattanzio wrote: > > >I always thought that when a process dies because it was sent a 'kill' > > >message it would broadcast to the linked processes a 'killed' EXIT > > >message (see Concurrent Programming in Erlang - Part I, D.3 Exit > > >signals, p. 193 ). > > >However for some reason recent implementations of the VM broadcasts a > > >'kill' EXIT message (I could only test it on Erlang VMs as old as > > >R13B04). > > > > 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > > <0.36.0> > > 2> exit(Pid, kill). > > ** exception exit: killed > > 3> f(). > > ok > > 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > > <0.41.0> > > 5> process_flag(trap_exit, true). > > false > > 6> exit(Pid, kill). > > true > > 7> flush(). > > Shell got {'EXIT',<0.41.0>,killed} > > ok > > > > Cheers, > > > > >I'm not asking to revert this behaviour (I bet such a change would > > >impact a lot of code), however it would be nice to know why it was > > >chosen a two-semantics kill message instead of more obvious two > > >one-semantic kill and killed message (if someone knows). > > > > > >On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote: > > >>I still find that extremely inconsistent, there are actually 2 'kill' > signals: one that is sent with exit(Pid, kill) and the other > > >>which sent when you do exit(kill). So I can trap 'kill' and I can't > trap 'kill', great. > > >> > > >>I would personally go the other way and say that kill is kill however > it is sent. But I agree with you, I'm not holding my breath > > >>waiting for it to be fixed. > > >> > > >>Robert > > >> > > >>P.S. I am not even going to mention the terribly inconsistent handling > of errors in link/1. > > >> > > >> > > >>On 7 October 2015 at 00:51, H?kan Huss wrote: > > >> > > >> 2015-10-07 3:46 GMT+02:00 Robert Virding : > > >> > > >> It's all about signals and not messages. Sending a message to > a process should *NEVER* by default kill it even if it has > > >> the same format as an 'EXIT' message. NEVER!. A signal is > converted to a message when it arrives at a process which is > > >> trapping exits unless it is the 'kill' which is untrappable > and the process always dies. > > >> > > >> > > >> Yes, but the 'kill' signal is not an exit signal with reason > kill. The 'kill' signal can only be sent by calling exit/2 with > > >> Reason = kill, which is documented to have the effect that "an > untrappable exit signal is sent to Pid which will > > >> unconditionally exit with exit reason killed." There is no > mention of how the exit reason in that exit signal, and since it is > > >> not trappable there is no way to observe it. > > >> > > >> > > >> Explicitly sending the SIGNAL with exit(Pid, kill) should > unconditionally kill the process > > >> > > >> Yes. > > >> > > >> > > >> as should dying with the reason 'kill' in exit(kill) which > also sends the SIGNAL 'kill'. > > >> > > >> No, this sends an exit signal with reason kill, but that is not > the same ass the signal sent using exit(Pid, kill). > > >> > > >> > > >> In both cases the process receives the SIGNAL 'kill', as > shown in my example, but in one case it is trappable and in the > > >> other it is untrappable. > > >> > > >> No, in one case it receives an exit signal with reason kill, in > the other case it receives the special untrappable exit signal > > >> which causes unconditional termination. > > >> > > >> > > >> My point is that the *same* signal results in different > behaviour depending on how it was sent. That's incocnsistent. > > >> > > >> I agree that it is inconsistent. I would have preferred that the > exit(Pid, kill) was a separate function, e.g., kill(Pid) and > > >> that exit(Pid, kill) would be handled as any other exit/2 call. > But I won't hold my breath in anticipation of that being > > >> changed... > > >> > > >> /H?kan > > >> > > >> > > >> Robert > > >> > > >> > > >> On 6 October 2015 at 18:33, zxq9 wrote: > > >> > > >> On Wednesday 07 October 2015 10:25:38 zxq9 wrote: > > >> > > >> > or maybe it is that {'EXIT', Pid = self(), kill} *is* > specifically untrappable by way of matching on self()? > > >> > > >> That was too much to hope for: > > >> > > >> 1> P = spawn(fun Loop() -> receive M -> io:format("Got > ~p~n", [M]), Loop() end end). > > >> <0.1889.0> > > >> 2> P ! {'EXIT', P, kill}. > > >> Got {'EXIT',<0.1889.0>,kill} > > >> {'EXIT',<0.1889.0>,kill} > > >> 3> P ! {'EXIT', P, blam}. > > >> Got {'EXIT',<0.1889.0>,blam} > > >> {'EXIT',<0.1889.0>,blam} > > >> 4> exit(P, kill). > > >> true > > >> 5> P ! {'EXIT', P, blam}. > > >> {'EXIT',<0.1889.0>,blam} > > >> > > >> If it *did* turn out that matching {'EXIT', self(), kill} > was untrappable I would just say "ah, that makes sense -- now > > >> I can understand the mechanism behind this without > thinking about VM details". Instead it appears to be a case of > > >> mysterious activity underlying a message form that is > semantically overloaded. And that stinks. > > >> > > >> -Craig > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questions@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-questions > > >> > > >> > > >> > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questions@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-questions > > >> > > >> > > >> > > >> > > >> > > > > > >>_______________________________________________ > > >>erlang-bugs mailing list > > >>erlang-bugs@REDACTED > > >>http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > -- > > Lo?c Hoguin > > http://ninenines.eu > > Author of The Erlanger Playbook, > > A book about software development using Erlang > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- > FRANCESCO LATTANZIO : SYSTEM & SOFTWARE > A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39 > 02 32069314 : SKYPE franz.lattanzio > a-tono.com : twitter.com/ATonoOfficial : facebook.com/ATonoOfficial > > Information in this email is confidential and may be privileged. It is > intended for the addresses only. > If you have received it in error, please notify the sender immediately and > delete it from your system. > You should not otherwise copy it, retransmit it or use or disclose its > content to anyone. Thank you for your co-operation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.karlsson@REDACTED Fri Oct 9 03:26:46 2015 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Fri, 9 Oct 2015 03:26:46 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> <20151008125730.GA1012@wagner.intra.a-tono.com> Message-ID: <561717D6.2030509@proxel.se> So Robert, tell me who missed it. What is the difference in behaviour when using exit/1 or exit/2? And is the difference still there if the process kills itself with exit/2? /Roland On 2015-10-09 02:28, Robert Virding wrote: > I think to realise here is that exit(kill) sends a 'kill' SIGNAL not a > message. It is the fact that the shell process is trapping exits which > means that the signal is converted to a message when it arrives at the > shell process. Sending a message, irrespective of it format, will > never kill a process. > > My point was just that if the same 'kill' signal is sent by exit/1 or > exit/2 it will result in different behaviour in the process which > receives the signal. So it is not just the signal itself which causes > the behaviour but how it was sent. I find this inconsistent. Should a > word on the screen look different whether I write with the left hand > or the right hand? > > Robert > > > On 8 October 2015 at 05:57, Francesco Lattanzio > > wrote: > > But: > > 1> Pid = spawn_link(fun() -> exit(kill) end). > ** exception exit: killed > 2> f(). > ok > 3> process_flag(trap_exit, true). > false > 4> Pid = spawn_link(fun() -> exit(kill) end). > <0.40.0> > 5> flush(). > Shell got {'EXIT',<0.40.0>,kill} > ok > > Regards. > > On Thu, Oct 08, 2015 at 02:37:19PM +0200, Lo?c Hoguin wrote: > > On 10/07/2015 02:27 PM, Francesco Lattanzio wrote: > > >I always thought that when a process dies because it was sent a > 'kill' > > >message it would broadcast to the linked processes a 'killed' EXIT > > >message (see Concurrent Programming in Erlang - Part I, D.3 Exit > > >signals, p. 193 ). > > >However for some reason recent implementations of the VM > broadcasts a > > >'kill' EXIT message (I could only test it on Erlang VMs as old as > > >R13B04). > > > > 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > > <0.36.0> > > 2> exit(Pid, kill). > > ** exception exit: killed > > 3> f(). > > ok > > 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > > <0.41.0> > > 5> process_flag(trap_exit, true). > > false > > 6> exit(Pid, kill). > > true > > 7> flush(). > > Shell got {'EXIT',<0.41.0>,killed} > > ok > > > > Cheers, > > > > >I'm not asking to revert this behaviour (I bet such a change would > > >impact a lot of code), however it would be nice to know why it was > > >chosen a two-semantics kill message instead of more obvious two > > >one-semantic kill and killed message (if someone knows). > > > > > >On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote: > > >>I still find that extremely inconsistent, there are actually 2 > 'kill' signals: one that is sent with exit(Pid, kill) and the other > > >>which sent when you do exit(kill). So I can trap 'kill' and I > can't trap 'kill', great. > > >> > > >>I would personally go the other way and say that kill is kill > however it is sent. But I agree with you, I'm not holding my breath > > >>waiting for it to be fixed. > > >> > > >>Robert > > >> > > >>P.S. I am not even going to mention the terribly inconsistent > handling of errors in link/1. > > >> > > >> > > >>On 7 October 2015 at 00:51, H?kan Huss > wrote: > > >> > > >> 2015-10-07 3:46 GMT+02:00 Robert Virding > >: > > >> > > >> It's all about signals and not messages. Sending a > message to a process should *NEVER* by default kill it even if it has > > >> the same format as an 'EXIT' message. NEVER!. A > signal is converted to a message when it arrives at a process which is > > >> trapping exits unless it is the 'kill' which is > untrappable and the process always dies. > > >> > > >> > > >> Yes, but the 'kill' signal is not an exit signal with > reason kill. The 'kill' signal can only be sent by calling exit/2 with > > >> Reason = kill, which is documented to have the effect > that "an untrappable exit signal is sent to Pid which will > > >> unconditionally exit with exit reason killed." There is > no mention of how the exit reason in that exit signal, and since it is > > >> not trappable there is no way to observe it. > > >> > > >> > > >> Explicitly sending the SIGNAL with exit(Pid, kill) > should unconditionally kill the process > > >> > > >> Yes. > > >> > > >> > > >> as should dying with the reason 'kill' in exit(kill) > which also sends the SIGNAL 'kill'. > > >> > > >> No, this sends an exit signal with reason kill, but that > is not the same ass the signal sent using exit(Pid, kill). > > >> > > >> > > >> In both cases the process receives the SIGNAL 'kill', > as shown in my example, but in one case it is trappable and in the > > >> other it is untrappable. > > >> > > >> No, in one case it receives an exit signal with reason > kill, in the other case it receives the special untrappable exit > signal > > >> which causes unconditional termination. > > >> > > >> > > >> My point is that the *same* signal results in > different behaviour depending on how it was sent. That's > incocnsistent. > > >> > > >> I agree that it is inconsistent. I would have preferred > that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and > > >> that exit(Pid, kill) would be handled as any other exit/2 > call. But I won't hold my breath in anticipation of that being > > >> changed... > > >> > > >> /H?kan > > >> > > >> > > >> Robert > > >> > > >> > > >> On 6 October 2015 at 18:33, zxq9 > wrote: > > >> > > >> On Wednesday 07 October 2015 10:25:38 zxq9 wrote: > > >> > > >> > or maybe it is that {'EXIT', Pid = self(), > kill} *is* specifically untrappable by way of matching on self()? > > >> > > >> That was too much to hope for: > > >> > > >> 1> P = spawn(fun Loop() -> receive M -> > io:format("Got ~p~n", [M]), Loop() end end). > > >> <0.1889.0> > > >> 2> P ! {'EXIT', P, kill}. > > >> Got {'EXIT',<0.1889.0>,kill} > > >> {'EXIT',<0.1889.0>,kill} > > >> 3> P ! {'EXIT', P, blam}. > > >> Got {'EXIT',<0.1889.0>,blam} > > >> {'EXIT',<0.1889.0>,blam} > > >> 4> exit(P, kill). > > >> true > > >> 5> P ! {'EXIT', P, blam}. > > >> {'EXIT',<0.1889.0>,blam} > > >> > > >> If it *did* turn out that matching {'EXIT', > self(), kill} was untrappable I would just say "ah, that makes > sense -- now > > >> I can understand the mechanism behind this > without thinking about VM details". Instead it appears to be a case of > > >> mysterious activity underlying a message form > that is semantically overloaded. And that stinks. > > >> > > >> -Craig > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questions@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-questions > > >> > > >> > > >> > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questions@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-questions > > >> > > >> > > >> > > >> > > >> > > > > > >>_______________________________________________ > > >>erlang-bugs mailing list > > >>erlang-bugs@REDACTED > > >>http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > -- > > Lo?c Hoguin > >http://ninenines.eu > > Author of The Erlanger Playbook, > > A book about software development using Erlang > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- > FRANCESCO LATTANZIO : SYSTEM & SOFTWARE > A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : > T +39 02 32069314 : SKYPE franz.lattanzio > a-tono.com : twitter.com/ATonoOfficial > : facebook.com/ATonoOfficial > > > Information in this email is confidential and may be privileged. > It is intended for the addresses only. > If you have received it in error, please notify the sender > immediately and delete it from your system. > You should not otherwise copy it, retransmit it or use or disclose > its content to anyone. Thank you for your co-operation. > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Oct 9 03:41:39 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 8 Oct 2015 20:41:39 -0500 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <561717D6.2030509@proxel.se> References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> <20151008125730.GA1012@wagner.intra.a-tono.com> <561717D6.2030509@proxel.se> Message-ID: <20151009014138.GL1744@fhebert-ltm1> On 10/09, Roland Karlsson wrote: >So Robert, tell me who missed it. >What is the difference in behaviour when using exit/1 or exit/2? >And is the difference still there if the process kills itself with exit/2? > >/Roland > exit/1 raises a 'kill' exception (you can do it with erlang:raise(exit, kill, Stacktrace)) that will unwind the stack and can be caught by try ... catch. In the case where the exception is not caught, the process is terminated and the reason of its death forwarded as a signal. exit/2 sends an exit signal asynchronously. The confusing aspect is that a 'kill' signal sent by exit/2 is untrappable, but a 'kill' signal that comes from a process terminating after an exception doesn't. This means the underlying secret is you have 2 levels of signals (at least): - termination signals (uncaught exception create one of these, dying from any other signal does the same) - kill signals (untrappable) The interesting bit then is why is there a need to translate 'kill' into 'killed'? From what I can tell, it's just so you can know the process was brutally killed -- if you only had 'kill' then you know it came from an exception. Buuuut here's the kicker: 1> spawn_link(fun() -> exit(kill) end), flush(). Shell got {'EXIT',<0.87.0>,kill} ok 2> spawn_link(fun() -> spawn_link(fun() -> exit(kill) end), timer:sleep(infinity) end), flush(). Shell got {'EXIT',<0.89.0>,killed} 3> spawn_link(fun() -> process_flag(trap_exit, true), spawn_link(fun() -> exit(kill) end), timer:sleep(infinity) end), flush(). ok woops. There's no real consistency there. In the end: - a special 'kill' signal that cannot be trapped will unconditionally kill a process and produce a signal 'killed' for peer processes - an exception 'kill' bubbling up is reported as a trappable exit signal with the reason 'kill' - that 'kill' exit signal is converted to 'killed' for other processes, regardless of the source, as long as it's not from a local stack. This just sounds like a leaky abstraction where the conversion of kill -> killed only takes place on incoming signals being converted, unconditionally. Still, you have two types of signals: untrappable (exit(Pid, kill)), and trappable (anything else, even with a reason kill, if produced from a stacktrace). It's confusing and always has been so. From sdl.web@REDACTED Fri Oct 9 03:59:01 2015 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 09 Oct 2015 09:59:01 +0800 Subject: [erlang-bugs] [PATCH] Prefer details in cdv_ets_cb:init_gen_page/2 Message-ID: Hi, When viewing the details page of an ETS table in crashdump_viewer, it always shows the `data structure' as `hash'. Could someone see if this is an oversight and the following patch is intended? Thanks. Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Prefer-details-in-cdv_ets_cb-init_gen_page-2.patch Type: text/x-patch Size: 930 bytes Desc: 0001-Prefer-details-in-cdv_ets_cb-init_gen_page-2.patch URL: From francesco.lattanzio@REDACTED Thu Oct 8 14:57:30 2015 From: francesco.lattanzio@REDACTED (Francesco Lattanzio) Date: Thu, 8 Oct 2015 14:57:30 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <5616637F.4010102@ninenines.eu> References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> Message-ID: <20151008125730.GA1012@wagner.intra.a-tono.com> But: 1> Pid = spawn_link(fun() -> exit(kill) end). ** exception exit: killed 2> f(). ok 3> process_flag(trap_exit, true). false 4> Pid = spawn_link(fun() -> exit(kill) end). <0.40.0> 5> flush(). Shell got {'EXIT',<0.40.0>,kill} ok Regards. On Thu, Oct 08, 2015 at 02:37:19PM +0200, Lo?c Hoguin wrote: > On 10/07/2015 02:27 PM, Francesco Lattanzio wrote: > >I always thought that when a process dies because it was sent a 'kill' > >message it would broadcast to the linked processes a 'killed' EXIT > >message (see Concurrent Programming in Erlang - Part I, D.3 Exit > >signals, p. 193 ). > >However for some reason recent implementations of the VM broadcasts a > >'kill' EXIT message (I could only test it on Erlang VMs as old as > >R13B04). > > 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > <0.36.0> > 2> exit(Pid, kill). > ** exception exit: killed > 3> f(). > ok > 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end). > <0.41.0> > 5> process_flag(trap_exit, true). > false > 6> exit(Pid, kill). > true > 7> flush(). > Shell got {'EXIT',<0.41.0>,killed} > ok > > Cheers, > > >I'm not asking to revert this behaviour (I bet such a change would > >impact a lot of code), however it would be nice to know why it was > >chosen a two-semantics kill message instead of more obvious two > >one-semantic kill and killed message (if someone knows). > > > >On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote: > >>I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other > >>which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great. > >> > >>I would personally go the other way and say that kill is kill however it is sent. But I agree with you, I'm not holding my breath > >>waiting for it to be fixed. > >> > >>Robert > >> > >>P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1. > >> > >> > >>On 7 October 2015 at 00:51, H?kan Huss wrote: > >> > >> 2015-10-07 3:46 GMT+02:00 Robert Virding : > >> > >> It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has > >> the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is > >> trapping exits unless it is the 'kill' which is untrappable and the process always dies. > >> > >> > >> Yes, but the 'kill' signal is not an exit signal with reason kill. The 'kill' signal can only be sent by calling exit/2 with > >> Reason = kill, which is documented to have the effect that "an untrappable exit signal is sent to Pid which will > >> unconditionally exit with exit reason killed." There is no mention of how the exit reason in that exit signal, and since it is > >> not trappable there is no way to observe it. > >> > >> > >> Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process > >> > >> Yes. > >> > >> > >> as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'. > >> > >> No, this sends an exit signal with reason kill, but that is not the same ass the signal sent using exit(Pid, kill). > >> > >> > >> In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the > >> other it is untrappable. > >> > >> No, in one case it receives an exit signal with reason kill, in the other case it receives the special untrappable exit signal > >> which causes unconditional termination. > >> > >> > >> My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent. > >> > >> I agree that it is inconsistent. I would have preferred that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and > >> that exit(Pid, kill) would be handled as any other exit/2 call. But I won't hold my breath in anticipation of that being > >> changed... > >> > >> /H?kan > >> > >> > >> Robert > >> > >> > >> On 6 October 2015 at 18:33, zxq9 wrote: > >> > >> On Wednesday 07 October 2015 10:25:38 zxq9 wrote: > >> > >> > or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically untrappable by way of matching on self()? > >> > >> That was too much to hope for: > >> > >> 1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), Loop() end end). > >> <0.1889.0> > >> 2> P ! {'EXIT', P, kill}. > >> Got {'EXIT',<0.1889.0>,kill} > >> {'EXIT',<0.1889.0>,kill} > >> 3> P ! {'EXIT', P, blam}. > >> Got {'EXIT',<0.1889.0>,blam} > >> {'EXIT',<0.1889.0>,blam} > >> 4> exit(P, kill). > >> true > >> 5> P ! {'EXIT', P, blam}. > >> {'EXIT',<0.1889.0>,blam} > >> > >> If it *did* turn out that matching {'EXIT', self(), kill} was untrappable I would just say "ah, that makes sense -- now > >> I can understand the mechanism behind this without thinking about VM details". Instead it appears to be a case of > >> mysterious activity underlying a message form that is semantically overloaded. And that stinks. > >> > >> -Craig > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > >> > >> > >> > > > >>_______________________________________________ > >>erlang-bugs mailing list > >>erlang-bugs@REDACTED > >>http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- FRANCESCO LATTANZIO : SYSTEM & SOFTWARE A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39 02 32069314 : SKYPE franz.lattanzio a-tono.com : twitter.com/ATonoOfficial : facebook.com/ATonoOfficial Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. From essen@REDACTED Fri Oct 9 21:13:29 2015 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 9 Oct 2015 21:13:29 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <08cbe95218f76510e156d649cda2c893.squirrel@klotjohan.proxel.se> References: <4419117.afWZKFkaIl@burrito> <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> <20151008125730.GA1012@wagner.intra.a-tono.com> <561717D6.2030509@proxel.se> <20151009014138.GL1744@fhebert-ltm1> <08cbe95218f76510e156d649cda2c893.squirrel@klotjohan.proxel.se> Message-ID: <561811D9.9000806@ninenines.eu> On 10/09/2015 10:35 AM, Roland Karlsson wrote: > Woa! > > Thanx for explaining it so well! > > This seems so wrong that I am ashamed being an Erlang evangelist. > I just want to lay down, curl together and cry. > > I have always assumed exit/1 just was implemented as > exit(Reason) -> exit(self(),Reason). > Or, at least, that they had the same semantics. > > Looking in the manual, I see that exit/1 and exit/2 are > correctly described, and I do understand the need > for both (maybe) as exit/1 is synchronous. > > Personally I think exit/2 shall be > deprecated and renamed to send_exit_signal/2 or maybe kill/2. Considering it is called an "exit signal", the name makes sense, although it is confusing. Another clue is that exit/2 does not have error/2 or throw/2 equivalents. Perhaps kill/2 would be better (and would also match the kill command on unix) but I don't see it improve things much. You still have the kill special case with all attached problems. On the other hand, if you had exit/2 (or kill/2) just sending an exit signal (even if reason is kill), and kill/1 sending a kill signal, then things would become much clearer. A change like this would take many years though. > To be frank, I have never really liked the exit/2 name as > it seems counter intuitive to exit someone else. > > > /Roland > > > > >> On 10/09, Roland Karlsson wrote: >>> So Robert, tell me who missed it. >>> What is the difference in behaviour when using exit/1 or exit/2? >>> And is the difference still there if the process kills itself with >>> exit/2? >>> >>> /Roland >>> >> >> exit/1 raises a 'kill' exception (you can do it with erlang:raise(exit, >> kill, Stacktrace)) that will unwind the stack and can be caught by try >> ... catch. In the case where the exception is not caught, the process is >> terminated and the reason of its death forwarded as a signal. >> >> exit/2 sends an exit signal asynchronously. >> >> The confusing aspect is that a 'kill' signal sent by exit/2 is >> untrappable, but a 'kill' signal that comes from a process terminating >> after an exception doesn't. >> >> This means the underlying secret is you have 2 levels of signals (at >> least): >> >> - termination signals (uncaught exception create one of these, dying >> from any other signal does the same) >> - kill signals (untrappable) >> >> The interesting bit then is why is there a need to translate 'kill' into >> 'killed'? From what I can tell, it's just so you can know the process >> was brutally killed -- if you only had 'kill' then you know it came from >> an exception. Buuuut here's the kicker: >> >> 1> spawn_link(fun() -> exit(kill) end), flush(). >> Shell got {'EXIT',<0.87.0>,kill} >> ok >> 2> spawn_link(fun() -> spawn_link(fun() -> exit(kill) end), >> timer:sleep(infinity) end), flush(). >> Shell got {'EXIT',<0.89.0>,killed} >> 3> spawn_link(fun() -> process_flag(trap_exit, true), spawn_link(fun() >> -> exit(kill) end), timer:sleep(infinity) end), flush(). >> ok >> >> woops. There's no real consistency there. In the end: >> >> - a special 'kill' signal that cannot be trapped will unconditionally >> kill a process and produce a signal 'killed' for peer processes >> - an exception 'kill' bubbling up is reported as a trappable exit signal >> with the reason 'kill' >> - that 'kill' exit signal is converted to 'killed' for other processes, >> regardless of the source, as long as it's not from a local stack. >> >> This just sounds like a leaky abstraction where the conversion of kill >> -> killed only takes place on incoming signals being converted, >> unconditionally. Still, you have two types of signals: untrappable >> (exit(Pid, kill)), and trappable (anything else, even with a reason >> kill, if produced from a stacktrace). >> >> It's confusing and always has been so. >> > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From francesco.lattanzio@REDACTED Sat Oct 10 12:05:44 2015 From: francesco.lattanzio@REDACTED (Francesco Lattanzio) Date: Sat, 10 Oct 2015 12:05:44 +0200 Subject: [erlang-bugs] [erlang-questions] Strange behaviour of exit(kill) In-Reply-To: <20151009014138.GL1744@fhebert-ltm1> References: <1713776.Oj5rNu4sYV@burrito> <20151007122725.GB3459@wagner.intra.a-tono.com> <5616637F.4010102@ninenines.eu> <20151008125730.GA1012@wagner.intra.a-tono.com> <561717D6.2030509@proxel.se> <20151009014138.GL1744@fhebert-ltm1> Message-ID: <20151010100544.GA40128@blackheart.bluenet.org> After reading your email, I started browsing the code out of curiosity and I found something I deem is a bug (see PR #854, https://github.com/erlang/otp/pull/854). On Thu, Oct 08, 2015 at 08:41:39PM -0500, Fred Hebert wrote: > On 10/09, Roland Karlsson wrote: > >So Robert, tell me who missed it. > >What is the difference in behaviour when using exit/1 or exit/2? > >And is the difference still there if the process kills itself with exit/2? > > > >/Roland > > > > exit/1 raises a 'kill' exception (you can do it with erlang:raise(exit, > kill, Stacktrace)) that will unwind the stack and can be caught by try > ... catch. In the case where the exception is not caught, the process is > terminated and the reason of its death forwarded as a signal. > > exit/2 sends an exit signal asynchronously. > > The confusing aspect is that a 'kill' signal sent by exit/2 is > untrappable, but a 'kill' signal that comes from a process terminating > after an exception doesn't. > > This means the underlying secret is you have 2 levels of signals (at > least): > > - termination signals (uncaught exception create one of these, dying > from any other signal does the same) > - kill signals (untrappable) > > The interesting bit then is why is there a need to translate 'kill' into > 'killed'? From what I can tell, it's just so you can know the process > was brutally killed -- if you only had 'kill' then you know it came from > an exception. Buuuut here's the kicker: > > 1> spawn_link(fun() -> exit(kill) end), flush(). > Shell got {'EXIT',<0.87.0>,kill} > ok > 2> spawn_link(fun() -> spawn_link(fun() -> exit(kill) end), > timer:sleep(infinity) end), flush(). > Shell got {'EXIT',<0.89.0>,killed} > 3> spawn_link(fun() -> process_flag(trap_exit, true), spawn_link(fun() > -> exit(kill) end), timer:sleep(infinity) end), flush(). > ok > > woops. There's no real consistency there. In the end: > > - a special 'kill' signal that cannot be trapped will unconditionally > kill a process and produce a signal 'killed' for peer processes > - an exception 'kill' bubbling up is reported as a trappable exit signal > with the reason 'kill' > - that 'kill' exit signal is converted to 'killed' for other processes, > regardless of the source, as long as it's not from a local stack. > > This just sounds like a leaky abstraction where the conversion of kill > -> killed only takes place on incoming signals being converted, > unconditionally. Still, you have two types of signals: untrappable > (exit(Pid, kill)), and trappable (anything else, even with a reason > kill, if produced from a stacktrace). > > It's confusing and always has been so. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- FRANCESCO LATTANZIO : SYSTEM & SOFTWARE A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39 02 32069314 : F +39 02 32069100 : SKYPE franz.lattanzio a-tono.com : faromobile.com : twitter.com/atono : facebook.com/atono Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. From dangud@REDACTED Mon Oct 12 15:10:45 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 12 Oct 2015 13:10:45 +0000 Subject: [erlang-bugs] [PATCH] Prefer details in cdv_ets_cb:init_gen_page/2 In-Reply-To: References: Message-ID: I think this patch is better.. diff --git a/lib/observer/src/crashdump_viewer.erl b/lib/observer/src/crashdump_viewer.erl index f2ce51b..b66b4d5 100644 --- a/lib/observer/src/crashdump_viewer.erl +++ b/lib/observer/src/crashdump_viewer.erl @@ -1572,7 +1572,7 @@ get_etsinfo(Fd,EtsTable = #ets_table{details=Ds},WS) -> get_etsinfo(Fd,EtsTable#ets_table{details=Ds#{fixed=>Val}},WS); "Type" -> Val = val(Fd), - get_etsinfo(Fd,EtsTable#ets_table{details=Ds#{data_type=>Val}},WS); + get_etsinfo(Fd,EtsTable#ets_table{data_type=Val},WS); "Protection" -> Val = val(Fd), get_etsinfo(Fd,EtsTable#ets_table{details=Ds#{protection=>Val}},WS); On Fri, Oct 9, 2015 at 3:59 AM Leo Liu wrote: > Hi, > > When viewing the details page of an ETS table in crashdump_viewer, it > always shows the `data structure' as `hash'. Could someone see if this > is an oversight and the following patch is intended? Thanks. > > Leo > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Mon Oct 19 20:04:57 2015 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 19 Oct 2015 19:04:57 +0100 Subject: [erlang-bugs] Race condition in TLS distribution Message-ID: Hi all, I'm trying to use Erlang distribution over TLS ("-proto_dist inet_tls"), and I've stumbled upon an interesting race condition. The kernel supervisor starts the distribution subsystem before it starts the code server. Therefore, it's possible for another node to establish a connection to the distribution port while the code server is not yet running. (Apologies for not providing a recipe for reproducing this; I could work on that if that would be useful.) In that case, the TLS distribution module eventually calls ssl:ssl_accept/2 on the connection socket. This in turn will eventually call crypto:supports/0. That's when I got this error: {error_logger,{{2015,10,19},{15,1,22}}, supervisor_report, [{supervisor,{local,ssl_dist_sup}}, {errorContext,child_terminated}, {reason,{undef,[{crypto,supports,[],[]}, {tls_record,supported_protocol_versions,1,[{file,"tls_record.erl"},{line,322}]}, {tls_record,supported_protocol_versions,0, [{file,"tls_record.erl"},{line,257}]}, {ssl,handle_options,1,[{file,"ssl.erl"},{line,617}]}, {ssl,ssl_accept,3,[{file,"ssl.erl"},{line,228}]}, {ssl_tls_dist_proxy,accept_loop,4,[{file,"ssl_tls_dist_proxy.erl"},{line,152}]}]}}, {offender,[{pid,<0.22.0>}, {name,ssl_tls_dist_proxy}, {mfargs,{ssl_tls_dist_proxy,start_link,[]}}, {restart_type,permanent}, {shutdown,4000}, {child_type,worker}]}]} (though it was formatted as one long line, using the kernel's primitive error reporter.) Why is that function undefined, you ask. That's because the crypto module has an on_load function, which calls code:priv_dir/1 to figure out where the NIF library is. Since the code server isn't running yet, code:priv_dir/1 raises an exception, and as I just learnt from reading the documentation, if an on_load function raises an exception (or returns anything but 'ok'), the module is unloaded - and thus we get an 'undef' error. (This will make the ssl_tls_dist_proxy process terminate. Its supervisor will restart it, but that doesn't help: it has lost its listening socket, and net_kernel won't ask it to open another one, rendering the node "alive" but unable to receive connections for distribution - but that's a separate issue.) I came up with the attached patch, which waits for the code server to start before proceeding, and that fixes the problem for me. What do you think about it? Might there be a better way to solve this? Regards, Magnus -------------- next part -------------- A non-text attachment was scrubbed... Name: wait-for-code-server.patch Type: text/x-patch Size: 2024 bytes Desc: not available URL: From mononcqc@REDACTED Mon Oct 19 22:05:14 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 19 Oct 2015 16:05:14 -0400 Subject: [erlang-bugs] Race condition in TLS distribution In-Reply-To: References: Message-ID: <20151019200513.GS1744@fhebert-ltm1> On 10/19, Magnus Henoch wrote: >I came up with the attached patch, which waits for the code server to >start before proceeding, and that fixes the problem for me. What do you >think about it? Might there be a better way to solve this? > I think one of the gotchas is that the code server could be loading code from over the network when running on diskless node, a thing the OTP team supports. In such cases, it would be impossible to use SSL as a transport mechanism as it would require to load the crypto stuff from over the network, but the crypto library would be required to establish a connection over the network, leaving you in an unbootable state. I have never tried this and have no proof it's an actual problem, but it's a possible circular dependency between protocol and diskless nodes that comes up in a thought exercise. Regards, Fred. From magnus@REDACTED Tue Oct 20 18:51:02 2015 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 20 Oct 2015 17:51:02 +0100 Subject: [erlang-bugs] Race condition in TLS distribution In-Reply-To: References: Message-ID: I just noticed an alternative solution in the example uds_server.erl. It jumps through a number of hoops to get the priv directory even if the code server is not running: https://github.com/erlang/otp/blob/maint/lib/kernel/examples/uds_dist/src/uds_server.erl#L107-L148 Perhaps the crypto module could do something similar in its on_load function. Regards, Magnus On Mon, Oct 19, 2015 at 7:04 PM, Magnus Henoch wrote: > Hi all, > > I'm trying to use Erlang distribution over TLS ("-proto_dist inet_tls"), > and I've stumbled upon an interesting race condition. > > The kernel supervisor starts the distribution subsystem before it starts > the code server. Therefore, it's possible for another node to establish a > connection to the distribution port while the code server is not yet > running. (Apologies for not providing a recipe for reproducing this; I > could work on that if that would be useful.) > > In that case, the TLS distribution module eventually calls > ssl:ssl_accept/2 on the connection socket. This in turn will eventually > call crypto:supports/0. That's when I got this error: > > {error_logger,{{2015,10,19},{15,1,22}}, > supervisor_report, > [{supervisor,{local,ssl_dist_sup}}, > {errorContext,child_terminated}, > {reason,{undef,[{crypto,supports,[],[]}, > > {tls_record,supported_protocol_versions,1,[{file,"tls_record.erl"},{line,322}]}, > {tls_record,supported_protocol_versions,0, > [{file,"tls_record.erl"},{line,257}]}, > {ssl,handle_options,1,[{file,"ssl.erl"},{line,617}]}, > {ssl,ssl_accept,3,[{file,"ssl.erl"},{line,228}]}, > > {ssl_tls_dist_proxy,accept_loop,4,[{file,"ssl_tls_dist_proxy.erl"},{line,152}]}]}}, > {offender,[{pid,<0.22.0>}, > {name,ssl_tls_dist_proxy}, > {mfargs,{ssl_tls_dist_proxy,start_link,[]}}, > {restart_type,permanent}, > {shutdown,4000}, > {child_type,worker}]}]} > > (though it was formatted as one long line, using the kernel's primitive > error reporter.) > > Why is that function undefined, you ask. That's because the crypto module > has an on_load function, which calls code:priv_dir/1 to figure out where > the NIF library is. Since the code server isn't running yet, > code:priv_dir/1 raises an exception, and as I just learnt from reading the > documentation, if an on_load function raises an exception (or returns > anything but 'ok'), the module is unloaded - and thus we get an 'undef' > error. > > (This will make the ssl_tls_dist_proxy process terminate. Its supervisor > will restart it, but that doesn't help: it has lost its listening socket, > and net_kernel won't ask it to open another one, rendering the node "alive" > but unable to receive connections for distribution - but that's a separate > issue.) > > I came up with the attached patch, which waits for the code server to > start before proceeding, and that fixes the problem for me. What do you > think about it? Might there be a better way to solve this? > > Regards, > Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed Oct 21 21:00:30 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 21 Oct 2015 21:00:30 +0200 Subject: [erlang-bugs] [erlang-questions] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org In-Reply-To: References: Message-ID: <5627E0CE.7020006@cs.ntua.gr> On 10/21/2015 05:13 PM, Bruce Yinhe wrote: > We are happy to announce the issue tracker for Erlang/OTP > (http://bugs.erlang.org ). Our intention is > that the issue tracker replaces the erlang-bugs mailing list, in order > to make it easier for the community to report bugs, suggest improvements > and new features. You can start using the issue tracker today. > > The issue tracker for Erlang/OTP is a step towards improving and > formalising the process of community contributions, a goal which is > actively worked on by the Industrial Erlang User Group. The IEUG is > working with Ericsson to improve libraries, tool chains, middle-ware and > contributions while spreading awareness and increasing user adoption. > > *FAQ* > * > * > *1. Where is the issue tracker?* > > bugs.erlang.org > > *2. Will I still be able to use the erlang-bugs mailing list?* > > We recommend you to report new bugs at bugs.erlang.org > instead. You are still able to use erlang-bugs > and see its archives, but we won't be looking at it as often. We will > gradually phase out the erlang-bugs mailing list. > > *3. How do I create an issue or feature request?* > > Create an account or Log in with an existing account. Select Create > Issue after you log in. You can also log in with your Erlangcentral.org > account if you have one. I very much welcome a public issue tracker -- thanks for this initiative! -- but I am wondering what exactly is the rationale for choosing this particular process. The Erlang/OTP system is hosted on GitHub, and GitHub already has (very nice, IMO) infrastructure for reporting and tracking issues (across all github code bases, actually). Moreover, there are also mechanisms of pointing to lines of code in (some branch) in the repo and to discussions of pull requests. Why re-invent the wheel (and complicate our lives)? Don't we all manage enough accounts already? Kostis From jesper.louis.andersen@REDACTED Wed Oct 21 21:29:55 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 21 Oct 2015 21:29:55 +0200 Subject: [erlang-bugs] [erlang-questions] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org In-Reply-To: <5627E0CE.7020006@cs.ntua.gr> References: <5627E0CE.7020006@cs.ntua.gr> Message-ID: On Wed, Oct 21, 2015 at 9:00 PM, Kostis Sagonas wrote: > Why re-invent the wheel (and complicate our lives)? On the Jira/Bugzilla scale, Github Issues tracks in at about 1 nano-Jira. That is, Jira can do some things in the enterprise setting which you can't easily get with Github. It is nice for small simple projects, but there are many large projects which run their "own" Jira-instances for the reason of interoperating. If I remember correctly, Jira can link to other internal Jira's at Ericsson, which is necessary to be able to track issues cross-projects, some of which are obviously internal and closed source. Given such constraints, running your own instance on the "outside of the firewall/walled garden" is the right choice. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Oct 21 21:38:51 2015 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 21 Oct 2015 21:38:51 +0200 Subject: [erlang-bugs] [erlang-questions] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org In-Reply-To: References: <5627E0CE.7020006@cs.ntua.gr> Message-ID: <5627E9CB.1080107@ninenines.eu> On 10/21/2015 09:29 PM, Jesper Louis Andersen wrote: > > On Wed, Oct 21, 2015 at 9:00 PM, Kostis Sagonas > wrote: > > Why re-invent the wheel (and complicate our lives)? > > > On the Jira/Bugzilla scale, Github Issues tracks in at about 1 nano-Jira. > > That is, Jira can do some things in the enterprise setting which you > can't easily get with Github. It is nice for small simple projects, but > there are many large projects which run their "own" Jira-instances for > the reason of interoperating. If I remember correctly, Jira can link to > other internal Jira's at Ericsson, which is necessary to be able to > track issues cross-projects, some of which are obviously internal and > closed source. Given such constraints, running your own instance on the > "outside of the firewall/walled garden" is the right choice. Would be good to at least be able to log in with your Github account, if nothing else. Apparently it can use OpenID for log in, but for some reason it's restricted to Erlang Central accounts. Adding Github would make it easier to contributors since they already have an account on Github. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From community-manager@REDACTED Wed Oct 21 17:13:12 2015 From: community-manager@REDACTED (Bruce Yinhe) Date: Wed, 21 Oct 2015 17:13:12 +0200 Subject: [erlang-bugs] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org Message-ID: Hello everyone We are happy to announce the issue tracker for Erlang/OTP ( http://bugs.erlang.org). Our intention is that the issue tracker replaces the erlang-bugs mailing list, in order to make it easier for the community to report bugs, suggest improvements and new features. You can start using the issue tracker today. The issue tracker for Erlang/OTP is a step towards improving and formalising the process of community contributions, a goal which is actively worked on by the Industrial Erlang User Group. The IEUG is working with Ericsson to improve libraries, tool chains, middle-ware and contributions while spreading awareness and increasing user adoption. *FAQ* *1. Where is the issue tracker?* bugs.erlang.org *2. Will I still be able to use the erlang-bugs mailing list?* We recommend you to report new bugs at bugs.erlang.org instead. You are still able to use erlang-bugs and see its archives, but we won't be looking at it as often. We will gradually phase out the erlang-bugs mailing list. *3. How do I create an issue or feature request?* Create an account or Log in with an existing account. Select Create Issue after you log in. You can also log in with your Erlangcentral.org account if you have one. *4. What types of issue can I report?* Bug, Improvement, New Feature Best regards Bruce Yinhe Community Manager Industrial Erlang User Group +46 72 311 43 89 community-manager@REDACTED -- Visit our Erlang community site ErlangCentral.org | @ErlangCentral | Industrial Erlang User Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunaku@REDACTED Wed Oct 21 23:48:44 2015 From: sunaku@REDACTED (Suraj N. Kurapati) Date: Wed, 21 Oct 2015 14:48:44 -0700 Subject: [erlang-bugs] leex extended regexp {m,n} quantifiers Message-ID: <20151021144844.19ba4af7@yantram> Hello, I'm using Erlang/OTP 18.1 ([erts-7.1] [source] [64-bit] [smp:24:24] [async-threads:10] [hipe] [kernel-poll:false]) where I find that leex does not honor extended regexp numerical repetition quantifiers [1]. For example, I'm trying to recognize exactly 11, 10, or 7 uppercase alphanumeric characters as a product_id in a leex rule, as follows: [A-Z0-9]{11}|[A-Z0-9]{10}|[A-Z0-9]{7} : {token, {product_id, TokenLine, TokenChars}}. However, that didn't work, so I tried using AWK syntax [2] exactly: [A-Z0-9]\{11\}|[A-Z0-9]\{10\}|[A-Z0-9]\{7\} : {token, {product_id, TokenLine, TokenChars}}. However, that didn't work either, so I was forced to expand it out: [A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]|[A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]|[A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9] : {token, {product_id, TokenLine, TokenChars}}. This is a giant step backwards in terms of regexp readability and maintainability, so please make leex honor the extended regexp numerical repetition quantifiers [1] since AWK supports them [2]. Furthermore, it seems that this work had already been started [3] but, for reasons unknown to me, was commented-out in the code [4]. Thanks for your consideration. [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_06 [2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_04 [3] https://github.com/erlang/otp/blob/maint/lib/parsetools/src/leex.erl#L138 [4] https://github.com/erlang/otp/blob/maint/lib/parsetools/src/leex.erl#L692-L700 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From sunaku@REDACTED Thu Oct 22 18:55:53 2015 From: sunaku@REDACTED (Suraj N. Kurapati) Date: Thu, 22 Oct 2015 09:55:53 -0700 Subject: [erlang-bugs] leex extended regexp {m,n} quantifiers In-Reply-To: <20151021144844.19ba4af7@yantram> References: <20151021144844.19ba4af7@yantram> Message-ID: <20151022095553.111f3076@yantram> Note: I've filed this bug report at: http://bugs.erlang.org/browse/ERL-31 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From albin.stigo@REDACTED Mon Oct 26 11:14:42 2015 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Mon, 26 Oct 2015 11:14:42 +0100 Subject: [erlang-bugs] erl -make returns 0 on failure. Message-ID: Hello, I'm pretty new to Erlang and I guess this is an old discussion. But why do erl -make return 0 even on error? It makes it harder to do: erl -make && erl -pa ebin/ test/ -noshell -s r1_tests test -s init stop I have found some previous posts about it through google but they normally boil down to "write a wrapper". --Albin From magnus@REDACTED Mon Oct 26 12:28:42 2015 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 26 Oct 2015 11:28:42 +0000 Subject: [erlang-bugs] erl -make returns 0 on failure. In-Reply-To: References: Message-ID: I posted a patch for that a while ago: http://erlang.org/pipermail/erlang-patches/2009-March/000390.html I got neither positive nor negative responses to it, so I'm not sure what the general opinion is on this. If anyone feels like it, feel free to try resubmitting the patch as a pull request. Regards, Magnus On Mon, Oct 26, 2015 at 10:14 AM, Albin Stig? wrote: > Hello, > > I'm pretty new to Erlang and I guess this is an old discussion. But why do > > erl -make > > return 0 even on error? It makes it harder to do: > > erl -make && erl -pa ebin/ test/ -noshell -s r1_tests test -s init stop > > I have found some previous posts about it through google but they > normally boil down to "write a wrapper". > > > --Albin > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.x.nord@REDACTED Mon Oct 26 14:45:43 2015 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Mon, 26 Oct 2015 14:45:43 +0100 Subject: [erlang-bugs] [erlang-questions] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org In-Reply-To: <5627E9CB.1080107@ninenines.eu> References: <5627E0CE.7020006@cs.ntua.gr> <5627E9CB.1080107@ninenines.eu> Message-ID: <562E2E87.40705@ericsson.com> On 10/21/2015 09:38 PM, Lo?c Hoguin wrote: > Would be good to at least be able to log in with your Github account, > if nothing else. Apparently it can use OpenID for log in, but for some > reason it's restricted to Erlang Central accounts. Adding Github would > make it easier to contributors since they already have an account on > Github. > This should be fixed. From magnus@REDACTED Mon Oct 26 16:57:19 2015 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 26 Oct 2015 15:57:19 +0000 Subject: [erlang-bugs] erl -make returns 0 on failure. In-Reply-To: References: Message-ID: On Mon, Oct 26, 2015 at 11:28 AM, Magnus Henoch wrote: > I posted a patch for that a while ago: > > http://erlang.org/pipermail/erlang-patches/2009-March/000390.html > > I got neither positive nor negative responses to it, so I'm not sure what > the general opinion is on this. If anyone feels like it, feel free to try > resubmitting the patch as a pull request. > Well, I just did it myself. Here it is: https://github.com/erlang/otp/pull/872 Regards, Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From louis-philippe.gauthier@REDACTED Tue Oct 27 14:14:39 2015 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Tue, 27 Oct 2015 09:14:39 -0400 Subject: [erlang-bugs] [erlang-questions] [ANN] Announcing Erlang Issue Tracker bugs.erlang.org In-Reply-To: <562E2E87.40705@ericsson.com> References: <5627E0CE.7020006@cs.ntua.gr> <5627E9CB.1080107@ninenines.eu> <562E2E87.40705@ericsson.com> Message-ID: FYI, I tried logging in with Github and got the following error message: OpenID Failed There was a problem during authentication. Please refer to logs for an additional info. On Mon, Oct 26, 2015 at 9:45 AM, Henrik Nord X wrote: > > > On 10/21/2015 09:38 PM, Lo?c Hoguin wrote: > >> Would be good to at least be able to log in with your Github account, if >> nothing else. Apparently it can use OpenID for log in, but for some reason >> it's restricted to Erlang Central accounts. Adding Github would make it >> easier to contributors since they already have an account on Github. >> >> > This should be fixed. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: