From fadiala.guiteye@REDACTED Mon Jan 3 16:47:58 2011 From: fadiala.guiteye@REDACTED (GUITEYE Fadiala) Date: Mon, 3 Jan 2011 16:47:58 +0100 Subject: ASN1 compilation error in otp_R14 and not in otp_R11 Message-ID: <4D21EFAE.4070102@myriadgroup.com> Hi all, Does someone have any idea about this asn1 problem ? Previously, we compiled our code with otp_R11B (that was ok). Now, we try to compile with otp_R14 and we have an issue with ASN compiler. You can find below: - outputs with R14 compilator (with error) - outputs with R11B compilator (no error) - ASN file Best Regards, F. ------------------ Result with otp_R14 --------------------------- make -k /usr/erlang/otp_R14B/lib/erlang/bin/erlc +noobj -bber_bin CAP.asn asn1error:23:'CAP':'ExtensionField' {internal_error, {function_clause, [{asn1ct_check,componentrelation_leadingattr, [{state, {module,1,'CAP',[],'IMPLICIT',{exports,all},{imports,[]},undefined,[]}, 'CAP', {typedef,false,23,'ExtensionField', {type,[], {'SEQUENCE',false,false,undefined, [{'ComponentType',24,type, {type,[], {'ObjectClassFieldType', {'Externaltypereference',24,'CAP','EXTENSION'}, {'Externaltypereference',24,'CAP','EXTENSION'}, [{valuefieldreference,id}], undefined}, [{simpletable, {type,[], {'Externaltypereference',24,'CAP','SupportedExtensions'}, [],[],no}}], [],no}, mandatory,undefined,undefined}, {'ComponentType',25,criticality,.................. ------------------ Result with otp_R11B --------------------------- otp_R11 make -k /usr/erlang/otp_R11B-5/lib/erlang/bin/erlc +noobj -bber_bin CAP.asn Erlang ASN.1 version "1.4.5" compiling "/home/CAP.asn" Compiler Options: [ber_bin, report_errors, {cwd,"/home/src"}, {outdir,"/home/src"}, noobj, {i,"."}, {i,"/home/src"}] --{generated,"/home/src/CAP.asn1db"}-- --{generated,"/home/src/CAP.hrl"}-- --{generated,"/home/src/CAP.erl"}-- ok ------------------ ASN CODE ------------------------- CAP {ccitt(0) identified-organization(4) etsi(0) mobileDomain(0) umts-network(1) modules(3) cap-datatypes(52) version3(2)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXTENSION ::= CLASS { &ExtensionType, &criticality CriticalityType DEFAULT ignore, &id Code } WITH SYNTAX { EXTENSION-SYNTAX &ExtensionType CRITICALITY &criticality IDENTIFIED BY &id } ExtensionField ::= SEQUENCE { type EXTENSION.&id ({SupportedExtensions }), criticality CriticalityType DEFAULT ignore, value [1] EXTENSION.&ExtensionType ({SupportedExtensions }{@type}), ...} SupportedExtensions EXTENSION ::= {firstExtension, ...} firstExtension EXTENSION ::= { EXTENSION-SYNTAX NULL CRITICALITY ignore IDENTIFIED BY global : {itu-t(0) identified-organization(4) organisation(0) gsm(1) capextension(2)}} CriticalityType ::= ENUMERATED { ignore (0), abort (1) } Code ::= CHOICE {local INTEGER, global OBJECT IDENTIFIER} END ________________________________ This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message. From erlang@REDACTED Wed Jan 5 15:49:33 2011 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 5 Jan 2011 15:49:33 +0100 Subject: bug Message-ID: -module(ecc_pass1). -record('FUNCTION', { compound_statement %% function body }). -export([start/2]). %% returns #Pass1 or throws an error start(File, ParseTree) -> Fs = [I || I <- ParseTree, is_function(I)]. is_function(X) -> is_record(X, 'FUNCTION'). Compiling this crashes the compiler ~/code/c_compiler/report_this_bug$ erlc ecc_pass1.erl Function: start/2 ./ecc_pass1.erl:none: internal error in kernel_module; crash reason: {function_clause, [{v3_kernel,lit_vars, [{k_call, [11,{file,"./ecc_pass1.erl"}], {k_local, [11,{file,"./ecc_pass1.erl"}], is_function,1}, [{k_var,[11,{file,"./ecc_pass1.erl"}],ker11}], []}]}, {v3_kernel,uguard_expr,3}, {v3_kernel,uguard_expr,3}, {v3_kernel,uguard,2}, {v3_kernel,umatch,3}, {v3_kernel,'-umatch_list/3-anonymous-0-',3}, {v3_kernel,umatch,3}, {v3_kernel,umatch,3}]} ./ecc_pass1.erl:16: Warning: function is_function/1 is unused /Joe From kostis@REDACTED Wed Jan 5 15:55:17 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 05 Jan 2011 16:55:17 +0200 Subject: [erlang-bugs] bug In-Reply-To: References: Message-ID: <4D248655.9060002@cs.ntua.gr> Joe Armstrong wrote: > -module(ecc_pass1). > > > -record('FUNCTION', > { > compound_statement %% function body > }). > > -export([start/2]). > > %% returns #Pass1 or throws an error > > start(File, ParseTree) -> > Fs = [I || I <- ParseTree, is_function(I)]. > > is_function(X) -> is_record(X, 'FUNCTION'). > > > Compiling this crashes the compiler The compiler should of course not crash, but is it a good idea to have a function whose name clashes with the name of a built-in guard? Rename is_function to something else (e.g. my_is_function) and the problem will go away. Kostis From mchris@REDACTED Thu Jan 6 11:26:55 2011 From: mchris@REDACTED (Maria Christakis) Date: Thu, 06 Jan 2011 12:26:55 +0200 Subject: Expand records bug? Message-ID: <4D2598EF.8040208@mail.ntua.gr> Hello, We are currently working on a project that requires that all records are expanded to tuples. So, we have been using the erl_expand_records:module/2 function, but we realized that it does not affect types. For example, for the code shown below: -module(test). -export([foo/0]). -record(myrec, {foo :: integer(), bar :: integer()}). -type mytype() :: #myrec{}. foo() -> bar. the record definition is removed because of the expansion, but the type is not handled/changed, resulting in a compiler error about record myrec being undefined. Is this a bug? Will there be handling of types? Thank you, Maria From ingela@REDACTED Mon Jan 10 16:24:08 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 10 Jan 2011 16:24:08 +0100 Subject: [erlang-bugs] ssl:ssl_accept/1 discrepancy in spec and doc In-Reply-To: <4D1AFE66.60904@cs.ntua.gr> References: <4D1AFE66.60904@cs.ntua.gr> Message-ID: <4D2B2498.9030101@erix.ericsson.se> Hi! Changed the specs to: -spec ssl_accept(#sslsocket{}) -> ok | {error, reason()}. -spec ssl_accept(#sslsocket{} | port(), timeout()| [option()]) -> ok | {ok, #sslsocket{}} | {error, reason()}. -spec ssl_accept(port(), [option()], timeout()) -> {ok, #sslsocket{}} | {error, reason()}. (Not showing the option()-type, here in this mail, it is according to the documentation). I know the functions return value is a bit "schizophrenic" it is due to backwards compatibility reasons. Regards Ingela Erlang/OTP team - Ericsson AB Kostis Sagonas wrote: > ssl's published documentation states: > > ssl_accept(ListenSocket) -> > ssl_accept(ListenSocket, Timeout) -> ok | {error, Reason} > > (see http://www.erlang.org/doc/man/ssl.html#ssl_accept-1) > > while its code has the specs: > > -spec ssl_accept(#sslsocket{}) -> {ok, #sslsocket{}} | {error, reason()}. > -spec ssl_accept(#sslsocket{}, list() | timeout()) -> {ok, > #sslsocket{}} | {error, reason()}. > > One of the two cannot be right. This should be fixed. > > > Moreover, I do not see why the spec just mentions list() for the > options when the documentation explicitly mentions the options of ssl. > > Kostis > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From fauli@REDACTED Wed Jan 12 10:39:10 2011 From: fauli@REDACTED (Christian Faulhammer) Date: Wed, 12 Jan 2011 10:39:10 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <201012141157.28759.kruber@zib.de> References: <201012141157.28759.kruber@zib.de> Message-ID: <20110112103910.5b0d7f5b@gentoo.org> Hi, Nico Kruber : > Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during > package compilation. I tried updating my erlang package (openSUSE > 11.3, x86_64) from R14B to R14B01 and received the following error > (also see the attached build.log.fortsource2 - compressed due to its > file size): This seems to be specific to 64bit arches as people could reproduce the problem with GCC 4.4. PLD Linux offers a fix (so they say, I still need reports from our users) in http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/erlang/erlang-fortify.patch V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kostis@REDACTED Wed Jan 12 10:50:12 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 12 Jan 2011 11:50:12 +0200 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20110112103910.5b0d7f5b@gentoo.org> References: <201012141157.28759.kruber@zib.de> <20110112103910.5b0d7f5b@gentoo.org> Message-ID: <4D2D7954.5030205@cs.ntua.gr> Christian Faulhammer wrote: > Hi, > > Nico Kruber : > >> Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during >> package compilation. I tried updating my erlang package (openSUSE >> 11.3, x86_64) from R14B to R14B01 and received the following error >> (also see the attached build.log.fortsource2 - compressed due to its >> file size): > > This seems to be specific to 64bit arches as people could reproduce > the problem with GCC 4.4. PLD Linux offers a fix (so they say, I still > need reports from our users) in > http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/erlang/erlang-fortify.patch From the patch: -# define FILENAME_COPY(To,From) strcpy(To,From) +# define FILENAME_COPY(To,From) memcpy(To,From,strlen(From)+1) and its comment: up to R14B01; replace strcpy with memcpy because fortify source won't allow to strcpy into too short array it's not at all clear to me why this is a 64-bit specific issue. It seems that this is (more of) a problem of fortify, which needs fixing here, not of Erlang/OTP. Kostis From mikpe@REDACTED Wed Jan 12 11:28:13 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 12 Jan 2011 11:28:13 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <4D2D7954.5030205@cs.ntua.gr> References: <201012141157.28759.kruber@zib.de> <20110112103910.5b0d7f5b@gentoo.org> <4D2D7954.5030205@cs.ntua.gr> Message-ID: <19757.33341.55403.810261@pilspetsen.it.uu.se> Kostis Sagonas writes: > Christian Faulhammer wrote: > > Hi, > > > > Nico Kruber : > > > >> Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during > >> package compilation. I tried updating my erlang package (openSUSE > >> 11.3, x86_64) from R14B to R14B01 and received the following error > >> (also see the attached build.log.fortsource2 - compressed due to its > >> file size): > > > > This seems to be specific to 64bit arches as people could reproduce > > the problem with GCC 4.4. PLD Linux offers a fix (so they say, I still > > need reports from our users) in > > http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/erlang/erlang-fortify.patch > > From the patch: > > -# define FILENAME_COPY(To,From) strcpy(To,From) > +# define FILENAME_COPY(To,From) memcpy(To,From,strlen(From)+1) > > and its comment: > > up to R14B01; replace strcpy with memcpy because fortify source > won't allow to strcpy into too short array > > it's not at all clear to me why this is a 64-bit specific issue. > > It seems that this is (more of) a problem of fortify, which needs fixing > here, not of Erlang/OTP. Indeed, the above patch makes no sense at all. If some target array is too short, then that target array needs to be enlarged, or the copy needs to be truncated or aborted. Using memcpy() instead is not a "fix". It's possible that fortify sees a definition of strcpy() that's broken (say, has an out-of-bounds write), and that that's the problem. But no-one has shown this to be the case. If someone thinks there's a buffer overflow, they need to say _where_ it occurs and under what circumstances it occurs. So far I've only seen "let's silence fortify" type stuff, which based on the patch above I have no confidence at all in. From mikpe@REDACTED Wed Jan 12 15:12:48 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 12 Jan 2011 15:12:48 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <19757.33341.55403.810261@pilspetsen.it.uu.se> References: <201012141157.28759.kruber@zib.de> <20110112103910.5b0d7f5b@gentoo.org> <4D2D7954.5030205@cs.ntua.gr> <19757.33341.55403.810261@pilspetsen.it.uu.se> Message-ID: <19757.46816.846945.581073@pilspetsen.it.uu.se> Mikael Pettersson writes: > If someone thinks there's a buffer overflow, they need to say _where_ > it occurs and under what circumstances it occurs. > > So far I've only seen "let's silence fortify" type stuff, which based > on the patch above I have no confidence at all in. FWIW, I've just managed to reproduce the fortify error, by compiling otp_src_R14B01 with gcc-4.5.2 on CentOS 5 / x86_64. I did not get the fortify error with otp_src_R14B. From mikpe@REDACTED Wed Jan 12 15:56:54 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 12 Jan 2011 15:56:54 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <19757.46816.846945.581073@pilspetsen.it.uu.se> References: <201012141157.28759.kruber@zib.de> <20110112103910.5b0d7f5b@gentoo.org> <4D2D7954.5030205@cs.ntua.gr> <19757.33341.55403.810261@pilspetsen.it.uu.se> <19757.46816.846945.581073@pilspetsen.it.uu.se> Message-ID: <19757.49462.124080.684698@pilspetsen.it.uu.se> Mikael Pettersson writes: > Mikael Pettersson writes: > > If someone thinks there's a buffer overflow, they need to say _where_ > > it occurs and under what circumstances it occurs. > > > > So far I've only seen "let's silence fortify" type stuff, which based > > on the patch above I have no confidence at all in. > > FWIW, I've just managed to reproduce the fortify error, by compiling > otp_src_R14B01 with gcc-4.5.2 on CentOS 5 / x86_64. > > I did not get the fortify error with otp_src_R14B. The problem is that the Erlang VM (efile_drv.c line 3074 for the current bug) fakes variable length arrays via the equivalent of: struct blah { ... ; char n[1]; }; size_t n = sizeof(struct blah) - 1 + strlen(s) + 1; struct blah *p = malloc(n); strcpy(p->n, s); At the strcpy() the length of p->n is known to be 1, so if strlen(s) > 1 the (false positive) out-of-bounds error is generated. I'm surprised that using memcpy() instead "fixes" this; presumably gcc and/or glibc does weaker checks on memcpy()s. Doing variable-length arrays properly one should say 'char n[];', and use offsetof() instead of sizeof() - 1, but that probably requires GNU C or C1x. (The sizeof() - 1 is wrong anyway, because in the real type there's a nested union involved, and there's no guarantee that &n[0] is the last byte of the surrounding struct, so there may be some over-allocation.) /Mikael From kostis@REDACTED Wed Jan 12 16:14:54 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 12 Jan 2011 17:14:54 +0200 Subject: [erlang-bugs] Specs of reltool In-Reply-To: <4CB77F64.7000507@cs.ntua.gr> References: <4CB77F64.7000507@cs.ntua.gr> Message-ID: <4D2DC56E.1080807@cs.ntua.gr> Kostis Sagonas wrote: > A dialyzer user complained that he gets spurious warnings when using > reltool functions. A quick dialyzer run revealed that reltool is full > of erroneous specs which cannot possibly be right. > > For example, dialyzer complains that: > > reltool.erl:178: The specification for reltool:get_target_spec/1 states > that the function might also return > {'ok',[[any()] | {_,_} | {_,_,_} | {_,_,_,_}] | > {'copy_file',[any()]} | {'strip_beam_file',[any()]} | > {'copy_file',[any()],[any()]} | {'create_dir',[any()],[any()]} | > {'write_file',[any()],maybe_improper_list(any(),binary() | [])} | > {'archive',[any()],[any()],[any()]} | > {'create_dir',[any()],[any()],[any()]}} > but the inferred return is > {'error',string()} | {'ok',pid()} > > and indeed: > > get_target_spec(PidOrOptions) > when is_pid(PidOrOptions); is_list(PidOrOptions) -> > eval_server(PidOrOptions, true, > fun(Pid) -> reltool_server:gen_spec(Pid) end). > > where there is a promise that eval_server/3 will return: > > -spec eval_server(server(), boolean(), fun((server_pid()) -> term())) -> > {ok, server_pid()} | {error, reason()}. > > > These two together cannot be right. In fact, it's easy to see that this > function returns whatever the fun in its third argument returns (which > is term() in this case, if one believes the 3rd argument). > > In general, reltool produces many dialyzer warnings of similar kind. > They should be fixed because they are not only wrong, but they affect > users of this application. I was expecting some action from the responsible developer, especially since I've described the issue and its solution, but apparently my mail has been ignored during the last three months. :-( Anyway, since the rebar developers kept bothering me, I've spent some time investigating this and fixed these problems. Some cleanup of the file was also done as a bonus. git fetch git://github.com/kostis/otp.git reltool-spec-fixes Kostis From pan@REDACTED Wed Jan 12 17:32:51 2011 From: pan@REDACTED (pan@REDACTED) Date: Wed, 12 Jan 2011 17:32:51 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) Message-ID: Hi, I've looked into it and found what _FORTIFY_SOURCE does not like. The construct name[1] is as Mikael explained to later dynamically allocate larger arrays, a common "trick" used throughout the VM to allow structures with different sized buffers. C99 allows structures to contain arrays with *no* size last in a struct, but the VM is not written in C99, as Mikael also correctly pointed out. We are however discussing using this C99 feature in future releases as very few people use a gcc or a MSVC++ that is too old to have that feature. GCC i think has all of C99 implemented and so does MSVC++, at least in the latest release. One of the reasons to use [] instead of [1] is the over-allocation Mikael pointed out, which happens regardless of unions as the sizeof() struct returns an aligned size. Anyway, the problem here is that the name field is actually not the last field in the struct, which is plain wrong. It does not actually produce any real buffer overflow, but the member b of the surrounding struct is the one which should be used for the dynamic buffer. This is old code that is really strange, but has worked despite that (b is never accessed when name is used, so it only generates even more over-allocation). It now got exposed as I started to use strcpy on the field when i implemented unicode filenames. Didn't notice the strange name field when i rewrote it though. So - it is in reality no buffer overflow. In fact, given that the last field is used, as the code intended, -D_FORTIFY_SOURCE allows this kind of constructs. It does not complain if the last member of a structure is indexed outside it's bounds and the actually allocated area is large enough. So, any workaround to silence -D_FORTIFY_SOURCE will do the trick, there is no real buffer overflow. I've made the change to use the "b" field for this callback and removed the strange "name" field in the union, which also makes _FORTIFY_SOURCE happy and makes the code in some way more understandable. Changing to the C99 way will be made in the future, when I'm sure it wont cause problems for people with strange/old platforms out there. That change will however touch a lot of structures in the VM as this kind of code is used at several places (for performance reasons). The change that fixes this will be visible at github as soon as out daily builds has accepted it, most probably before the end of the week. Cheers, /Patrik From kostis@REDACTED Thu Jan 13 14:09:27 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 13 Jan 2011 15:09:27 +0200 Subject: [erlang-questions] picky dialyzer In-Reply-To: <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> Message-ID: <4D2EF987.2010706@cs.ntua.gr> Ulf Wiger wrote: > On 13 Jan 2011, at 12:09, Kostis Sagonas wrote: > .... >> mfa() is an alias for {atom(),atom(),byte()}. > > Ahh, as in {Module, Function, Arity}? > > In the System Limits of the Efficiency Guide, it says that you can have > 256 arguments in a function or fun. Since dialyzer is never wrong, I will > assume that the Efficiency Guide is? :) Let's see... %%========================================================= -module(f_256). -export([f/256]). f(_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_) -> ok. %%========================================================== % erlc f_256.erl % ~/HiPE/otp/bin/erl Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> l(f_256). {"Kernel pid terminated",application_controller,"{application_terminated,kernel,shutdown}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_terminated,kernel,shutdown}) Well, what can I say? Dialyzer is never wrong! ;-) I guess the efficiency guide needs some fixing. Also, the compiler should better complain in such cases instead of generating a bogus .beam file. Kostis From wrr@REDACTED Thu Jan 13 16:34:35 2011 From: wrr@REDACTED (Janek Wrobel) Date: Thu, 13 Jan 2011 16:34:35 +0100 Subject: Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. Message-ID: Hi, When trying to setup an Erlang cluster I was getting following error while spawning a function on a remote node: =ERROR REPORT==== 13-Jan-2011::01:00:38 === ** Can not start hello_world:ping,[] on 'node3@REDACTED' ** After some investigation it turned out that nodes did not accept TCP connections, because setting SO_PRIORITY socket option failed. Strace follows: accept(7, {sa_family=AF_INET, sin_port=htons(51602), sin_addr=inet_addr("123.123.123.123")}, [16]) = 10 fcntl(10, F_GETFL) = 0x2 (flags O_RDWR) fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0 getsockopt(7, SOL_TCP, TCP_NODELAY, [29220483580821504], [4]) = 0 getsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [29220483580821504], [4]) = 0 getsockopt(7, SOL_SOCKET, SO_PRIORITY, [29220483580821504], [4]) = 0 getsockopt(7, SOL_IP, IP_TOS, [29220483580821504], [4]) = 0 getsockopt(10, SOL_SOCKET, SO_PRIORITY, [-4294967281], [4]) = 0 getsockopt(10, SOL_IP, IP_TOS, [64424509440], [4]) = 0 setsockopt(10, SOL_IP, IP_TOS, [0], 4) = 0 setsockopt(10, SOL_SOCKET, SO_PRIORITY, [15], 4) = -1 EPERM (Operation not permitted) close(10) To make it working I needed to add '#undef SO_PRIORITY' to erts/emulator/drivers/common/inet_drv.c and recompile. Can errors from setsockopt(..., SO_PRIORITY) be ignored? According to the socket(7) manual, it is normal for a user not to be able to change this option ('Setting a priority outside the range 0 to 6 requires the CAP_NET_ADMIN capability.'). thanks, Jan Wrobel From burbas@REDACTED Thu Jan 13 17:30:26 2011 From: burbas@REDACTED (Niclas Axelsson) Date: Thu, 13 Jan 2011 17:30:26 +0100 Subject: [erlang-bugs] Specs of reltool In-Reply-To: <4D2DC56E.1080807@cs.ntua.gr> References: <4CB77F64.7000507@cs.ntua.gr> <4D2DC56E.1080807@cs.ntua.gr> Message-ID: <4D2F28A2.7050303@erlang.org> On 01/12/2011 04:14 PM, Kostis Sagonas wrote: > I was expecting some action from the responsible developer, especially > since I've described the issue and its solution, but apparently my > mail has been ignored during the last three months. :-( > > Anyway, since the rebar developers kept bothering me, I've spent some > time investigating this and fixed these problems. Some cleanup of the > file was also done as a bonus. > > git fetch git://github.com/kostis/otp.git reltool-spec-fixes > > Kostis Thanks Kostis, Sorry for not responding to your first mail. I will merge your fix into 'pu'. Regards, Niclas Axelsson, Erlang/OTP From bgustavsson@REDACTED Fri Jan 14 15:40:35 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 14 Jan 2011 15:40:35 +0100 Subject: [erlang-questions] picky dialyzer In-Reply-To: <4D2EF987.2010706@cs.ntua.gr> References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> Message-ID: On Thu, Jan 13, 2011 at 2:09 PM, Kostis Sagonas wrote: > Ulf Wiger wrote: >> >> On 13 Jan 2011, at 12:09, Kostis Sagonas wrote: >> .... >>> >>> mfa() is an alias for {atom(),atom(),byte()}. >> >> Ahh, as in {Module, Function, Arity}? >> >> In the System Limits of the Efficiency Guide, it says that you can have >> 256 arguments in a function or fun. Since dialyzer is never wrong, I will >> assume that the Efficiency Guide is? :) > > Let's see... > > %%========================================================= > -module(f_256). > > -export([f/256]). > > f(_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_) > -> ok. > %%========================================================== > > > % erlc f_256.erl > % ~/HiPE/otp/bin/erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> l(f_256). > {"Kernel pid > terminated",application_controller,"{application_terminated,kernel,shutdown}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_terminated,kernel,shutdown}) > Works fine for me: $ erlc f_256.erl $ /ldisk/bjorn/otp/bin/erl Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> l(f_256). {module,f_256} 2> If I try to load a function with 257 arguments, the loader will refuse to load the file: Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> c(f_257). =ERROR REPORT==== 14-Jan-2011::15:34:45 === beam/beam_load.c(2115): Error loading function f_257:f/257: op i_func_info: IaaI: too many arguments: 257 {error,badfile} =ERROR REPORT==== 14-Jan-2011::15:34:45 === Loading of /home/bjorn/test/f_257.beam failed: badfile 2> (Hint: Note that HiPE is not enabled in the emulator I used.) -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ulf.wiger@REDACTED Fri Jan 14 15:56:34 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 14 Jan 2011 15:56:34 +0100 Subject: [erlang-questions] picky dialyzer In-Reply-To: References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> Message-ID: <3B77805E-1772-48C1-816B-FC7887C8209B@erlang-solutions.com> Ouch! What say you, Kostis? Waiting for the comeback from Dialyzer. :) Of course now I'm also curious what leads to such a weird limit as 256 arguments? obviously, 0 args is allowed, so the range 0..256 does at least make my eyebrow twitch a little. Bj?rn? BR, Ulf On 14 Jan 2011, at 15:40, Bj?rn Gustavsson wrote: > On Thu, Jan 13, 2011 at 2:09 PM, Kostis Sagonas wrote: >> Ulf Wiger wrote: >>> >>> On 13 Jan 2011, at 12:09, Kostis Sagonas wrote: >>> .... >>>> >>>> mfa() is an alias for {atom(),atom(),byte()}. >>> >>> Ahh, as in {Module, Function, Arity}? >>> >>> In the System Limits of the Efficiency Guide, it says that you can have >>> 256 arguments in a function or fun. Since dialyzer is never wrong, I will >>> assume that the Efficiency Guide is? :) >> >> Let's see... >> >> %%========================================================= >> -module(f_256). >> >> -export([f/256]). >> >> f(_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_) >> -> ok. >> %%========================================================== >> >> >> % erlc f_256.erl >> % ~/HiPE/otp/bin/erl >> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> l(f_256). >> {"Kernel pid >> terminated",application_controller,"{application_terminated,kernel,shutdown}"} >> >> Crash dump was written to: erl_crash.dump >> Kernel pid terminated (application_controller) >> ({application_terminated,kernel,shutdown}) >> > > Works fine for me: > > $ erlc f_256.erl > $ /ldisk/bjorn/otp/bin/erl > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> l(f_256). > {module,f_256} > 2> > > > If I try to load a function with 257 arguments, the loader will > refuse to load the file: > > Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] > [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> c(f_257). > > =ERROR REPORT==== 14-Jan-2011::15:34:45 === > beam/beam_load.c(2115): Error loading function f_257:f/257: op > i_func_info: IaaI: > too many arguments: 257 > > {error,badfile} > > =ERROR REPORT==== 14-Jan-2011::15:34:45 === > Loading of /home/bjorn/test/f_257.beam failed: badfile > 2> > > > (Hint: Note that HiPE is not enabled in the > emulator I used.) > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From kostis@REDACTED Fri Jan 14 16:22:50 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 14 Jan 2011 17:22:50 +0200 Subject: [erlang-questions] picky dialyzer In-Reply-To: References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> Message-ID: <4D306A4A.5050005@cs.ntua.gr> Bj?rn Gustavsson wrote: > On Thu, Jan 13, 2011 at 2:09 PM, Kostis Sagonas wrote: >> >> % erlc f_256.erl >> % ~/HiPE/otp/bin/erl >> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.3 (abort with ^G) >> 1> l(f_256). >> {"Kernel pid >> terminated",application_controller,"{application_terminated,kernel,shutdown}"} >> >> Crash dump was written to: erl_crash.dump >> Kernel pid terminated (application_controller) >> ({application_terminated,kernel,shutdown}) >> > > Works fine for me: > > ... SNIP > > (Hint: Note that HiPE is not enabled in the emulator I used.) You are right. Apparently, enabling HiPE causes the loader to crash miserably when one tries to load a function with 256 arguments. This is very surprising, because no native code is involved. I can of course investigate and possibly correct this throughout but I am also wondering: is this 0..256 a sane choice? Why on earth one would have such a range? Wasn't Erlang exotic enough without this feature? :-) Have a nice weekend everybody! Kostis PS. I still do not like: erlc f_257.erl Happily succeeding and generating a bogus file. From ulf.wiger@REDACTED Fri Jan 14 16:29:56 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 14 Jan 2011 16:29:56 +0100 Subject: [erlang-questions] picky dialyzer In-Reply-To: References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> <3B77805E-1772-48C1-816B-FC7887C8209B@erlang-solutions.com> Message-ID: <310965E6-F077-4CA1-9A70-3235E0944A86@erlang-solutions.com> Oh, I'm just in it for the action. :) BR, Ulf On 14 Jan 2011, at 16:24, Tony Rogvall wrote: > > On 14 jan 2011, at 15.56, Ulf Wiger wrote: > >> Ouch! What say you, Kostis? Waiting for the comeback from Dialyzer. :) >> >> Of course now I'm also curious what leads to such a weird limit as 256 >> arguments? obviously, 0 args is allowed, so the range 0..256 does at >> least make my eyebrow twitch a little. Bj?rn? >> > > Switch side now, are we ? ;-) > > /Tony > >> BR, >> Ulf >> >> On 14 Jan 2011, at 15:40, Bj?rn Gustavsson wrote: >> >>> On Thu, Jan 13, 2011 at 2:09 PM, Kostis Sagonas wrote: >>>> Ulf Wiger wrote: >>>>> >>>>> On 13 Jan 2011, at 12:09, Kostis Sagonas wrote: >>>>> .... >>>>>> >>>>>> mfa() is an alias for {atom(),atom(),byte()}. >>>>> >>>>> Ahh, as in {Module, Function, Arity}? >>>>> >>>>> In the System Limits of the Efficiency Guide, it says that you can have >>>>> 256 arguments in a function or fun. Since dialyzer is never wrong, I will >>>>> assume that the Efficiency Guide is? :) >>>> >>>> Let's see... >>>> >>>> %%========================================================= >>>> -module(f_256). >>>> >>>> -export([f/256]). >>>> >>>> f(_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_) >>>> -> ok. >>>> %%========================================================== >>>> >>>> >>>> % erlc f_256.erl >>>> % ~/HiPE/otp/bin/erl >>>> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >>>> [hipe] [kernel-poll:false] >>>> >>>> Eshell V5.8.3 (abort with ^G) >>>> 1> l(f_256). >>>> {"Kernel pid >>>> terminated",application_controller,"{application_terminated,kernel,shutdown}"} >>>> >>>> Crash dump was written to: erl_crash.dump >>>> Kernel pid terminated (application_controller) >>>> ({application_terminated,kernel,shutdown}) >>>> >>> >>> Works fine for me: >>> >>> $ erlc f_256.erl >>> $ /ldisk/bjorn/otp/bin/erl >>> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >>> [kernel-poll:false] >>> >>> Eshell V5.8.3 (abort with ^G) >>> 1> l(f_256). >>> {module,f_256} >>> 2> >>> >>> >>> If I try to load a function with 257 arguments, the loader will >>> refuse to load the file: >>> >>> Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] >>> [kernel-poll:false] >>> >>> Eshell V5.8.3 (abort with ^G) >>> 1> c(f_257). >>> >>> =ERROR REPORT==== 14-Jan-2011::15:34:45 === >>> beam/beam_load.c(2115): Error loading function f_257:f/257: op >>> i_func_info: IaaI: >>> too many arguments: 257 >>> >>> {error,badfile} >>> >>> =ERROR REPORT==== 14-Jan-2011::15:34:45 === >>> Loading of /home/bjorn/test/f_257.beam failed: badfile >>> 2> >>> >>> >>> (Hint: Note that HiPE is not enabled in the >>> emulator I used.) >>> >>> -- >>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >> >> Ulf Wiger, CTO, Erlang Solutions, Ltd. >> http://erlang-solutions.com >> >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > > "Have run Make so many times I dunno what's installed anymore" > Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From jonas.boberg@REDACTED Mon Jan 17 14:46:01 2011 From: jonas.boberg@REDACTED (Jonas Boberg) Date: Mon, 17 Jan 2011 13:46:01 +0000 (GMT) Subject: case clause in cpu_sup:get_uint32_measurement In-Reply-To: <192914135.298211295271870983.JavaMail.root@zimbra> Message-ID: <1275523027.298301295271961542.JavaMail.root@zimbra> Hi, Spotted this SASL error report in the logs of a system running with cpu_sup on: =ERROR REPORT==== 13-Jan-2011::15:05:53 === Error in process <0.601.0> on node 'XXXX@REDACTED' with exit value: {{case_clause,{data,4711}},[{cpu_ sup,get_uint32_measurement,2},{cpu_sup,measurement_server_loop,1}]} Looking at the code, seems like 4711 is some magic number used to implement a ping function: https://github.com/erlang/otp/blob/dev/lib/os_mon/src/cpu_sup.erl The error report above was spotted on R13B04 (Linux), but looks like the cpu_sup source hasn't changed since then (only type-specs and comments at the beginning of file). /Jonas From wrr@REDACTED Mon Jan 17 19:33:28 2011 From: wrr@REDACTED (Janek Wrobel) Date: Mon, 17 Jan 2011 19:33:28 +0100 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: References: Message-ID: On Thu, Jan 13, 2011 at 5:22 PM, Patrik Nyblom wrote: > Hi! > > On Thu, 13 Jan 2011, Janek Wrobel wrote: > >> Hi, >> >> When trying to setup an Erlang cluster I was getting following error >> while spawning a function on a remote node: >> >> =ERROR REPORT==== 13-Jan-2011::01:00:38 === >> ** Can not start hello_world:ping,[] on 'node3@REDACTED' ** >> >> After some investigation it turned out that nodes did not accept TCP >> connections, because setting SO_PRIORITY socket option failed. Strace >> follows: > > What kind of node (kernel version, extra options etc) do you have? Sorry for a late reply, but I was trying to investigate what configuration option is responsible for this behavior and how to reproduce it on a standard Linux box. Unfortunately without any success. The problem here is that socket gets created with default priority larger then user running the process can set with setsockopt, so the sequence of getsockopt(SO_PRIORITY, &priority), setsockopt(SO_PRIORITY, priority) fails. I was thinking that maybe some firewall rule increasing TOS of packets directed and coming from a given TCP port, or some traffic shaping rule ('tc' command) can have an effect of changing default priority of sockets associated with the port. It does not seem to be the case. Maybe someone on this list knows if default priority of Linux sockets can be somehow altered? One scenario in which the sequence of getsocopt(), setsockopt() can fail is when socket was created by a different OS process that had CAP_NET_ADMIN capability. Socket descriptor can be then passed to Erlang VM running without CAP_NET_ADMIN, and used in 'listen {fd, Fd}' function, causing similar error. But this is definitely not the case here. > The inet_driver has a workaround for SO_PRIORITY being destroyed by SO_TOS > settings, I think that's where this fails. > >> >> accept(7, {sa_family=AF_INET, sin_port=htons(51602), >> sin_addr=inet_addr("123.123.123.123")}, [16]) = 10 >> fcntl(10, F_GETFL) ? ? ? ? ? ? ? ? ? ? ?= 0x2 (flags O_RDWR) >> fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) ? = 0 >> getsockopt(7, SOL_TCP, TCP_NODELAY, [29220483580821504], [4]) = 0 >> getsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [29220483580821504], [4]) = 0 >> getsockopt(7, SOL_SOCKET, SO_PRIORITY, [29220483580821504], [4]) = 0 >> getsockopt(7, SOL_IP, IP_TOS, [29220483580821504], [4]) = 0 >> getsockopt(10, SOL_SOCKET, SO_PRIORITY, [-4294967281], [4]) = 0 >> getsockopt(10, SOL_IP, IP_TOS, [64424509440], [4]) = 0 >> setsockopt(10, SOL_IP, IP_TOS, [0], 4) ?= 0 >> setsockopt(10, SOL_SOCKET, SO_PRIORITY, [15], 4) = -1 EPERM (Operation >> not permitted) >> close(10) >> >> To make it working I needed to add '#undef SO_PRIORITY' to >> erts/emulator/drivers/common/inet_drv.c and recompile. >> >> Can errors from setsockopt(..., SO_PRIORITY) be ignored? According to >> the socket(7) manual, it is normal for a user not to be able to change >> this option ('Setting a priority outside the range 0 to 6 requires the >> CAP_NET_ADMIN capability.'). > > > I think it would be OK if you checked that you got EPERM in the exact > copy-from-listen-socket-to-result-of-accept code and ignored the result > then. > > I suspect you would have to patch the function setopt_prio_tos_trick in > inet_drv.c like this: > ----------------------------- > diff --combined erts/emulator/drivers/common/inet_drv.c > index 818bc63,818bc63..0000000 > --- a/erts/emulator/drivers/common/inet_drv.c > +++ b/erts/emulator/drivers/common/inet_drv.c > @@@ -5095,6 -5095,6 +5095,9 @@@ static int setopt_prio_tos_tric > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SO_PRIORITY, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (char *) &tmp_ival_prio, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? tmp_arg_sz_prio); > ++ ? ? ? ? ? ? ? ? ? ? ?if (res != 0 && sock_errno() == EPERM) { > ++ ? ? ? ? ? ? ? ? ? ? ? ? ?res = 0; > ++ ? ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ------------------------------- > > Try that and see if it fixes the problem. This fixes the problem. thanks, Janek From serge@REDACTED Tue Jan 18 05:41:57 2011 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 17 Jan 2011 23:41:57 -0500 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: References: Message-ID: <4D351A15.6020309@aleynikov.org> At some point I was having a similar issue with SO_PRIORITY and SO_TOS bug in inet_drv when trying to open a unix domain socket and pass the open file descriptor to gen_tcp, which failed to function properly. After discussing this issue with Per Hedeland he sent me the attached patch that worked well to solve the issue. Perhaps it will also work in your case, and if so, it should be included in distribution. Serge On 1/17/2011 1:33 PM, Janek Wrobel wrote: > On Thu, Jan 13, 2011 at 5:22 PM, Patrik Nyblom wrote: >> Hi! >> >> On Thu, 13 Jan 2011, Janek Wrobel wrote: >> >>> Hi, >>> >>> When trying to setup an Erlang cluster I was getting following error >>> while spawning a function on a remote node: >>> >>> =ERROR REPORT==== 13-Jan-2011::01:00:38 === >>> ** Can not start hello_world:ping,[] on 'node3@REDACTED' ** >>> >>> After some investigation it turned out that nodes did not accept TCP >>> connections, because setting SO_PRIORITY socket option failed. Strace >>> follows: >> >> What kind of node (kernel version, extra options etc) do you have? > > Sorry for a late reply, but I was trying to investigate what > configuration option is responsible for this behavior and how to > reproduce it on a standard Linux box. Unfortunately without any > success. The problem here is that socket gets created with default > priority larger then user running the process can > set with setsockopt, so the sequence of getsockopt(SO_PRIORITY, > &priority), setsockopt(SO_PRIORITY, priority) fails. > > I was thinking that maybe some firewall rule increasing TOS of packets > directed and coming from a given TCP port, or some traffic shaping > rule ('tc' command) can have an effect of changing default priority of > sockets associated with the port. It does not seem to be the case. > Maybe someone on this list knows if default priority of Linux sockets > can be somehow altered? > > One scenario in which the sequence of getsocopt(), setsockopt() can > fail is when socket was created by a different OS process that had > CAP_NET_ADMIN capability. Socket descriptor can be then passed to > Erlang VM running without CAP_NET_ADMIN, and used in 'listen {fd, Fd}' > function, causing similar error. But this is definitely not the case > here. > > >> The inet_driver has a workaround for SO_PRIORITY being destroyed by SO_TOS >> settings, I think that's where this fails. >> >>> >>> accept(7, {sa_family=AF_INET, sin_port=htons(51602), >>> sin_addr=inet_addr("123.123.123.123")}, [16]) = 10 >>> fcntl(10, F_GETFL) = 0x2 (flags O_RDWR) >>> fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0 >>> getsockopt(7, SOL_TCP, TCP_NODELAY, [29220483580821504], [4]) = 0 >>> getsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [29220483580821504], [4]) = 0 >>> getsockopt(7, SOL_SOCKET, SO_PRIORITY, [29220483580821504], [4]) = 0 >>> getsockopt(7, SOL_IP, IP_TOS, [29220483580821504], [4]) = 0 >>> getsockopt(10, SOL_SOCKET, SO_PRIORITY, [-4294967281], [4]) = 0 >>> getsockopt(10, SOL_IP, IP_TOS, [64424509440], [4]) = 0 >>> setsockopt(10, SOL_IP, IP_TOS, [0], 4) = 0 >>> setsockopt(10, SOL_SOCKET, SO_PRIORITY, [15], 4) = -1 EPERM (Operation >>> not permitted) >>> close(10) >>> >>> To make it working I needed to add '#undef SO_PRIORITY' to >>> erts/emulator/drivers/common/inet_drv.c and recompile. >>> >>> Can errors from setsockopt(..., SO_PRIORITY) be ignored? According to >>> the socket(7) manual, it is normal for a user not to be able to change >>> this option ('Setting a priority outside the range 0 to 6 requires the >>> CAP_NET_ADMIN capability.'). >> >> >> I think it would be OK if you checked that you got EPERM in the exact >> copy-from-listen-socket-to-result-of-accept code and ignored the result >> then. >> >> I suspect you would have to patch the function setopt_prio_tos_trick in >> inet_drv.c like this: >> ----------------------------- >> diff --combined erts/emulator/drivers/common/inet_drv.c >> index 818bc63,818bc63..0000000 >> --- a/erts/emulator/drivers/common/inet_drv.c >> +++ b/erts/emulator/drivers/common/inet_drv.c >> @@@ -5095,6 -5095,6 +5095,9 @@@ static int setopt_prio_tos_tric >> SO_PRIORITY, >> (char *)&tmp_ival_prio, >> tmp_arg_sz_prio); >> ++ if (res != 0&& sock_errno() == EPERM) { >> ++ res = 0; >> ++ } >> } >> } >> } >> ------------------------------- >> >> Try that and see if it fixes the problem. > > This fixes the problem. > > thanks, > Janek > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2-otp.inet_drv.R14A.patch URL: From bgustavsson@REDACTED Tue Jan 18 08:36:52 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 18 Jan 2011 08:36:52 +0100 Subject: [erlang-questions] picky dialyzer In-Reply-To: <4D306A4A.5050005@cs.ntua.gr> References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> <4D306A4A.5050005@cs.ntua.gr> Message-ID: 2011/1/14 Kostis Sagonas : > You are right. Apparently, enabling HiPE causes the loader to crash > miserably when one tries to load a function with 256 arguments. > This is very surprising, because no native code is involved. The crash is in hipe_unified_loader. It crashes the code_server process before it has found out that there is no native code to load. > I can of course investigate and possibly correct this throughout but I am > also wondering: is this 0..256 a sane choice? Why on earth one would have > such a range? Wasn't Erlang exotic enough without this feature? :-) The 0..256 range was an arbitrary choice decided long before there was a Dialyzer. Actually, I am willing to change the range to 0..255 in the next release in order to keep the Dialyzer type simple and beautiful. I don't think that there is any code depending on a function having 256 arguments, so that change should be safe. > PS. I still do not like: > > ? ? ? ?erlc f_257.erl > > ? ?Happily succeeding and generating a bogus file. > The loader will refuse to load the file, so it will not crash the emulator. But I'll try to add the check to the compiler in the next release. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kostis@REDACTED Tue Jan 18 13:44:33 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 18 Jan 2011 14:44:33 +0200 Subject: [erlang-bugs] Re: [erlang-questions] picky dialyzer In-Reply-To: References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> <4D306A4A.5050005@cs.ntua.gr> Message-ID: <4D358B31.5010900@cs.ntua.gr> Bj?rn Gustavsson wrote: > 2011/1/14 Kostis Sagonas : > > The crash is in hipe_unified_loader. It crashes the code_server > process before it has found out that there is no native code > to load. > >> I can of course investigate and possibly correct this throughout but I am >> also wondering: is this 0..256 a sane choice? Why on earth one would have >> such a range? Wasn't Erlang exotic enough without this feature? :-) > > The 0..256 range was an arbitrary choice decided long before > there was a Dialyzer. > > Actually, I am willing to change the range to 0..255 in the next > release in order to keep the Dialyzer type simple and beautiful. > I don't think that there is any code depending on a function > having 256 arguments, so that change should be safe. Thanks Bjorn! I also think this is safe and in any case it's a change for the better. Actually, it's not dialyzer which is what's difficult to change here, but more finding out all places in the hipe compiler and loader where there might be implicit assumptions that the function's arity can always be stored in a byte. Kostis From mikpe@REDACTED Tue Jan 18 14:42:48 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 18 Jan 2011 14:42:48 +0100 Subject: [erlang-bugs] Re: [erlang-questions] picky dialyzer In-Reply-To: <4D358B31.5010900@cs.ntua.gr> References: <4D2EDD7F.5040409@cs.ntua.gr> <8548EADD-542F-42E9-9ED3-FC1FE5523BFF@erlang-solutions.com> <4D2EF987.2010706@cs.ntua.gr> <4D306A4A.5050005@cs.ntua.gr> <4D358B31.5010900@cs.ntua.gr> Message-ID: <19765.39128.437716.501328@pilspetsen.it.uu.se> Kostis Sagonas writes: > Bj??rn Gustavsson wrote: > > 2011/1/14 Kostis Sagonas : > > > > The crash is in hipe_unified_loader. It crashes the code_server > > process before it has found out that there is no native code > > to load. > > > >> I can of course investigate and possibly correct this throughout but I am > >> also wondering: is this 0..256 a sane choice? Why on earth one would have > >> such a range? Wasn't Erlang exotic enough without this feature? :-) > > > > The 0..256 range was an arbitrary choice decided long before > > there was a Dialyzer. > > > > Actually, I am willing to change the range to 0..255 in the next > > release in order to keep the Dialyzer type simple and beautiful. > > I don't think that there is any code depending on a function > > having 256 arguments, so that change should be safe. > > Thanks Bjorn! > > I also think this is safe and in any case it's a change for the better. > > Actually, it's not dialyzer which is what's difficult to change here, > but more finding out all places in the hipe compiler and loader where > there might be implicit assumptions that the function's arity can always > be stored in a byte. I distinctly remember that Bj?rn once said that the max arity was 255, though he may have said 256. I always interpreted it as 255, implying that a byte suffices, since 256 seemed like a totally arbitrary limit. The only things I _know_ break if the limit is 256 are: - hipe_{x86,amd64}.c emit "movb $Arity, ..." insns in the native code wrappers for BEAM functions, and hipe_arm.c similarly is limited to an 8-bit immediate for the arity - there are a few type checks on MFAs in the HiPE runtime system that check that the arity doesn't exceed 255 The first breakage is real and I'd hate to have to emit 32-bit immediates there. The other breakage is superficial and can easily be repaired if necessary. If Bj?rn's willing to lower the max arity from 256 to 255 then I'm all for that solution. /Mikael From fauli@REDACTED Tue Jan 18 16:40:01 2011 From: fauli@REDACTED (Christian Faulhammer) Date: Tue, 18 Jan 2011 16:40:01 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: References: Message-ID: <20110118164001.27fa2ce4@gentoo.org> Hi, : > The change that fixes this will be visible at github as soon as out > daily builds has accepted it, most probably before the end of the > week. At least talking about a bad fix made you create a better one. :) The fix from https://github.com/erlang/otp/commit/3b7fd1030711ad56fa45d18dc6e0f1d0beee2399 gets applied in Gentoo land, although this is my last action as maintainer due to work constraints. Dirkjan Ochtman (djc AT gentoo.org) takes over. Bye and thanks for being a really friendly upstream to all Erlang developers. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From pan@REDACTED Tue Jan 18 17:11:46 2011 From: pan@REDACTED (pan@REDACTED) Date: Tue, 18 Jan 2011 17:11:46 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20110118164001.27fa2ce4@gentoo.org> References: <20110118164001.27fa2ce4@gentoo.org> Message-ID: Hi! On Tue, 18 Jan 2011, Christian Faulhammer wrote: > Hi, > > : >> The change that fixes this will be visible at github as soon as out >> daily builds has accepted it, most probably before the end of the >> week. > > At least talking about a bad fix made you create a better one. :) Yes - it tends to do that :) > The fix from https://github.com/erlang/otp/commit/3b7fd1030711ad56fa45d18dc6e0f1d0beee2399 > gets applied in Gentoo land, although this is my last action as > maintainer due to work constraints. Dirkjan Ochtman (djc AT > gentoo.org) takes over. Bye and thanks for being a really friendly > upstream to all Erlang developers. Great that it gets applied! Sorry to hear though that it's your last action as a maintainer. Cheers, /Patrik PS. Welcome Dirkjan! Hope we can make Erlang work great with gentoo! DS. > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > > From pan@REDACTED Tue Jan 18 17:15:09 2011 From: pan@REDACTED (pan@REDACTED) Date: Tue, 18 Jan 2011 17:15:09 +0100 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: <4D351A15.6020309@aleynikov.org> References: <4D351A15.6020309@aleynikov.org> Message-ID: Hi! On Mon, 17 Jan 2011, Serge Aleynikov wrote: > At some point I was having a similar issue with SO_PRIORITY and SO_TOS bug in > inet_drv when trying to open a unix domain socket and pass the open file > descriptor to gen_tcp, which failed to function properly. After discussing > this issue with Per Hedeland he sent me the attached patch that worked well > to solve the issue. Perhaps it will also work in your case, and if so, it > should be included in distribution. Seems Per's patch covers more cases - if this solves the problem, it seems like the best choice to take this one int dev instead of the smaller fix i presented earlier. Janek - have you tried this one? Cheers, /Patrik > > Serge > > On 1/17/2011 1:33 PM, Janek Wrobel wrote: >> On Thu, Jan 13, 2011 at 5:22 PM, Patrik Nyblom >> wrote: >>> Hi! >>> >>> On Thu, 13 Jan 2011, Janek Wrobel wrote: >>> >>>> Hi, >>>> >>>> When trying to setup an Erlang cluster I was getting following error >>>> while spawning a function on a remote node: >>>> >>>> =ERROR REPORT==== 13-Jan-2011::01:00:38 === >>>> ** Can not start hello_world:ping,[] on 'node3@REDACTED' ** >>>> >>>> After some investigation it turned out that nodes did not accept TCP >>>> connections, because setting SO_PRIORITY socket option failed. Strace >>>> follows: >>> >>> What kind of node (kernel version, extra options etc) do you have? >> >> Sorry for a late reply, but I was trying to investigate what >> configuration option is responsible for this behavior and how to >> reproduce it on a standard Linux box. Unfortunately without any >> success. The problem here is that socket gets created with default >> priority larger then user running the process can >> set with setsockopt, so the sequence of getsockopt(SO_PRIORITY, >> &priority), setsockopt(SO_PRIORITY, priority) fails. >> >> I was thinking that maybe some firewall rule increasing TOS of packets >> directed and coming from a given TCP port, or some traffic shaping >> rule ('tc' command) can have an effect of changing default priority of >> sockets associated with the port. It does not seem to be the case. >> Maybe someone on this list knows if default priority of Linux sockets >> can be somehow altered? >> >> One scenario in which the sequence of getsocopt(), setsockopt() can >> fail is when socket was created by a different OS process that had >> CAP_NET_ADMIN capability. Socket descriptor can be then passed to >> Erlang VM running without CAP_NET_ADMIN, and used in 'listen {fd, Fd}' >> function, causing similar error. But this is definitely not the case >> here. >> >> >>> The inet_driver has a workaround for SO_PRIORITY being destroyed by SO_TOS >>> settings, I think that's where this fails. >>> >>>> >>>> accept(7, {sa_family=AF_INET, sin_port=htons(51602), >>>> sin_addr=inet_addr("123.123.123.123")}, [16]) = 10 >>>> fcntl(10, F_GETFL) = 0x2 (flags O_RDWR) >>>> fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0 >>>> getsockopt(7, SOL_TCP, TCP_NODELAY, [29220483580821504], [4]) = 0 >>>> getsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [29220483580821504], [4]) = 0 >>>> getsockopt(7, SOL_SOCKET, SO_PRIORITY, [29220483580821504], [4]) = 0 >>>> getsockopt(7, SOL_IP, IP_TOS, [29220483580821504], [4]) = 0 >>>> getsockopt(10, SOL_SOCKET, SO_PRIORITY, [-4294967281], [4]) = 0 >>>> getsockopt(10, SOL_IP, IP_TOS, [64424509440], [4]) = 0 >>>> setsockopt(10, SOL_IP, IP_TOS, [0], 4) = 0 >>>> setsockopt(10, SOL_SOCKET, SO_PRIORITY, [15], 4) = -1 EPERM (Operation >>>> not permitted) >>>> close(10) >>>> >>>> To make it working I needed to add '#undef SO_PRIORITY' to >>>> erts/emulator/drivers/common/inet_drv.c and recompile. >>>> >>>> Can errors from setsockopt(..., SO_PRIORITY) be ignored? According to >>>> the socket(7) manual, it is normal for a user not to be able to change >>>> this option ('Setting a priority outside the range 0 to 6 requires the >>>> CAP_NET_ADMIN capability.'). >>> >>> >>> I think it would be OK if you checked that you got EPERM in the exact >>> copy-from-listen-socket-to-result-of-accept code and ignored the result >>> then. >>> >>> I suspect you would have to patch the function setopt_prio_tos_trick in >>> inet_drv.c like this: >>> ----------------------------- >>> diff --combined erts/emulator/drivers/common/inet_drv.c >>> index 818bc63,818bc63..0000000 >>> --- a/erts/emulator/drivers/common/inet_drv.c >>> +++ b/erts/emulator/drivers/common/inet_drv.c >>> @@@ -5095,6 -5095,6 +5095,9 @@@ static int setopt_prio_tos_tric >>> SO_PRIORITY, >>> (char *)&tmp_ival_prio, >>> tmp_arg_sz_prio); >>> ++ if (res != 0&& sock_errno() == EPERM) { >>> ++ res = 0; >>> ++ } >>> } >>> } >>> } >>> ------------------------------- >>> >>> Try that and see if it fixes the problem. >> >> This fixes the problem. >> >> thanks, >> Janek >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> > From wrr@REDACTED Wed Jan 19 11:48:59 2011 From: wrr@REDACTED (Janek Wrobel) Date: Wed, 19 Jan 2011 11:48:59 +0100 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: References: <4D351A15.6020309@aleynikov.org> Message-ID: On Tue, Jan 18, 2011 at 5:15 PM, wrote: > On Mon, 17 Jan 2011, Serge Aleynikov wrote: > >> At some point I was having a similar issue with SO_PRIORITY and SO_TOS bug >> in inet_drv when trying to open a unix domain socket and pass the open file >> descriptor to gen_tcp, which failed to function properly. After discussing >> this issue with Per Hedeland he sent me the attached patch that worked well >> to solve the issue. ?Perhaps it will also work in your case, and if so, it >> should be included in distribution. > > Seems Per's patch covers more cases - if this solves the problem, it seems > like the best choice to take this one int dev instead of the smaller fix i > presented earlier. > > Janek - have you tried this one? Yes, I've tried it. It solves a different problem and does not help in my case. The Per's patch makes sure that setsockopt(...,SO_PRIORITY) is not called when SO_PRIORITY is not supported by a socket (getsockopt(..., SO_PRIORITY) fails). In my case SO_PRIORITY is supported (getsockopt(.., SO_PRIORITY succeeds), but it is set to a value that user has no capabilities to set. I've sent an email to netdev@REDACTED, maybe those guys will help to determine if this is a generic problem that can affect other Erlang users: http://www.spinics.net/lists/netdev/msg153009.html Cheers, Janek From pan@REDACTED Mon Jan 24 15:16:50 2011 From: pan@REDACTED (pan@REDACTED) Date: Mon, 24 Jan 2011 15:16:50 +0100 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: References: <4D351A15.6020309@aleynikov.org> Message-ID: Hi, On Wed, 19 Jan 2011, Janek Wrobel wrote: > On Tue, Jan 18, 2011 at 5:15 PM, wrote: >> On Mon, 17 Jan 2011, Serge Aleynikov wrote: >> >>> At some point I was having a similar issue with SO_PRIORITY and SO_TOS bug >>> in inet_drv when trying to open a unix domain socket and pass the open file >>> descriptor to gen_tcp, which failed to function properly. After discussing >>> this issue with Per Hedeland he sent me the attached patch that worked well >>> to solve the issue. ?Perhaps it will also work in your case, and if so, it >>> should be included in distribution. >> >> Seems Per's patch covers more cases - if this solves the problem, it seems >> like the best choice to take this one int dev instead of the smaller fix i >> presented earlier. >> >> Janek - have you tried this one? > > Yes, I've tried it. It solves a different problem and does not help in > my case. The Per's patch makes sure that setsockopt(...,SO_PRIORITY) > is not called when SO_PRIORITY is not supported by a socket > (getsockopt(..., SO_PRIORITY) fails). > > In my case SO_PRIORITY is supported (getsockopt(.., SO_PRIORITY > succeeds), but it is set to a value that user has no capabilities to > set. Oh, right. I should have looked more closely at the patch. Seems like both things can happen though. I think i'll do a patch that fixes both problems while at it. It might take a few days though, I have some personal matters of illness to attend to... Hope you'll be okay with the simple patch I made earlier for now! > > I've sent an email to netdev@REDACTED, maybe those guys will > help to determine if this is a generic problem that can affect other > Erlang users: http://www.spinics.net/lists/netdev/msg153009.html > It would be interesting to hear the reason for this strange SO_PRIORITY behaviour, although i think we could safely implement the workaround anyway, after all, the whole resetting of SO_PRIORITY is a workaround to start with... > Cheers, > Janek > Cheers, /Patrik From wrr@REDACTED Tue Jan 25 10:09:10 2011 From: wrr@REDACTED (Janek Wrobel) Date: Tue, 25 Jan 2011 10:09:10 +0100 Subject: [erlang-bugs] Erlang nodes fail to communicate if user has no capability to change SO_PRIORITY socket options. In-Reply-To: References: <4D351A15.6020309@aleynikov.org> Message-ID: Hi, On Mon, Jan 24, 2011 at 3:16 PM, wrote: > > On Wed, 19 Jan 2011, Janek Wrobel wrote: > >> On Tue, Jan 18, 2011 at 5:15 PM, ? wrote: >>> >>> On Mon, 17 Jan 2011, Serge Aleynikov wrote: >>> >>>> At some point I was having a similar issue with SO_PRIORITY and SO_TOS >>>> bug >>>> in inet_drv when trying to open a unix domain socket and pass the open >>>> file >>>> descriptor to gen_tcp, which failed to function properly. After >>>> discussing >>>> this issue with Per Hedeland he sent me the attached patch that worked >>>> well >>>> to solve the issue. ?Perhaps it will also work in your case, and if so, >>>> it >>>> should be included in distribution. >>> >>> Seems Per's patch covers more cases - if this solves the problem, it >>> seems >>> like the best choice to take this one int dev instead of the smaller fix >>> i >>> presented earlier. >>> >>> Janek - have you tried this one? >> >> Yes, I've tried it. It solves a different problem and does not help in >> my case. The Per's patch makes sure that setsockopt(...,SO_PRIORITY) >> is not called when SO_PRIORITY is not supported by a socket >> (getsockopt(..., SO_PRIORITY) fails). >> >> In my case SO_PRIORITY is supported (getsockopt(.., SO_PRIORITY >> succeeds), but it is set to a value that user has no capabilities to >> set. > > Oh, right. I should have looked more closely at the patch. Seems like both > things can happen though. I think i'll do a patch that fixes both problems > while at it. This sounds great! > It might take a few days though, I have some personal matters of illness to > attend to... Hope you'll be okay with the simple patch I made earlier for > now! Sure, the patch is working fine for me. In the long term it will be just much more convenient to have it included in the distribution. This is the only thing that did not work out of the box in my setup. Thanks Patrik for your help! Cheers, Janek From alex.demidenko@REDACTED Fri Jan 28 08:07:39 2011 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Fri, 28 Jan 2011 13:07:39 +0600 Subject: [bug] syntax_tool-1.6.5, injury data in erl_syntax_lib:map() In-Reply-To: References: Message-ID: Hi! I have fix for old bug. Please confirm. I believe that the behavior of the functions map() and fold() must be coordinated. Otherwise it leads to errors when processing ast-tree by parse_transform. Test on Erlang R13B04 (erts-5.7.5) and Erlang R13B01 (erts-5.7.2) erl_syntax.diff 2264,2267c2264,2267 < {nil, _} -> < none; % no interesting information is lost < _ -> < Tail --- > %% {nil, _} -> > %% none; % no interesting information is lost > _ -> > Tail On Tue, Jun 29, 2010 at 7:27 PM, Alexander Demidenko < alex.demidenko@REDACTED> wrote: > Hi, > > Try to show on a synthetic example: > > I have some source data: > 1> X = {function,34,handle_event,2, [{clause,34, > [{var,34,'_'},{var,34,'_'}],[], [{cons,35,{tuple,35,[]},{nil,36}}]}]}. > {function,34,handle_event,2, > [{clause,34, > [{var,34,'_'},{var,34,'_'}], > [], > [{cons,35,{tuple,35,[]},{nil,36}}]}]} > > Now, I will try to traverse the data via erl_syntax_lib:map() > > 2> erl_syntax_lib:map(fun (El) -> io:format("~p~n", > [erl_syntax:revert(El)]), El end, X). > {atom,34,handle_event} > {var,34,'_'} > {var,34,'_'} > {tuple,35,[]} > {cons,35,{tuple,35,[]},{nil,35}} > > {clause,34,[{var,34,'_'},{var,34,'_'}],[],[{cons,35,{tuple,35,[]},{nil,35}}]} > {function,34,handle_event,2, > [{clause,34, > [{var,34,'_'},{var,34,'_'}], > [], > [{cons,35,{tuple,35,[]},{nil,35}}]}]} > {tree,function, > {attr,34,[],none}, > {function,{tree,atom,{attr,34,[],none},handle_event}, > [{tree,clause, > {attr,34,[],none}, > {clause,[{var,34,'_'},{var,34,'_'}], > none, > [{tree,list, > {attr,35,[],none}, > {list,[{tuple,35,[]}],none}}]}}]}} > > > Ops, erl_syntax_lib vodoo magic, make unexpected change original > {nil,36} to {nil,35} > To test, make control measurements via erl_syntax_lib:fold() > > 3> erl_syntax_lib:fold(fun (El, Acc) -> io:format("~p~n", [El]) end, [], > X). > {tree,atom,{attr,34,[],none},handle_event} > {var,34,'_'} > {var,34,'_'} > {tuple,35,[]} > {cons,35,{tuple,35,[]},{nil,36}} > > {clause,34,[{var,34,'_'},{var,34,'_'}],[],[{cons,35,{tuple,35,[]},{nil,36}}]} > {function,34,handle_event,2, > [{clause,34, > [{var,34,'_'},{var,34,'_'}], > [], > [{cons,35,{tuple,35,[]},{nil,36}}]}]} > ok > > Unlike map(), fold() working correctly. > > > PS Test on Erlang R13B04 (erts-5.7.5) and Erlang R13B01 (erts-5.7.2) > with same results > > -- > --------------------------------------------- > With best regards, > Alexander. > -- --------------------------------------------- With best regards, Alexander. From mmzeeman@REDACTED Fri Jan 28 15:34:04 2011 From: mmzeeman@REDACTED (Maas-Maarten Zeeman) Date: Fri, 28 Jan 2011 15:34:04 +0100 Subject: inets http cookie parsing bug Message-ID: <00866D02-599F-4BCC-A8D1-D3852137C481@xs4all.nl> Hello, Yesterday I discovered a cookie parsing bug in inets http client. 1> inets:start(). ok 2> http:set_options([{cookies, enabled}]). ok 3> http:request("http://zotonic.com"). {error,{function_clause,[{string,substr, [" 01 Jul 2012 11:48:43 GMT",1,-1]}, {httpc_cookie,parse_set_cookie,3}, {lists,map,2}, {httpc_cookie,parse_set_cookies,2}, {httpc_cookie,cookies,3}, {httpc_handler,handle_cookies,4}, {httpc_handler,handle_response,1}, {httpc_handler,handle_info,2}]}} ... ... When it parses a cookie header like this: Set-Cookie: z_sid=r5tOZ6GQlWtb68XEoo4m; Version=1; Path=/; HttpOnly, z_pid=49Rr3y6VeuMs407m2KUM; Version=1; Expires=Sun, 01 Jul 2012 11:59:21 GMT; Max-Age=44928000; Path=/; HttpOnly This cookie header is split in the wrong location. During parsing this string is first split on the "," character. But when a cookie contains an expires attribute with a date string, that split will be in the wrong location, because the date format contains a comma. The bug appears in all R13 and R14 releases. Kind regards, Maas-Maarten Zeeman From mmzeeman@REDACTED Sat Jan 29 23:40:25 2011 From: mmzeeman@REDACTED (Maas-Maarten Zeeman) Date: Sat, 29 Jan 2011 23:40:25 +0100 Subject: inets http cookie parsing bug Message-ID: <09CB51DC-3529-4967-A515-A2B71AF38325@xs4all.nl> The bug seems to be fixed in R14B02. Kind regards, Maas From pguyot@REDACTED Mon Jan 31 10:41:39 2011 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 31 Jan 2011 10:41:39 +0100 Subject: HiPE bug with comparison of floats with integers Message-ID: Hello, There is a bug in HiPE compilation with the comparison of floats with integers. This bug happens with the following two functions: ------ -module(hipe_zero). -export([f/1, g/2]). f(X) -> Y = X / 2, Y == 0. g(X, Z) -> Y = X / 2, case Z of test when Y == 0 -> test_zero; test -> test_non_zero; other -> other end. ------ Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE properly evaluates hipe_zero:f/1 to true if passed {icode_inline_bifs, false}. However, not inlining the '==' bif just masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) to test_zero. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From mikpe@REDACTED Mon Jan 31 11:20:43 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 31 Jan 2011 11:20:43 +0100 Subject: [erlang-bugs] HiPE bug with comparison of floats with integers In-Reply-To: References: Message-ID: <19782.36091.255157.371261@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > There is a bug in HiPE compilation with the comparison of floats with integers. > This bug happens with the following two functions: > > ------ > -module(hipe_zero). > -export([f/1, g/2]). > > f(X) -> > Y = X / 2, > Y == 0. > > g(X, Z) -> > Y = X / 2, > case Z of > test when Y == 0 -> test_zero; > test -> test_non_zero; > other -> other > end. > ------ > > Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE properly evaluates hipe_zero:f/1 to true if passed {icode_inline_bifs, false}. However, not inlining the '==' bif just masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) to test_zero. Platform? If it's 32-bit x86, please also try 64-bit x86 (and vice-versa). From pguyot@REDACTED Mon Jan 31 11:31:26 2011 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 31 Jan 2011 11:31:26 +0100 Subject: [erlang-bugs] HiPE bug with comparison of floats with integers In-Reply-To: <19782.36091.255157.371261@pilspetsen.it.uu.se> References: <19782.36091.255157.371261@pilspetsen.it.uu.se> Message-ID: Le 31 janv. 2011 ? 11:20, Mikael Pettersson a ?crit : > Paul Guyot writes: >> Hello, >> >> There is a bug in HiPE compilation with the comparison of floats with integers. >> This bug happens with the following two functions: >> >> ------ >> -module(hipe_zero). >> -export([f/1, g/2]). >> >> f(X) -> >> Y = X / 2, >> Y == 0. >> >> g(X, Z) -> >> Y = X / 2, >> case Z of >> test when Y == 0 -> test_zero; >> test -> test_non_zero; >> other -> other >> end. >> ------ >> >> Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE properly evaluates hipe_zero:f/1 to true if passed {icode_inline_bifs, false}. However, not inlining the '==' bif just masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) to test_zero. > > Platform? If it's 32-bit x86, please also try 64-bit x86 (and vice-versa). Mikael, Thank you for your quick reply. Indeed, I should have mentioned the platform: the bug can be observed on 64-bit x86 (MacOS X and FreeBSD). Regards, Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From kostis@REDACTED Mon Jan 31 13:45:57 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 31 Jan 2011 14:45:57 +0200 Subject: [erlang-bugs] HiPE bug with comparison of floats with integers In-Reply-To: References: <19782.36091.255157.371261@pilspetsen.it.uu.se> Message-ID: <4D46AF05.5080805@cs.ntua.gr> Paul Guyot wrote: > Le 31 janv. 2011 ? 11:20, Mikael Pettersson a ?crit : > >> Paul Guyot writes: >>> Hello, >>> >>> There is a bug in HiPE compilation with the comparison of floats with integers. >>> This bug happens with the following two functions: >>> >>> ------ >>> -module(hipe_zero). >>> -export([f/1, g/2]). >>> >>> f(X) -> >>> Y = X / 2, >>> Y == 0. >>> >>> g(X, Z) -> >>> Y = X / 2, >>> case Z of >>> test when Y == 0 -> test_zero; >>> test -> test_non_zero; >>> other -> other >>> end. >>> ------ >>> >>> Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE properly evaluates hipe_zero:f/1 to true if passed {icode_inline_bifs, false}. However, not inlining the '==' bif just masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) to test_zero. >> Platform? If it's 32-bit x86, please also try 64-bit x86 (and vice-versa). > > Mikael, > > Thank you for your quick reply. Indeed, I should have mentioned the platform: the bug can be observed on 64-bit x86 (MacOS X and FreeBSD). Actually, I think this information was/is irrelevant. This is a generic bug and happens in all platforms I've tried. Once again, the culprit seems to be the type analysis on Icode :-( If one compiles with the [no_icode_type] option, the behavior one gets is that of BEAM: 12> c(hipe_zero). {ok,hipe_zero} 13> hipe_zero:f(0). true 14> hipe_zero:f(0.0). true 15> hipe:c(hipe_zero). {ok,hipe_zero} 16> hipe_zero:f(0). false 17> hipe_zero:f(0.0). false 18> hipe:c(hipe_zero, [no_icode_type]). {ok,hipe_zero} 19> hipe_zero:f(0). true 20> hipe_zero:f(0.0). true I will try to put it on my TODO list, but it has already overflowed. Kostis