From danek.duvall@REDACTED Sat Jun 1 00:40:02 2013 From: danek.duvall@REDACTED (Danek Duvall) Date: Fri, 31 May 2013 15:40:02 -0700 Subject: [erlang-bugs] epmd exit status Message-ID: <20130531224002.GZ2488@smelly.us.oracle.com> I've noticed that in certain failure cases, epmd exits with a 0 status code. Things like -kill didn't work because there are still nodes in the database, or it failed to bind to the port because something was already bound. If I were to work up a patch to change these failures to cause epmd to exit 1, would it be accepted, or is there a reason that it is the way it is? Thanks, Danek From eric.pailleau@REDACTED Sat Jun 1 17:10:08 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 01 Jun 2013 17:10:08 +0200 Subject: [erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return . Message-ID: <51AA0ED0.8010006@wanadoo.fr> Hello, while io:rows(), io:nl() and io:columns() in the Erlang shell are working, I tried the arity /1 of those functions with self() as argument. All those functions with such argment looks to never return . Regards From aronisstav@REDACTED Tue Jun 4 17:23:50 2013 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 4 Jun 2013 17:23:50 +0200 Subject: [erlang-bugs] Fwd: Internal error in lint_module In-Reply-To: References: Message-ID: Version: ------------ Erlang R16B01 [source-01eb200], Steps to reproduce: ----------------------------- After cloning this repository... git clone git://github.com/abhay/eunit.git and running... make I get a crash from the lint_module: erlc -pa ../ebin -W -I../include +warn_unused_vars +nowarn_shadow_vars +warn_unused_import -o../ebin eunit.erl eunit.erl:none: internal error in lint_module; crash reason: {function_clause, [{erl_lint,expr, [{record_field, [{line,{"eunit.erl",0}}], {atom,[{line,{"eunit.erl",0}}],''}, {atom,[{line,{"eunit.erl",0}}],eunit}}, [],... Analysis: ------------- It is related to the deletion of a clause in erl_lint that was handling packages: Commit: 1c1649481025236cad29a7ee3cbd8f552757b2b6 Author: Bj?rn Gustavsson Date: Mon Dec 3 14:45:10 2012 +0100 erl_lint: Remove support for packages @@ -2086,13 +2030,6 @@ expr({record,Line,Name,Inits}, Vt, St) -> fun (Dfs, St1) -> init_fields(Inits, Line, Name, Dfs, Vt, St1) end); -expr({record_field,Line,_,_}=M, _Vt, St0) -> - case expand_package(M, St0) of - {error, St1} -> - {[],add_error(Line, illegal_expr, St1)}; - {_, St1} -> - {[], St1} - end; expr({record_field,Line,Rec,Name,Field}, Vt, St0) -> {Rvt,St1} = record_expr(Line, Rec, Vt, St0), {Fvt,St2} = check_record(Line, Name, St1, The input module is of course legacy code and should be updated, but I think a better error message would be nice. Cheers, Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Tue Jun 4 17:49:11 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 4 Jun 2013 17:49:11 +0200 Subject: [erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return . In-Reply-To: <51AA0ED0.8010006@wanadoo.fr> References: <51AA0ED0.8010006@wanadoo.fr> Message-ID: <51AE0C77.3000002@erlang.org> Hi! On 06/01/2013 05:10 PM, PAILLEAU Eric wrote: > Hello, > > while io:rows(), io:nl() and io:columns() in the Erlang shell are > working, I tried the arity /1 of those functions with self() as argument. > All those functions with such argment looks to never return . The parameter has to be an "IO device" (type device() in the doc)? As the documentation states: "Either standard_io, standard_error, a registered name, or a pid handling IO protocols" (which maybe should read "a pid of a process handling the IO protocol", but anyway :)). The IO protocol is described in stdlib users guide, chapter "The Erlang I/O-protocol". You basically send a message to a process that never responds, and as IO-servers are not required to respond within a certain time frame, the io-module will wait indefinitely for an answer from the process. This is not a bug. > Regards > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Regards, /Patrik, OTP From eric.pailleau@REDACTED Tue Jun 4 20:09:30 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 04 Jun 2013 20:09:30 +0200 Subject: [erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return . In-Reply-To: <51AE0C77.3000002@erlang.org> References: <51AA0ED0.8010006@wanadoo.fr> <51AE0C77.3000002@erlang.org> Message-ID: <51AE2D5A.7020408@wanadoo.fr> Hi Patrick, > The parameter has to be an "IO device" (type device() in the doc)? As > the documentation states: "Either standard_io, standard_error, a > registered name, or a pid handling IO protocols" (which maybe should > read "a pid of a process handling the IO protocol", but anyway :)). The > IO protocol is described in stdlib users guide, chapter "The Erlang > I/O-protocol". > > You basically send a message to a process that never responds, and as > IO-servers are not required to respond within a certain time frame, the > io-module will wait indefinitely for an answer from the process. This is > not a bug. I don't totally agree with you, with below arguments : - Is there any way to know that a PID is of type io_device ? - io:xxxx() returns {error,enotsup} - io:xxxx() returns {error,enotsup} (so why self() don't have same error ?) - A function should return, even an error or a timeout. - this could be a serious security breach. (will Erlang ever talk about security ? :>) ...) So, I don't really care if my patch is graduated or not, but for me this is not a normal behaviour for such functions. Regards. From raimo+erlang-bugs@REDACTED Wed Jun 5 10:35:53 2013 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 5 Jun 2013 10:35:53 +0200 Subject: [erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return . In-Reply-To: <51AE2D5A.7020408@wanadoo.fr> References: <51AA0ED0.8010006@wanadoo.fr> <51AE0C77.3000002@erlang.org> <51AE2D5A.7020408@wanadoo.fr> Message-ID: <20130605083553.GB32319@erix.ericsson.se> On Tue, Jun 04, 2013 at 08:09:30PM +0200, PAILLEAU Eric wrote: > Hi Patrick, > > > The parameter has to be an "IO device" (type device() in the doc)? As > > the documentation states: "Either standard_io, standard_error, a > > registered name, or a pid handling IO protocols" (which maybe should > > read "a pid of a process handling the IO protocol", but anyway :)). The > > IO protocol is described in stdlib users guide, chapter "The Erlang > > I/O-protocol". > > > > You basically send a message to a process that never responds, and as > > IO-servers are not required to respond within a certain time frame, the > > io-module will wait indefinitely for an answer from the process. This is > > not a bug. > > I don't totally agree with you, with below arguments : > > - Is there any way to know that a PID is of type io_device ? No. You can write an IO server yourself, with any bugs you like. It is up to the writer of the IO server to ensure it is bug free. > - io:xxxx() returns {error,enotsup} > - io:xxxx() returns {error,enotsup} > (so why self() don't have same error ?) That must be wrong. io:columns(AnyPid) does not return {error,enotsup}. io:columns(AnyAtom) returns {error,enotsup} if there is no pid that registered the name AnyAtom. An atom is not a pid. io:columns(rex) for instance hangs since the process that registered 'rex' does not implement the IO server protocol. > - A function should return, even an error or a timeout. There is no guarantee for that in any programming language. > - this could be a serious security breach. (will Erlang ever talk > about security ? :>) ...) io:columns(AnyRandomPid) can have any random effect. If you start sending random messages to random processes you get random results. Erlang is built on the assumtion that there are no rouge processes and incorrect behaviour is a bug to be fixed. Security has to be implemented towards the outside (not in the node) world. > > So, I don't really care if my patch is graduated or not, but for me > this is not a normal behaviour for such functions. > > Regards. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From eric.pailleau@REDACTED Wed Jun 5 12:46:32 2013 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Wed, 05 Jun 2013 12:46:32 +0200 Subject: [erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return . Message-ID: <34fatwdjf2pkwdovdslwnqbv.1370429192284@email.android.com> hello Raimo, ok I give up. please drop the patch, and let's stay in this satisfying state. best regards. ? Envoy? depuis mon mobile ? Eric Raimo Niskanen a ?crit?: >On Tue, Jun 04, 2013 at 08:09:30PM +0200, PAILLEAU Eric wrote: >> Hi Patrick, >> >> > The parameter has to be an "IO device" (type device() in the doc)? As >> > the documentation states: "Either standard_io, standard_error, a >> > registered name, or a pid handling IO protocols" (which maybe should >> > read "a pid of a process handling the IO protocol", but anyway :)). The >> > IO protocol is described in stdlib users guide, chapter "The Erlang >> > I/O-protocol". >> > >> > You basically send a message to a process that never responds, and as >> > IO-servers are not required to respond within a certain time frame, the >> > io-module will wait indefinitely for an answer from the process. This is >> > not a bug. >> >> I don't totally agree with you, with below arguments : >> >> - Is there any way to know that a PID is of type io_device ? > >No. You can write an IO server yourself, with any bugs you like. >It is up to the writer of the IO server to ensure it is bug free. > >> - io:xxxx() returns {error,enotsup} >> - io:xxxx() returns {error,enotsup} >> (so why self() don't have same error ?) > >That must be wrong. io:columns(AnyPid) does not return {error,enotsup}. >io:columns(AnyAtom) returns {error,enotsup} if there is no pid that >registered the name AnyAtom. An atom is not a pid. > >io:columns(rex) for instance hangs since the process that registered >'rex' does not implement the IO server protocol. > >> - A function should return, even an error or a timeout. > >There is no guarantee for that in any programming language. > >> - this could be a serious security breach. (will Erlang ever talk >> about security ? :>) ...) > >io:columns(AnyRandomPid) can have any random effect. If you start >sending random messages to random processes you get random results. > >Erlang is built on the assumtion that there are no rouge processes and >incorrect behaviour is a bug to be fixed. Security has to be implemented >towards the outside (not in the node) world. > >> >> So, I don't really care if my patch is graduated or not, but for me >> this is not a normal behaviour for such functions. >> >> Regards. >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > >-- > >/ Raimo Niskanen, Erlang/OTP, Ericsson AB >_______________________________________________ >erlang-bugs mailing list >erlang-bugs@REDACTED >http://erlang.org/mailman/listinfo/erlang-bugs From n.oxyde@REDACTED Thu Jun 6 01:47:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Jun 2013 01:47:10 +0200 Subject: [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> Message-ID: Hello, When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old unused variables are not recorded as such: t(X, Y) -> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: t(X, Y) -> #r{a=A=X,b=A=Y}. Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. git fetch https://github.com/nox/otp.git fix-erl_lint-variable-usage https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch Regards, -- Anthony Ramine Le 31 mai 2013 ? 00:46, Anthony Ramine a ?crit : > Hello, > > Smaller test case reproducing the bug, without KeyList2 nor filter/1: > > -8<-- > -module(missing_warning). > > -export([test_missing_warning/2, > test_with_warning1/2, > test_with_warning2/2 > ]). > > -record(data, {aList, bList}). > > test_missing_warning(Data, KeyList) -> %% Data, KeyList never used - no warning. > #data{aList = [Key || Key <- []], > bList = [Key || Key <- []]}. > > test_with_warning1(Data, KeyList) -> %% Data, KeyList never used - get warning. > #data{aList = [Key || Key <- []]}. %% Only one LC in the record. > > test_with_warning2(Data, KeyList) -> %% Data, KeyList never used - get warning. > {data, > [Key || Key <- []], %% Not in a record. > [Key || Key <- []]}. > -->8- > > Regards, > > -- > Anthony Ramine > > Le 29 mai 2013 ? 20:02, a ?crit : > >> >> When a function creates a record and more than one field is bound to the value of a list comprehension the compiler/linter fails to generate warnings for unused variables in that function. I just tested this on R16B and the problem is still there. >> >> I use the following module to test this: >> >> --8<---------------------------------------------------------- >> -module(missing_warning). >> >> -export([test_missing_warning/2, >> test_with_warning1/2, >> test_with_warning2/2 >> ]). >> >> -record(data, {aList, bList}). >> >> test_missing_warning(Data, KeyList) -> %% Data never used - no warning. >> KeyList2 = filter(KeyList), %% KeyList2 never used - no warning. >> #data{aList = [Key || Key <- KeyList], >> bList = [Key || Key <- KeyList]}. >> >> test_with_warning1(Data, KeyList) -> %% Data never used - get warning. >> KeyList2 = filter(KeyList), %% KeyList2 never used - get warning. >> #data{aList = [Key || Key <- KeyList]}. %% Only one LC in the record. >> >> test_with_warning2(Data, KeyList) -> %% Data never used - get warning. >> KeyList2 = filter(KeyList), %% KeyList2 never used - get warning. >> {data, >> [Key || Key <- KeyList], %% Not in a record. >> [Key || Key <- KeyList]}. >> >> filter(L) -> L. >> --8<---------------------------------------------------------- >> >> In all three test functions the variables Data (in the function head) and KeyList2 (in the function body) are unused. >> Compiling the module should produce six warnings but I only get four. >> You get the same result with other "advanced" calls like >> lists:map(fun(Key) -> Key end, KeyList) >> so it's not limited to list comprehensions. >> If the fields are bound to e.g. the variable KeyList directly the warnings work just fine. >> >> /Anders >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From zfsgeek@REDACTED Thu Jun 6 07:33:42 2013 From: zfsgeek@REDACTED (Xu Yifeng) Date: Thu, 06 Jun 2013 13:33:42 +0800 Subject: [erlang-bugs] imprecise computation result Message-ID: <51B01F36.7050404@163.com> Erlang's matchematic is crazy: Erlang R15B03 (erts-5.9.3.1) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.3.1 (abort with ^G) 1> 2.8 * 2800. 7839.999999999999 2> but the result should be 7840. -- Xu Yifeng From cao.xu@REDACTED Thu Jun 6 07:41:02 2013 From: cao.xu@REDACTED (rytong-caoxu) Date: Thu, 6 Jun 2013 13:41:02 +0800 Subject: [erlang-bugs] imprecise computation result In-Reply-To: <51B01F36.7050404@163.com> References: <51B01F36.7050404@163.com> Message-ID: http://floating-point-gui.de ? 2013-6-6???1:33?Xu Yifeng ??? > Erlang's matchematic is crazy: > > Erlang R15B03 (erts-5.9.3.1) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9.3.1 (abort with ^G) > 1> 2.8 * 2800. > 7839.999999999999 > 2> > > > but the result should be 7840. > > -- > Xu Yifeng > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Thu Jun 6 10:44:54 2013 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Thu, 06 Jun 2013 10:44:54 +0200 Subject: [erlang-bugs] imprecise computation result Message-ID: hello, > 28.0e-1 * 2800. 7839.999999999999 but > 28 * 2800 / 10. 7840.0 always tranlate reals into integers and then finally apply division of powers of ten. reals are coded on a fix length of bits while decimals of the reals can be infinite. it is due to computer architectures and all languages, even C, are impacted. regards ? Envoy? depuis mon mobile ? Eric Xu Yifeng a ?crit?: >Erlang's matchematic is crazy: > >Erlang R15B03 (erts-5.9.3.1) [source] [smp:2:2] [async-threads:0] [hipe] >[kernel-poll:false] > >Eshell V5.9.3.1 (abort with ^G) >1> 2.8 * 2800. >7839.999999999999 >2> > > >but the result should be 7840. > >-- >Xu Yifeng > > >_______________________________________________ >erlang-bugs mailing list >erlang-bugs@REDACTED >http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Thu Jun 6 11:03:04 2013 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Thu, 06 Jun 2013 11:03:04 +0200 Subject: [erlang-bugs] imprecise computation result Message-ID: <8q44xhv0p6ccw0whfrjxqi9q.1370509384078@email.android.com> hello again, I forgot : if you needs a 3digits precision at display, simply * 1000 the computation, and then before displaying result, divide by 1000. > 2.845 * 2800. 7966.000000000001 but > 1000 * 2.845 * 2800 / 1000. 7966.0 regards ? Envoy? depuis mon mobile ? Eric Eric Pailleau a ?crit?: >hello, >> 28.0e-1 * 2800. >7839.999999999999 >but >> 28 * 2800 / 10. >7840.0 > >always tranlate reals into integers and then finally apply division of powers of ten. >reals are coded on a fix length of bits while decimals of the reals can be infinite. >it is due to computer architectures and all languages, even C, are impacted. >regards > >? Envoy? depuis mon mobile ? Eric > >Xu Yifeng a ?crit?: > >>Erlang's matchematic is crazy: >> >>Erlang R15B03 (erts-5.9.3.1) [source] [smp:2:2] [async-threads:0] [hipe] >>[kernel-poll:false] >> >>Eshell V5.9.3.1 (abort with ^G) >>1> 2.8 * 2800. >>7839.999999999999 >>2> >> >> >>but the result should be 7840. >> >>-- >>Xu Yifeng >> >> >>_______________________________________________ >>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 ess@REDACTED Thu Jun 6 13:48:30 2013 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Thu, 6 Jun 2013 13:48:30 +0200 Subject: [erlang-bugs] xmerl_scan leaks ets table Message-ID: <51B0770E.7060009@trifork.com> Hi there - When parsing a string, xmerl_scan creates an ets table which it doesn't delete again in the case of exceptions. Demo: Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.1 (abort with ^G) 1> length(ets:all()). 16 2> 2> catch xmerl_scan:string(""). 3900- fatal: expected_element_start_tag {'EXIT', {fatal, {expected_element_start_tag, {file,file_name_unknown}, {line,1}, {col,1}}}} 3> length(ets:all()). 17 (I just re-discovered this bug; I apologize for having neglected to report it earlier, considering that I've noticed it before some years ago.) From a brief inspection at the code, I think the place to ensure table deletion would be to add a "try...after" in scan_document. Alternatively, it could be done in int_string/4 and int_string_decl/4, where the cleanup can mirror the calls to initial_state0()->initial_state() where the ets table is created. 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 bchesneau@REDACTED Thu Jun 6 16:15:26 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Jun 2013 16:15:26 +0200 Subject: [erlang-bugs] decode_packet doesn't ignore empty lines when decoding the request line Message-ID: Erlang version R16B (erts 5.10.1) 4> Test2 = iolist_to_binary([[<<"\r\n">> || _ <- lists:seq(0,10)], Test1]). <<"\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nGET / HTTP/1.1\r\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"...>> 16> erlang:decode_packet(http_bin, Test2, [{packet_size, 4092}]). {ok,{http_error,<<"\r\n">>}, <<"\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nGET / HTTP/1.1\r\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"...>>} According to the spec empty lines before the request lines should be ignored: In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.1 Imo, decode_packet should just ignore them instead of returning an error. In the case a packet_sixe isn't given maybe thenumber of empty lines can also be set ( or just rely on default packet size). - benoit From fredrik@REDACTED Fri Jun 7 09:21:28 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 7 Jun 2013 09:21:28 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> Message-ID: <51B189F8.3060901@erlang.org> On 06/06/2013 01:47 AM, Anthony Ramine wrote: > Hello, > > When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old > unused variables are not recorded as such: > > t(X, Y) -> > #r{a=[ K || K<- Y ],b=[ K || K<- Y ]. > > As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. > > The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: > > t(X, Y) -> > #r{a=A=X,b=A=Y}. > > Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. > > This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. > > git fetch https://github.com/nox/otp.git fix-erl_lint-variable-usage > > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch > > Regards, > Hello, I've fetched your patch and it should be visible in the 'pu' branch shortly. I also assigned it to be reviewed by the responsible team directly. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From ess@REDACTED Fri Jun 7 10:33:12 2013 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 7 Jun 2013 10:33:12 +0200 Subject: [erlang-bugs] xmerl_scan leaks ets table In-Reply-To: References: <51B0770E.7060009@trifork.com> Message-ID: <51B19AC8.9090000@trifork.com> Hi Pascal, You confuse me. I did not "write the code to get this behaviour" - I used "catch" to let the process live on. Which is something I'd typically do if I had one long-lived process which were to parse a lot of XML documents, which makes this bug even worse. I certainly did not write the code such in order to get a leaked table. (Which is to say: yes, in this case I did - in order to demonstrate the bug...) There is no reason to *not* destroy the table, given that its handle is lost. I'm aware that if I didn't handle the exception any place, and let the process die, then I wouldn't have a leak problem. However, - the table is a resource; - the library which creates it is responsible for cleaning it up; - it should do so even in the case of exceptions; - it is *quite common* to catch exceptions, especially in input validation related error handling such as this; - the calling code *cannot* (without very ugly hacks such as using ets:all()) destroy the table on behalf of the library. Regards, Erik On 06-06-2013 14:32, Pascal Chapier wrote: > Hi Erik, > In my opinion, when you do your test you execute the > xmerl_scan:string("") inside a catch from shell, the process which > create the table - the shell - does not die, so, there is no reason to > destroy the ets table, consideringing that you wrote the code to get > this behaviour. > > Best regards, > > Pascal > > > 2013/6/6 Erik S?e S?rensen > > > Hi there - > When parsing a string, xmerl_scan creates an ets table which it > doesn't delete again in the case of exceptions. > > Demo: > > Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.1 (abort with ^G) > 1> length(ets:all()). > 16 > 2> > 2> catch xmerl_scan:string(""). > 3900- fatal: expected_element_start_tag > {'EXIT', > {fatal, > {expected_element_start_tag, > {file,file_name_unknown}, > {line,1}, > {col,1}}}} > 3> length(ets:all()). > 17 > > (I just re-discovered this bug; I apologize for having neglected > to report it earlier, considering that I've noticed it before some > years ago.) > > From a brief inspection at the code, I think the place to ensure > table deletion would be to add a "try...after" in scan_document. > Alternatively, it could be done in int_string/4 and > int_string_decl/4, where the cleanup can mirror the calls to > initial_state0()->initial_state() where the ets table is created. > > 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 > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- 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 pan@REDACTED Fri Jun 7 15:30:32 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 7 Jun 2013 15:30:32 +0200 Subject: [erlang-bugs] xmerl_scan leaks ets table In-Reply-To: <51B0770E.7060009@trifork.com> References: <51B0770E.7060009@trifork.com> Message-ID: <51B1E078.1040901@erlang.org> Hi! Definitely a bug. You should definitely be able to catch an exception here without leaking memory! Could you submit a patch as you suggested, or should i put it in the backlog for "future processing" by us? Cheers, Patrik On 06/06/2013 01:48 PM, Erik S?e S?rensen wrote: > Hi there - > When parsing a string, xmerl_scan creates an ets table which it > doesn't delete again in the case of exceptions. > > Demo: > > Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.1 (abort with ^G) > 1> length(ets:all()). > 16 > 2> > 2> catch xmerl_scan:string(""). > 3900- fatal: expected_element_start_tag > {'EXIT', > {fatal, > {expected_element_start_tag, > {file,file_name_unknown}, > {line,1}, > {col,1}}}} > 3> length(ets:all()). > 17 > > (I just re-discovered this bug; I apologize for having neglected to > report it earlier, considering that I've noticed it before some years > ago.) > > From a brief inspection at the code, I think the place to ensure table > deletion would be to add a "try...after" in scan_document. > Alternatively, it could be done in int_string/4 and int_string_decl/4, > where the cleanup can mirror the calls to > initial_state0()->initial_state() where the ets table is created. > > 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 > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile@REDACTED Fri Jun 14 16:03:05 2013 From: emile@REDACTED (Emile Joubert) Date: Fri, 14 Jun 2013 15:03:05 +0100 Subject: [erlang-bugs] mnesia_tm:commit_participant() error Message-ID: <51BB2299.7080303@rabbitmq.com> This error was observed in RabbitMQ (R16B) in the context of shutting down: =ERROR REPORT==== 14-Jun-2013::11:33:57 === Error in process <0.28456.0> on node 'rabbit@REDACTED' with exit value: {badarg,[{mnesia_tm,commit_participant,6, [{file,"mnesia_tm.erl"},{line,1751}]}]} The error looks relatively harmless, because an exit is underway, but it shouldn't happen. -Emile From jose.valim@REDACTED Sun Jun 16 17:38:51 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sun, 16 Jun 2013 17:38:51 +0200 Subject: [erlang-bugs] Wrong "this clause cannot match because of a previous clause" warning Message-ID: Hello, I have found a bug on the "cannot match clause" warning. Consider this minimal case: -module(foo). -export([bar/0]). bar() -> V = <<"hello">>, case is_binary(V) of false -> good; true -> bad end. When compiled, the code above spews the following warning: $ erlc foo.erl foo.erl:7: Warning: this clause cannot match because *a previous* clause at line 8 always matches In fact, the clause that always match is the following one and not the previous one. One simple fix for this issue is to change the message to: foo.erl:7: Warning: this clause cannot match because *another* clause at line 8 always matches One may attempt a smarter fix by checking if the order of the lines but that would could still generate invalid warnings in case someone decides to inline case into a single line. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Mon Jun 17 11:08:56 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 17 Jun 2013 11:08:56 +0200 Subject: [erlang-bugs] Wrong "this clause cannot match because of a previous clause" warning In-Reply-To: References: Message-ID: On Sun, Jun 16, 2013 at 5:38 PM, Jos? Valim wrote: > Hello, > > I have found a bug on the "cannot match clause" warning. Consider this > minimal case: > > -module(foo). > -export([bar/0]). > > bar() -> > V = <<"hello">>, > case is_binary(V) of > false -> good; > true -> bad > end. > > > When compiled, the code above spews the following warning: > > $ erlc foo.erl > foo.erl:7: Warning: this clause cannot match because *a previous* clause > at line 8 always matches > > > In fact, the clause that always match is the following one and not the > previous one. One simple fix for this issue is to change the message to: > > foo.erl:7: Warning: this clause cannot match because *another* clause at > line 8 always matches > > > > This is tricky and I will have to think about how to best fix the problem. I want to keep the current wording of the warning when it is appropriate, for example for the following code: case E of Var -> ...; a -> ... end. In this case, the use of a variable forces the order in which the clauses are matched. In your example, a more appropriate message would be something like: "this clause cannot match, because the case expression evaluates to a literal, but it is the wrong literal". I am not sure yet how to best produce that message. The reason that it is tricky is that the code is transformed in several internal steps. After one of those steps, the code would look something like this (if it were to be translated back to Erlang source code from Core Erlang code): if is_binary(V) -> bad; true -> good end (That transformation is done because the compiler will generally generate better code for guard expressons.) When that code is further optimized, it will be seen that that the first clause will always match and a warning will be generated for the second clause in the 'if'. It seems that I will have to add some sort of annotation to the transformed code so that the appropriate warning could be produced, or alternately evaluate the case expression before attempting to to move it into the guard. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Jun 17 20:05:39 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 17 Jun 2013 20:05:39 +0200 Subject: [erlang-bugs] Wrong "this clause cannot match because of a previous clause" warning In-Reply-To: References: Message-ID: <29714EE2-1923-4B1B-9949-56F0EB957982@gmail.com> Hello Jos?, hello Bj?rn, We already have two warnings: - "this clause cannot match because a previous clause at line X always matches" - "this clause cannot match because of different types/sizes" The second is triggered for matches like "{_} = {X,Y}". Shouldn't we just use it in that case? Note that diagnostics would help in the clause shadowing case: foo.erl:3:8: Warning: this clause cannot match because a previous clause at line 2 always matches a -> bad ^~~~~~~~ foo:erl:2:8: Note: This clause shadows clause at line 3 Var -> good; ^~~~~~~~~~~ Or something like that. Regards, -- Anthony Ramine Le 17 juin 2013 ? 11:08, Bj?rn Gustavsson a ?crit : > On Sun, Jun 16, 2013 at 5:38 PM, Jos? Valim wrote: > >> Hello, >> >> I have found a bug on the "cannot match clause" warning. Consider this minimal case: >> >> -module(foo). >> -export([bar/0]). >> >> bar() -> >> V = <<"hello">>, >> case is_binary(V) of >> false -> good; >> true -> bad >> end. >> >> When compiled, the code above spews the following warning: >> >> $ erlc foo.erl >> foo.erl:7: Warning: this clause cannot match because a previous clause at line 8 always matches >> >> In fact, the clause that always match is the following one and not the previous one. One simple fix for this issue is to change the message to: >> >> foo.erl:7: Warning: this clause cannot match because another clause at line 8 always matches > > This is tricky and I will have to think about how to best > fix the problem. > > I want to keep the current wording of the warning when it > is appropriate, for example for the following code: > > case E of > Var -> ...; > a -> ... > end. > > In this case, the use of a variable forces the order in > which the clauses are matched. > > In your example, a more appropriate message would be > something like: "this clause cannot match, because the case > expression evaluates to a literal, but it is the wrong literal". > I am not sure yet how to best produce that message. > > The reason that it is tricky is that the code is transformed > in several internal steps. After one of those steps, the > code would look something like this (if it were to be > translated back to Erlang source code from Core Erlang > code): > > if > is_binary(V) -> bad; > true -> good > end > > (That transformation is done because the compiler will > generally generate better code for guard expressons.) > > When that code is further optimized, it will be seen that > that the first clause will always match and a warning will > be generated for the second clause in the 'if'. > > It seems that I will have to add some sort of annotation > to the transformed code so that the appropriate warning > could be produced, or alternately evaluate the case > expression before attempting to to move it into the guard. > > /Bjorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Wed Jun 19 11:47:48 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 19 Jun 2013 11:47:48 +0200 Subject: [erlang-bugs] Strange application shutdown deadlock In-Reply-To: <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> References: <20130524144546.GB14817@ferdair.local> <7E9616D5-BD4E-4F87-9EDA-A3AF2262FE05@gmail.com> Message-ID: 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 watson.timothy@REDACTED Wed Jun 19 12:00:02 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 19 Jun 2013 11:00:02 +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: <71B41CC1-8BCD-4F8A-8CDD-B811C03CD497@gmail.com> No problems - thanks for letting me know Siri! Cheers, Tim On 19 Jun 2013, at 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 bduggan@REDACTED Fri Jun 21 07:57:00 2013 From: bduggan@REDACTED (Bernard Duggan) Date: Fri, 21 Jun 2013 15:57:00 +1000 Subject: [erlang-bugs] Documentation error for mnesia:activity/4 Message-ID: <51C3EB2C.3090606@shoretel.com> Hi list, This isn't strictly a bug per se, not in the code, anyway, but it it will certainly lead to them (take my word for it ;)). The documented list of functions that an AccessMod passed to mnesia:activity/4 needs to implement is incomplete. It appears, at the very least, to need select/5 added to it. A glance through the code suggests to me that all of the following need to be added: foldl/6 foldr/6 select/5,6 select_cont/3 clear_table/4 I discovered this while moving our code to R16 - previously I'd used -extends(mnesia) in our AccessMod, so anything implemented in the mnesia module was automatically provided by my module. However when I removed the -extends and explicitly provided pass-through implementations for the functions I hadn't implemented (based on the list in the docs) I ended up getting an undef crash on a call to my_access_mod:select/5. (For what it's worth, I ended up going back to -extends, using the pmod_pt parse transform). I'm happy to fix the docs myself, I partly just wanted to double check that I'd read the code correctly and that all those functions really are required. Cheers, Bernard ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From stefan.zegenhagen@REDACTED Tue Jun 25 16:29:36 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Tue, 25 Jun 2013 16:29:36 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl Message-ID: <1372170576.4174.42.camel@ax-sze> Dear all, All input routines in lib/kernel/src/group.erl suffer from a denial-of-service vulnerability that can easily be used by an attacker to randomly crash erlang applications, the erlang VM or other system processes on the same computer. The group.erl I/O server offers line-editing functionality (using edlin.erl) for all input. It therefore applies line-editing until a newline character was received and the current input line is finished. Only then the supplied end-of-input detection routines are called, that differ for the get_chars, get_until, get_line, and get_password commands. Any attacker that has access to an input prompt serviced by group.erl can send several megabytes of characters to the input prompt without a newline in between. Thereby he can cause the Erlang VM to A. consume all available memory and eventually have the Linux OOM (Out-Of-Memory) killer randomly kill system processes even other than the Erlang VM B. consume all available CPU power and slow the system down C. cause timeout errors in unrelated Erlang applications by the amount of garbage collection going on D. cause the Erlang VM to crash (was observed on a live system, but a crash dump could not be saved). Currently, it is not possible to circumvent this behaviour (except by re-implementing group.erl in any application using it). This is because all of the end-of-input searching routines are only ever called *AFTER* a complete, newline-terminated line has been read. Therefore, get_until and get_chars won't help. A meaningful solution is to allow users of group.erl to optionally limit the maximum line length it will handle. If this maximum line length is reached, group.erl should report an error response to the I/O request. This would likely be implemented as a new set_opts option (although not a global one affecting all group.erl process instances). This way, the current behaviour would be retained and compatibility problems are not to expect. Please note that group.erl is *NOT EXCLUSIVELY* used by the erlang shell. Erlang's SSH application uses group.erl as I/O server for its SSH server implementation. Several devices may have a specific command line interface (CLI) running on serial ports. Other uses of group.erl are imaginable. 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 mononcqc@REDACTED Tue Jun 25 17:20:58 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 25 Jun 2013 11:20:58 -0400 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <1372170576.4174.42.camel@ax-sze> References: <1372170576.4174.42.camel@ax-sze> Message-ID: <20130625152057.GA4510@ferdair.local> What are the risks of someone being able to gain access to group.erl, where killing the node through OOM because of end of lines is the most practical approach? For the SSH module, the group.erl module is used with custom shells implementations, and I've never seen Erlang code that allowed arbitrary code execution without being ultimately very easy to crash in all kinds of ways. If you can run simple expressions such as sending messages, or can construct binaries, chances are you can kill a node with far more ease than you can by overflowing group.erl. I'm asking this seriously, and not as some kind of snark. I can see the OOM error being the result of honest mistakes, but I can't imagine connecting to a node, seeing a shell, and saying "yes, I will overload it by streaming data" instead of trying any of the following: - halt(0) - init:stop() - c:q() - init ! {stop,stop} - apply(Mod, Fun, ...) from any of the previous options - {init,[0]}:stop() - lists:duplicate(99999999999999999999999999999, hello) - <<0:100000000000000000/binary>>. - << <> || <> <= <<1,2,3>> >> - os:cmd("..."), - all sorts of binary_to_term tricks - and so on Which would take far less effort and far less bandwidth to accomplish. You might also want to cripple systems by using sys:suspend/1-2 on all the processes you can get your hand on, either through using `processes()` or dynamically building pids from binaries. So is there a case where input frequently makes it to group.erl *without* the user having the ability to execute arbitrary code of some sort if it ever succeeds? If not, then I don't think limiting the input will accomplish much. I'm curious about the cases that would use group.erl without wanting to evaluate input. Regards, Fred. On 06/25, Stefan Zegenhagen wrote: > Dear all, > > All input routines in lib/kernel/src/group.erl suffer from a > denial-of-service vulnerability that can easily be used by an attacker > to randomly crash erlang applications, the erlang VM or other system > processes on the same computer. > > The group.erl I/O server offers line-editing functionality (using > edlin.erl) for all input. It therefore applies line-editing until a > newline character was received and the current input line is finished. > Only then the supplied end-of-input detection routines are called, that > differ for the get_chars, get_until, get_line, and get_password > commands. > > Any attacker that has access to an input prompt serviced by group.erl > can send several megabytes of characters to the input prompt without a > newline in between. Thereby he can cause the Erlang VM to > A. consume all available memory and eventually have the Linux OOM > (Out-Of-Memory) killer randomly kill system processes even other > than the Erlang VM > B. consume all available CPU power and slow the system down > C. cause timeout errors in unrelated Erlang applications by the > amount of garbage collection going on > D. cause the Erlang VM to crash (was observed on a live system, but > a crash dump could not be saved). > > Currently, it is not possible to circumvent this behaviour (except by > re-implementing group.erl in any application using it). This is because > all of the end-of-input searching routines are only ever called *AFTER* > a complete, newline-terminated line has been read. Therefore, get_until > and get_chars won't help. > > A meaningful solution is to allow users of group.erl to optionally limit > the maximum line length it will handle. If this maximum line length is > reached, group.erl should report an error response to the I/O request. > This would likely be implemented as a new set_opts option (although not > a global one affecting all group.erl process instances). This way, the > current behaviour would be retained and compatibility problems are not > to expect. > > Please note that group.erl is *NOT EXCLUSIVELY* used by the erlang > shell. Erlang's SSH application uses group.erl as I/O server for its SSH > server implementation. Several devices may have a specific command line > interface (CLI) running on serial ports. Other uses of group.erl are > imaginable. > > > 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. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From matthias@REDACTED Tue Jun 25 22:15:36 2013 From: matthias@REDACTED (Matthias Lang) Date: Tue, 25 Jun 2013 22:15:36 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <1372170576.4174.42.camel@ax-sze> References: <1372170576.4174.42.camel@ax-sze> Message-ID: <20130625201536.GA27971@corelatus.com> Hi, Stefan Zegenhagen wrote: > All input routines in lib/kernel/src/group.erl suffer from a > denial-of-service vulnerability that can easily be used by an attacker Is this a new problem or are you reporting http://erlang.org/pipermail/erlang-patches/2013-June/004138.html one more time? Matt From bosky101@REDACTED Tue Jun 25 14:53:09 2013 From: bosky101@REDACTED (Bhasker Kode) Date: Tue, 25 Jun 2013 18:23:09 +0530 Subject: [erlang-bugs] Un-identifiable SSL issue after upgrading from R 15B-02 to 16A, 16B, 16B-01 ( worked in R15B-03 ) Message-ID: Ping! I'm posting my experience upgrading from an Ubuntu 11.04 image R15B-02 to a more recent release. tl;dr https://gist.github.com/bosky101/5844535 I began with R16B01, R16B, R16A, R15B-03 respectively and was only able to run the expected TLS behaviour in R15-03. I tested them on different instances of the ubuntu 11.04 image. Various OpenSSL made no difference. Here is a module to test the same with accompanying notes https://gist.github.com/bosky101/5844535 It has constants for ?USE_VERIFY_PEER, ?USE_SSL_ACCEPT. You may have to pass ?CERT,?KEY,?CA as well. Considering that under the same circumstances - only R15B-03 worked - I wonder if this is a regression issue. Will be happy to pass ssh access if it helps. ~Bosky | Verbs.im | @bhaskerkode -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.zegenhagen@REDACTED Wed Jun 26 10:47:03 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Wed, 26 Jun 2013 10:47:03 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <20130625152057.GA4510@ferdair.local> References: <1372170576.4174.42.camel@ax-sze> <20130625152057.GA4510@ferdair.local> Message-ID: <1372236330.4174.71.camel@ax-sze> Hi Fred, > I'm asking this seriously, and not as some kind of snark. I can see the > OOM error being the result of honest mistakes, but I can't imagine > connecting to a node, seeing a shell, and saying "yes, I will overload > it by streaming data" instead of trying any of the following: I'm very happy that the discussion has started again and hope for open ears this time. I'm talking about the case where custom shells come into play. We have devices where a custom command line interface (CLI) was implemented to allow authorized customers to configure/control the device. The CLI is available via both, SSH and a serial port. Such a custom CLI is not uncommon in the computer world. Many databases offer a CLI to run SQL queries, Routers offer a CLI to configure networking, ... They all have in common that the user does not get system privileges or a system shell prompt and is restricted to a certain set of self-defined commands. The user that is using our CLI has no access whatever to an erlang shell and is restricted to executing our custom commands allowed by the CLI. He cannot simply execute arbitrary code, he cannot simply type arbitrary commands, he cannot arbitrarily interfere with the system. The user has to authenticate to the device by means of username/password (over the serial port) or whatever method SSH allows. What sounds like a bug to me is that the user is able to crash our system, using our CLI system and *NOT THE ERLANG SHELL*, just by sending megabyte-long lines to the CLI (where a prompt is waiting for input), and we can do nothing against it except reimplementing group.erl. While we could do that for our shell implementation over the serial port easily (we start group.erl in our code), the situation is a little more complicated for SSH. There is no chance to replace group.erl without additionally patching the Erlang SSH application. Two examples: 1.) The user connects a cable to the serial port and is asked to login. He sends megabytes of data, the device crashes reliably. 2.) A user with read-only permissions connects to our device via SSH. He has no permission to reboot the system. By sending tons of characters over SSH he reboots the device reliably. To summarize: * I'm not talking of arbitrary code execution possiblities. * I'm talking of a "hardended", custom CLI implementation. * No regular access to the erlang shell. * Instead of logging on to our CLI, the user just sends megabyte-long lines to the device and it crashes as reliably as the sun rises in the morning. * Various misbehaviours of the software act as precursor to the final crash/reboot, including the ones I already mentioned: system slowdown, OOM killer killing non-erlang services, erlang crash, misbehaving erlang applications unrelated to the CLI. * We cannot simply amend the situation. * The device is unable to fulfil its designated task, the attacker is able to make the device "deny the service". I would call this a bug in group.erl, and the only thing I want to request is an optional method to circumvent the problem (that is not esotheric or academic for us, but a real, practical problem) for the services where this is needed (our CLI). This would most easily be achieved using a new io:setopts() option. How overlong lines are reported back to the application utilizing group.erl is a matter of taste, but it is likely that some kind of error-abort of the io_request should be done to stop further processing of that line. 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 stefan.zegenhagen@REDACTED Wed Jun 26 10:48:24 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Wed, 26 Jun 2013 10:48:24 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <20130625201536.GA27971@corelatus.com> References: <1372170576.4174.42.camel@ax-sze> <20130625201536.GA27971@corelatus.com> Message-ID: <1372236504.4174.73.camel@ax-sze> Dear Matthias, > > All input routines in lib/kernel/src/group.erl suffer from a > > denial-of-service vulnerability that can easily be used by an attacker > > Is this a new problem or are you reporting > > http://erlang.org/pipermail/erlang-patches/2013-June/004138.html > > one more time? Yes, it is. I reposted it because the patch was rejected, but the issue is still unsolved. It is, however, imported for us to get solved. 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 ess@REDACTED Wed Jun 26 11:53:31 2013 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 26 Jun 2013 11:53:31 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <1372236330.4174.71.camel@ax-sze> References: <1372170576.4174.42.camel@ax-sze> <20130625152057.GA4510@ferdair.local> <1372236330.4174.71.camel@ax-sze> Message-ID: <51CABA1B.6000309@trifork.com> +1 for meaningful application of the phrase "crashes reliably" :-) From bgustavsson@REDACTED Wed Jun 26 14:43:24 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Jun 2013 14:43:24 +0200 Subject: [erlang-bugs] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> Message-ID: Thanks! Looks good. I have only two slight comments: If find the first sentence in the commit message confusing: "Local fun references look like plain old variables in the Core Erlang AST and should not be treated as such." I would suggest "but" instead of "and": "Local fun references look like plain old variables in the Core Erlang AST, but should not be treated as such." The test cases tests that the compiler does not crash and that the code can be loaded, but it does not test that the code actually works. I suggest that you rewrite it to something like this: ?MODULE() -> F = fun bar/1, G = lists:last([(fun (X) when F =:= X -> X end)]), F = G(F), ok. bar(X) -> X. /Bjorn On Sat, May 18, 2013 at 6:22 PM, Anthony Ramine wrote: > Hello, > > This patch fixes the bug by forbidding inlining of variables which values > are local fun references outside of application contexts. > > git fetch https://github.com/nox/otp.git fix-fname-inlining > > > https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining > > https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining.patch > > Regards, > > -- > Anthony Ramine > > Le 17 mai 2013 ? 20:06, Anthony Ramine a ?crit : > > > Hello, > > > > Shorter test case, showing the problem comes from the inline itself and > not inline_list_funcs: > > > > -module(test). > > -compile(inline). > > -export([foo/0]). > > > > foo() -> > > F = fun bar/1, > > fun (X) when X =:= F -> X end. > > > > bar(X) -> X. > > > > If you run the core_lint pass, you can see where the problem comes from: > > > > $ erlc +clint test.erl > > test: illegal guard expression in foo/0 > > > > The inliner inlines `when 'erlang':'=:='(X, F)` to `'erlang':'=:='(X, > 'bar'/1)` but local fun references can't appear in guards. > > > > I'll try to make a patch. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 17 mai 2013 ? 10:55, Masatake Daimon a ?crit : > > > >> Hello, > >> > >> Compiling the following module makes the compiler crash. I'm using > >> R16B. > >> > >> ===== test.erl ===== > >> -module(test). > >> -compile(inline). > >> -compile(inline_list_funcs). > >> -export([foo/0]). > >> > >> foo() -> > >> lists:map(fun bar/1, [1]). > >> > >> bar(X) -> X. > >> > >> ===== the crash ==== > >> % erlc test.erl > >> test: function '-foo/0-lists^map/1-0-'/1+15: > >> Internal consistency check failed - please report this bug. > >> Instruction: {move,{x,0},{yy,0}} > >> Error: {invalid_store,{yy,0},term}: > >> > >> > >> Note that the problem disappears with any of these changes: > >> > >> * Commenting out "-compile(inline)." > >> * Commenting out "-compile(inline_list_funcs)." > >> * Changing the definition of foo/0 to: > >> foo() -> > >> lists:map(fun bar/1, []). % [] instead of [1] > >> * Changing the definition of foo/0 to: > >> foo() -> > >> lists:map(fun (A) -> bar(A) end, [1]). > >> > >> 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 > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Jun 26 14:52:23 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 26 Jun 2013 14:52:23 +0200 Subject: [erlang-bugs] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> Message-ID: <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> Will amend. -- Anthony Ramine Le 26 juin 2013 ? 14:43, Bj?rn Gustavsson a ?crit : > Thanks! Looks good. I have only two slight comments: > > If find the first sentence in the commit message confusing: > > "Local fun references look like plain old variables in the Core Erlang > AST and should not be treated as such." > > I would suggest "but" instead of "and": > > "Local fun references look like plain old variables in the Core Erlang > AST, but should not be treated as such." > > The test cases tests that the compiler does not crash and that > the code can be loaded, but it does not test that the code actually > works. I suggest that you rewrite it to something like this: > > ?MODULE() -> > F = fun bar/1, > G = lists:last([(fun (X) when F =:= X -> X end)]), > F = G(F), > ok. > > bar(X) -> > X. > > /Bjorn > > > > On Sat, May 18, 2013 at 6:22 PM, Anthony Ramine wrote: > Hello, > > This patch fixes the bug by forbidding inlining of variables which values are local fun references outside of application contexts. > > git fetch https://github.com/nox/otp.git fix-fname-inlining > > https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining > https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining.patch > > Regards, > > -- > Anthony Ramine > > Le 17 mai 2013 ? 20:06, Anthony Ramine a ?crit : > > > Hello, > > > > Shorter test case, showing the problem comes from the inline itself and not inline_list_funcs: > > > > -module(test). > > -compile(inline). > > -export([foo/0]). > > > > foo() -> > > F = fun bar/1, > > fun (X) when X =:= F -> X end. > > > > bar(X) -> X. > > > > If you run the core_lint pass, you can see where the problem comes from: > > > > $ erlc +clint test.erl > > test: illegal guard expression in foo/0 > > > > The inliner inlines `when 'erlang':'=:='(X, F)` to `'erlang':'=:='(X, 'bar'/1)` but local fun references can't appear in guards. > > > > I'll try to make a patch. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 17 mai 2013 ? 10:55, Masatake Daimon a ?crit : > > > >> Hello, > >> > >> Compiling the following module makes the compiler crash. I'm using > >> R16B. > >> > >> ===== test.erl ===== > >> -module(test). > >> -compile(inline). > >> -compile(inline_list_funcs). > >> -export([foo/0]). > >> > >> foo() -> > >> lists:map(fun bar/1, [1]). > >> > >> bar(X) -> X. > >> > >> ===== the crash ==== > >> % erlc test.erl > >> test: function '-foo/0-lists^map/1-0-'/1+15: > >> Internal consistency check failed - please report this bug. > >> Instruction: {move,{x,0},{yy,0}} > >> Error: {invalid_store,{yy,0},term}: > >> > >> > >> Note that the problem disappears with any of these changes: > >> > >> * Commenting out "-compile(inline)." > >> * Commenting out "-compile(inline_list_funcs)." > >> * Changing the definition of foo/0 to: > >> foo() -> > >> lists:map(fun bar/1, []). % [] instead of [1] > >> * Changing the definition of foo/0 to: > >> foo() -> > >> lists:map(fun (A) -> bar(A) end, [1]). > >> > >> 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 > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From watson.timothy@REDACTED Wed Jun 26 18:01:22 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 26 Jun 2013 17:01:22 +0100 Subject: [erlang-bugs] common_test + test_server_io errors Message-ID: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> I'm seeing some weird errors in my common_test suites since upgrading to R16B01 - I'd like to know if this is a bug or if my code is doing something wrong... ct_util_server got EXIT from <0.227.0>: {noproc, {gen_server,call, [test_server_io, {print,xxxFrom,unexpected_io, [[[["
*** User 2013-06-26 16:47:39.122 ***"], "\n", [91,102,114,97,109,101,119,111, 114,107,93,32,119,97,116,99, 104,100,111,103,58,32,110,111, 32,112,114,111,99,115,32,116, 111,32,107,105,108,108,"\n"]], "\n","
"]]}, infinity]}} That message originated in these lines of code, running in a process started outside of common_test: log(framework, "watchdog: no procs to kill~n", []); which calls another module: log(Scope, Fmt, Args) -> gen_event:sync_notify(systest_event_log, {Scope, Fmt, Args}). which ends up in the following handler (amongst other places): write_log(EvId, _Fd, What, Args) -> ct:log("[" ++ as_string(EvId) ++ "] " ++ as_string(What), Args). So what's up with the "unexpected_io" error here, and *why* has this brought the whole common_test run down? Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From emile@REDACTED Thu Jun 27 16:13:31 2013 From: emile@REDACTED (Emile Joubert) Date: Thu, 27 Jun 2013 15:13:31 +0100 Subject: [erlang-bugs] mnesia_locker unexpected_info message Message-ID: <51CC488B.2050004@rabbitmq.com> The following error was produced on Windows 2008 64bit and R16B 64bit: =ERROR REPORT==== 13-Jun-2013::15:20:54 === ** Generic server <0.190.0> terminating ** Last message in was {mnesia_locker,'rabbit@REDACTED',granted} ** When Server state == 1 ** Reason for termination == ** {unexpected_info,{mnesia_locker,'rabbit@REDACTED',granted}} It is not clear how to reproduce the error. Mnesia reports "inconsistent_database, running_partitioned_network" after this log entry. Please let me know if there is a workaround that will prevent this error or make it less likely. -Emile From ml@REDACTED Thu Jun 27 12:17:08 2013 From: ml@REDACTED (Sergej Pupykin) Date: Thu, 27 Jun 2013 14:17:08 +0400 Subject: [erlang-bugs] ejabberd broken by R16B01 with bad_object_header error Message-ID: <87d2r77t97.wl%sergej.pupykin@dsr-company.com> Hello, R16B01 breaks my ejabberd installation. I found this workaround and it helped me too: http://stackoverflow.com/questions/17031683/random-bad-object-header-mnesia-error R16B-3 package works. I thought about distro specific bug, but there is no difference in build procedure: *** diff between R16B-3 and R16B01-1 pkgbuilds *** 11,12c11,12 < pkgver=R16B01 < pkgrel=1 --- > pkgver=R16B > pkgrel=3 19,20c19,20 < sha256sums=('da388bc07b8ebdd008f5bb6c3d2c280e358bd188b5aac3ea01e3a7436315abc0' < '71972049fbac73457fb6868be18068edce9f2c9fc2aeeab15f019d4217b6a8c2') --- > sha256sums=('f01c2cfe512d3118fd3398a66bdb82bea6ad0f45b464a46a58e452264b7682cd' > 'f7b1baa088d4ecda4a86944d3a782fcbf80c6b9161756bb50fec9e8d129176b9') 35,36d34 < provides=('erlang-nox') < conflicts=('erlang-nox') 64c62 < depends=('unixodbc' 'erlang-nox') --- > depends=('unixodbc' 'erlang') *** *** *** References: how ejabberd package built: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ejabberd how erlang package built: R16B01-1 https://projects.archlinux.org/svntogit/community.git/tree/repos/community-x86_64/PKGBUILD?h=packages/erlang R16B-3 https://projects.archlinux.org/svntogit/community.git/tree/repos/community-x86_64/PKGBUILD?h=packages/erlang&id=738285a9e52f74b3e89bb56dc939781fcde64f43 Error: =ERROR REPORT==== 2013-06-26 16:02:05 === E(<0.742.0>:ejabberd_hooks:335) : {{case_clause, {error, {bad_object_header, "/var/lib/ejabberd/offline_msg.DAT"}}}, [{lists,keysort,2, [{file,"lists.erl"},{line,738}]}, {mod_offline,pop_offline_messages,4, [{file,"mod_offline.erl"},{line,433}]}, {ejabberd_hooks,run_fold1,4, [{file,"ejabberd_hooks.erl"},{line,331}]}, {ejabberd_c2s,resend_offline_messages,1, [{file,"ejabberd_c2s.erl"},{line,2107}]}, {ejabberd_c2s,presence_update,3, [{file,"ejabberd_c2s.erl"},{line,1801}]}, {ejabberd_c2s,session_established2,2, [{file,"ejabberd_c2s.erl"},{line,1097}]}, {p1_fsm,handle_msg,10, [{file,"p1_fsm.erl"},{line,544}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]} From peppe@REDACTED Fri Jun 28 10:57:16 2013 From: peppe@REDACTED (Peter Andersson) Date: Fri, 28 Jun 2013 10:57:16 +0200 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> Message-ID: <51CD4FEC.4070302@erlang.org> Hi Tim, When a process that hasn't inherited the group leader from a test case process (i.e typically one that hasn't been spawned directly or indirectly from a test case) sends a printout to common_test (by means of e.g ct:log), common_test will print the string to the "Unexpected I/O log", which you find a link to from the test overview page. This is done by actually sending the string to a process named test_server_io, which performs the printing. It is passing the message from the common_test logger to test_server_io that fails, because test_server_io has terminated. Now, test_server_io should live for as long as common_test is up and running (well, almost). You should not get that crash report unless ct:log is called after the test run is finished or test_server_io has crashed unexpectedly because of a bug. The latter should not be a silent event - there should be some indication of such a crash during the test run. Is it possible it's the former problem you encounter, or are you sure the tests are still running when the printout happens? This thing smells timing related error to me. There are only two short "windows" during a test run when the common_test logger is alive while test_server_io isn't: During startup and shutdown of the test run. If the ct:log call happens during either window, you could get this error. Is it easy for you to reproduce the error or does it only happen occasionally? We should try to rule out that there's a bug that causes test_server failure. Then, the timing problem I described above is quite easily fixed by making sure common_test prints to stdout if test_server isn't up and running. I'll implement a fix for this right now, in any event. Best regards, Peter Ericsson AB, Erlang/OTP Tim Watson wrote: > I'm seeing some weird errors in my common_test suites since upgrading > to R16B01 - I'd like to know if this is a bug or if my code is doing > something wrong... > > ct_util_server got EXIT from <0.227.0>: {noproc, > {gen_server,call, > [test_server_io, > {print,xxxFrom,unexpected_io, > [[[["
class=\"default\">*** User 2013-06-26 16:47:39.122 ***"], > "\n", > [91,102,114,97,109,101,119,111, > 114,107,93,32,119,97,116,99, > 104,100,111,103,58,32,110,111, > 32,112,114,111,99,115,32,116, > 111,32,107,105,108,108,"\n"]], > "\n","
"]]}, > infinity]}} > > That message originated in these lines of code, running in a process > started outside of common_test: > > log(framework, "watchdog: no procs to kill~n", []); > > which calls another module: > > log(Scope, Fmt, Args) -> > gen_event:sync_notify(systest_event_log, {Scope, Fmt, Args}). > > which ends up in the following handler (amongst other places): > > write_log(EvId, _Fd, What, Args) -> > ct:log("[" ++ as_string(EvId) ++ "] " ++ as_string(What), Args). > > So what's up with the "unexpected_io" error here, and *why* has this > brought the whole common_test run down? > > Thanks, > > Tim > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From matthias@REDACTED Sat Jun 29 23:59:09 2013 From: matthias@REDACTED (Matthias Lang) Date: Sat, 29 Jun 2013 23:59:09 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <1372236330.4174.71.camel@ax-sze> References: <1372170576.4174.42.camel@ax-sze> <20130625152057.GA4510@ferdair.local> <1372236330.4174.71.camel@ax-sze> Message-ID: <20130629215909.GD3827@corelatus.se> Hi, While it sounds like there's a problem in group.erl which should be fixed, my experience is that things aren't quite as bad as: > * We cannot simply amend the situation. On our embedded device, we completely avoid the situation by authenticating users before they get to the CLI implemented in Erlang. We use 'dropbear' as the SSH server and have /etc/passwd use 'to_erl' as the user's shell. The approach for serial ports is similar. Once authenticated, you can reboot our system using the 'reset' command. --- You were also concerned about linux's OOM killer. Finding and stopping all possible ways Erlang can grab unexpected amounts of RAM is difficult, and not just because they're no longer unexpected once you find them. Telling linux to limit the amount Erlang _can_ grab is much easier. You can do that with 'ulimit' or, if starting from something like 'heart' (which you probably should be), setrlimit(). --- Finally, if I start a server like this: # cat ss.erl -module(ss). -export([go/0]). go() -> crypto:start(), ssh:start(), ssh:daemon(9988, [{password, "bla"}, {ip_v6_disabled, true}]). # ulimit -m 12000 # /usr/local/src/otp_src_R15B03/bin/erl Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:2:2] ... 1> ss:go(). {ok,<0.46.0>} can you give me a program which crashes that through overflow, automatically? (You've given a description. I'd like a program so that I can be sure I'm doing exactly what you're doing.) Matt From mrhegarty@REDACTED Sun Jun 30 21:31:38 2013 From: mrhegarty@REDACTED (Matthew Hegarty) Date: Sun, 30 Jun 2013 20:31:38 +0100 Subject: [erlang-bugs] GUI debugger Module view crashes in dual monitor setup Message-ID: To reproduce 1. debugger:start() 2. Move Monitor window to secondary monitor (to LHS in my case) 3. Module / Interpret (choose module) 4. Open Module View window 5. It will crash as soon as there is a mouse move event with: Error in process <0.2844.0> with exit value: {badarith,[{dbg_ui_trace_win,handle_event,2,[{file,"dbg_ui_trace_win.erl"},{line,696}]},{dbg_ui_view,loop,1,[{file,"dbg_ui_view.erl"},{line,77}]}]} line is: dbg_ui_trace_win.erl 696 {coords, {gs:read(Win, x)+LastX-5, gs:read(Win, y)+LastY-5}}; Workaround: Open the module view window before moving it to secondary monitor, and then it won't crash. === Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] Linux Mint 64bit: 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux 1st Monitor: Samsung 22" 1680 x 1050 2nd Monitor: Dell 19" 1290 x 1024 -------------- next part -------------- An HTML attachment was scrubbed... URL: