From nicolas.charpentier@REDACTED Fri Apr 1 08:35:21 2011 From: nicolas.charpentier@REDACTED (Nicolas Charpentier) Date: Fri, 1 Apr 2011 07:35:21 +0100 Subject: [erlang-bugs] ETS ordered_set not ordered with OTP R14-B02 64 bits Message-ID: <252919C6-5274-4631-80B2-1DFBE2A36D2F@erlang-solutions.com> Hi, Testing our application with R14-B02, we noticed some strange behaviour with the timers. Sometimes, timer:send_interval/3 wasn't sending the message to the process. After some investigations, it seems that in some circumstances, on an ordered_set ets:first/1 doesn't give the lowest key. The minimal use case is isolated in the script bug.esh. The bug can be reproduce on: - Ubuntu 64bits and Red-Hat 64 bits (OTP compiled without any particular option ) - MacOS 64 BIts (64 bits compilation forced with ./configure --enable-darwin-64bit) The bug can't be reproduce on: - MacOs 32 bits - Ubuntu 32 bits Thanks to "git bisect" the bug seems to be introduced by the commit fff4ba0282e42e2942acebff9c10a274075c1c62 $ git start $ git bisect good OTP_R14B01 $ git bisect bad OTP_R14B02 $ git bisect run Regards, Nicolas Charpentier -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.esh Type: application/octet-stream Size: 520 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: bisect_ets_bug.sh Type: application/octet-stream Size: 65 bytes Desc: not available URL: From pan@REDACTED Fri Apr 1 11:04:26 2011 From: pan@REDACTED (pan@REDACTED) Date: Fri, 1 Apr 2011 11:04:26 +0200 Subject: [erlang-bugs] Re: ETS ordered_set not ordered with OTP R14-B02 64 bits In-Reply-To: <252919C6-5274-4631-80B2-1DFBE2A36D2F@erlang-solutions.com> References: <252919C6-5274-4631-80B2-1DFBE2A36D2F@erlang-solutions.com> Message-ID: Hi! Thank you for the awesome error report! The bug is confirmed (of course) and it looks like a truncated integer in the comparision. The attached patch should fix it. Please verify the patch and I'll add it (together with your testcase) to dev. Cheers, /Patrik On Fri, 1 Apr 2011, Nicolas Charpentier wrote: > Hi, > > Testing our application with R14-B02, we noticed some strange behaviour with the timers. > Sometimes, timer:send_interval/3 wasn't sending the message to the process. > > After some investigations, it seems that in some circumstances, on an ordered_set ets:first/1 doesn't give the lowest key. > > The minimal use case is isolated in the script bug.esh. > > The bug can be reproduce on: > - Ubuntu 64bits and Red-Hat 64 bits (OTP compiled without any particular option ) > - MacOS 64 BIts (64 bits compilation forced with ./configure --enable-darwin-64bit) > > The bug can't be reproduce on: > - MacOs 32 bits > - Ubuntu 32 bits > > > Thanks to "git bisect" the bug seems to be introduced by the commit fff4ba0282e42e2942acebff9c10a274075c1c62 > > $ git start > $ git bisect good OTP_R14B01 > $ git bisect bad OTP_R14B02 > $ git bisect run > > > > Regards, > Nicolas Charpentier > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ets_ordered_set_key_cmp.diff Type: text/x-patch Size: 548 bytes Desc: Correction for ordered_set comparision bug. URL: From hans.bolinder@REDACTED Mon Apr 4 13:32:54 2011 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 4 Apr 2011 13:32:54 +0200 Subject: [erlang-bugs] Re: [erlang-bugs 3] Bug in -spec/@doc ordering in new edoc In-Reply-To: <20110324173513.GK20461@hijacked.us> References: <20110324173513.GK20461@hijacked.us> Message-ID: <19865.44134.1755.305909@ornendil.otp.ericsson.se> Hi, [Andrew Thompson:] > Hi, I just noticed an odd behaviour where the order in which a @doc and > a -spec appear affects whether the @doc appears in the edoc output. If I > put the -spec first, the only documentation for that function is the > spec, if I put the @doc first, they both show up. This bug has been reported several times, and finally a fix has been merged into 'dev' (R14B03 to be): https://github.com/erlang/otp/commit/efd032654990280daee58463b3208ef843008a2a Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From ingela@REDACTED Mon Apr 4 14:30:36 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 4 Apr 2011 14:30:36 +0200 Subject: [erlang-bugs] Re: [erlang-bugs 8] Re: possible supervisor bug in r14b02 In-Reply-To: References: <4D9045DB.5060509@erix.ericsson.se> Message-ID: <4D99B9EC.2000702@erix.ericsson.se> Hi! We found that your patch was not complete and also a little buggy. Normally we require a test case for patches, but as this was a latent bug that was triggered by our latest change we decided to write a test case our selfs. We think the solution should look like follows and it will be included in dev shortly. (Diff is based on your patch) index b511545..368dc2e 100644 @@ -344,8 +344,12 @@ handle_call({delete_child, Name}, _From, State) -> handle_call({terminate_child, Name}, _From, State) -> case get_child(Name, State) of {value, Child} -> - NChild = do_terminate(Child, State#state.name), - {reply, ok, replace_child(NChild, State)}; + case do_terminate(Child, State#state.name) of + #child{restart_type = temporary} = NChild -> + {reply, ok, state_del_child(NChild, State)}; + NChild -> + {reply, ok, replace_child(NChild, State)} + end; _ -> {reply, {error, not_found}, State} end; @@ -818,11 +822,11 @@ state_del_child(Child, State) -> State#state{children = NChildren}. del_child(Name, [Ch|Chs]) when Ch#child.name =:= Name, Ch#child.restart_type =:= temporary -> - [Chs]; + Chs; del_child(Name, [Ch|Chs]) when Ch#child.name =:= Name -> [Ch#child{pid = undefined} | Chs]; del_child(Pid, [Ch|Chs]) when Ch#child.pid =:= Pid, Ch#child.restart_type =:= temporary -> - [Chs]; + Chs; del_child(Pid, [Ch|Chs]) when Ch#child.pid =:= Pid -> [Ch#child{pid = undefined} | Chs]; del_child(Name, [Ch|Chs]) -> Regards Ingela Erlang/OTP team - Ericsson AB Filipe David Manana wrote: > Thanks :) > > On Mon, Mar 28, 2011 at 9:24 AM, Ingela Anderton Andin > wrote: > >> Hi! >> >> We will take a look at your patch it sounds like it is the right thing to >> do. >> Temporary processes should not be restarted so you should not have >> to save their init-arguments, although until the last release they where >> saved >> so it was possible to restart them! Especially for simple_one_for_one >> supervisors >> that may have lots of temporary processes memory consumption can >> go sky high if you save them. >> >> Regards Ingela Erlang OTP team - Ericsson AB >> >> Filipe David Manana wrote: >> >>> Hi, >>> >>> In R14B02 I noticed that for a child with a "temporary" restart_type, >>> we discard its A component of the MFA tuple when adding the childspec >>> to the list of the supervisor's children [1]. >>> >>> When the child terminates, its spec is never removed from the list of >>> the supervisor's children specs. >>> Then if we call supervisor:restart_child/2 after the child terminates, >>> the handle_call clause for restart_child gets the childspec with an >>> MFA that is {M, F, undefined} [2]. At that point do_start_child will >>> call apply(M, F, undefined) [3] which will cause the supervisor to >>> reply with an error, instead of returning {ok, Pid} as in previous >>> releases. An example for the returned error: >>> >>> {error,{'EXIT',{badarg,[{erlang,apply,[gen_server,start_link,undefined]}, >>> {supervisor,do_start_child,2}, >>> {supervisor,handle_call,3}, >>> {gen_server,handle_msg,5}, >>> {proc_lib,init_p_do_apply,3}]}}} >>> >>> The patch at [4] fixes the issue for me. The particular code that is >>> no longer working in R14B02 but worked on all previous releases, is >>> from Apache CouchDB, see [5] >>> >>> This issue was introuced by OTP-9064 (reading from the R14B02 release >>> notes). >>> Was this intended behaviour? It doesn't make much sense for me to keep >>> a temporary childspec in the supervisor once the child terminates, so >>> I believe deleting it from the state is the right thing to do. >>> >>> [1] - >>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L787 >>> [2] - >>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L314 >>> [3] - >>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L246 >>> [4] - >>> https://github.com/fdmanana/otp/commit/2697042aa9ebab2fcd208c93b7f454b25bc580d4 >>> [5] - >>> https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_replicator.erl#L119 >>> >>> >>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > > > From fdmanana@REDACTED Mon Apr 4 15:39:46 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Mon, 4 Apr 2011 14:39:46 +0100 Subject: [erlang-bugs] Re: [erlang-bugs 8] Re: possible supervisor bug in r14b02 In-Reply-To: <4D99B9EC.2000702@erix.ericsson.se> References: <4D9045DB.5060509@erix.ericsson.se> <4D99B9EC.2000702@erix.ericsson.se> Message-ID: Oh, yes, I definitely made a mistake by putting the rest of the children list inside another list. Copy-paste curse :) Looks fine to me. Thanks Ingela. On Mon, Apr 4, 2011 at 1:30 PM, Ingela Anderton Andin wrote: > Hi! > > We found that your patch was not complete and also a little buggy. > Normally we require a test case for patches, but as this was a > latent bug that was triggered by our latest change we > decided to write a test case our selfs. > > We think the solution should look like follows and it > will be included in dev shortly. ?(Diff is based on your patch) > > index b511545..368dc2e 100644 > @@ -344,8 +344,12 @@ handle_call({delete_child, Name}, _From, State) -> > handle_call({terminate_child, Name}, _From, State) -> > ? ?case get_child(Name, State) of > ? ?{value, Child} -> > - ? ? ? ?NChild = do_terminate(Child, State#state.name), > - ? ? ? ?{reply, ok, replace_child(NChild, State)}; > + ? ? ? ?case do_terminate(Child, State#state.name) of > + ? ? ? ?#child{restart_type = temporary} = NChild -> > + ? ? ? ? ? ?{reply, ok, state_del_child(NChild, State)}; > + ? ? ? ?NChild -> > + ? ? ? ? ? ?{reply, ok, replace_child(NChild, State)} > + ? ? ? ?end; > ? ?_ -> > ? ? ? ?{reply, {error, not_found}, State} > ? ?end; > @@ -818,11 +822,11 @@ state_del_child(Child, State) -> > ? ?State#state{children = NChildren}. > > del_child(Name, [Ch|Chs]) when Ch#child.name =:= Name, Ch#child.restart_type > =:= temporary -> > - ? ?[Chs]; > + ? ?Chs; > del_child(Name, [Ch|Chs]) when Ch#child.name =:= Name -> > ? ?[Ch#child{pid = undefined} | Chs]; > del_child(Pid, [Ch|Chs]) when Ch#child.pid =:= Pid, Ch#child.restart_type > =:= temporary -> > - ? ?[Chs]; > + ? ?Chs; > del_child(Pid, [Ch|Chs]) when Ch#child.pid =:= Pid -> > ? ?[Ch#child{pid = undefined} | Chs]; > del_child(Name, [Ch|Chs]) -> > > Regards Ingela Erlang/OTP team - Ericsson AB > > Filipe David Manana wrote: >> >> Thanks :) >> >> On Mon, Mar 28, 2011 at 9:24 AM, Ingela Anderton Andin >> wrote: >> >>> >>> Hi! >>> >>> We will take a look at your patch it sounds like it is the right thing to >>> do. >>> Temporary processes should not be restarted so you should not have >>> to save their ?init-arguments, although until the last release they where >>> saved >>> so it was possible to restart them! Especially for simple_one_for_one >>> supervisors >>> that may have lots of temporary processes memory consumption can >>> go sky high if you save them. >>> >>> Regards ?Ingela Erlang OTP team - Ericsson AB >>> >>> Filipe David Manana wrote: >>> >>>> >>>> Hi, >>>> >>>> In R14B02 I noticed that for a child with a "temporary" restart_type, >>>> we discard its A component of the MFA tuple when adding the childspec >>>> to the list of the supervisor's children [1]. >>>> >>>> When the child terminates, its spec is never removed from the list of >>>> the supervisor's children specs. >>>> Then if we call supervisor:restart_child/2 after the child terminates, >>>> the handle_call clause for restart_child gets the childspec with an >>>> MFA ?that is {M, F, undefined} [2]. At that point do_start_child will >>>> call apply(M, F, undefined) [3] which will cause the supervisor to >>>> reply with an error, instead of returning {ok, Pid} as in previous >>>> releases. An example for the returned error: >>>> >>>> >>>> ?{error,{'EXIT',{badarg,[{erlang,apply,[gen_server,start_link,undefined]}, >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? {supervisor,do_start_child,2}, >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? {supervisor,handle_call,3}, >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? {gen_server,handle_msg,5}, >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3}]}}} >>>> >>>> The patch at [4] fixes the issue for me. The particular code that is >>>> no longer working in R14B02 but worked on all previous releases, is >>>> from Apache CouchDB, see [5] >>>> >>>> This issue was introuced by OTP-9064 (reading from the R14B02 release >>>> notes). >>>> Was this intended behaviour? It doesn't make much sense for me to keep >>>> a temporary childspec in the supervisor once the child terminates, so >>>> I believe deleting it from the state is the right thing to do. >>>> >>>> [1] - >>>> >>>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L787 >>>> [2] - >>>> >>>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L314 >>>> [3] - >>>> >>>> https://github.com/erlang/otp/blob/dev/lib/stdlib/src/supervisor.erl#L246 >>>> [4] - >>>> >>>> https://github.com/fdmanana/otp/commit/2697042aa9ebab2fcd208c93b7f454b25bc580d4 >>>> [5] - >>>> >>>> https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_replicator.erl#L119 >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From per.melin@REDACTED Mon Apr 4 20:35:41 2011 From: per.melin@REDACTED (Per Melin) Date: Mon, 4 Apr 2011 20:35:41 +0200 Subject: [erlang-bugs] Crash in VTS (Common Test) Message-ID: =ERROR REPORT==== 4-Apr-2011::20:22:11 === Error in process <0.58.0> on node 'ct@REDACTED' with exit value: {badarg,[{erlang,integer_to_list,[unknown]},{vts,result_summary_body,1},{vts,result_summary_frame1,1},{vts,loop,1}]} Minimal test case: -module(vts_crash_SUITE). -include_lib("common_test/include/ct.hrl"). -export([all/0, groups/0]). -export([noop/1]). all() -> [{group, main}]. groups() -> [{main, [{repeat, 2}], [noop]}]. % {repeat, 1} does not crash noop(_Config) -> ok. From peppe@REDACTED Tue Apr 5 09:20:32 2011 From: peppe@REDACTED (Peter Andersson) Date: Tue, 5 Apr 2011 09:20:32 +0200 Subject: [erlang-bugs] Re: Crash in VTS (Common Test) In-Reply-To: References: Message-ID: Hi Per, How did you start your test (with which parameters)? /Peter On Mon, 4 Apr 2011, Per Melin wrote: > =ERROR REPORT==== 4-Apr-2011::20:22:11 === > Error in process <0.58.0> on node 'ct@REDACTED' with exit value: > {badarg,[{erlang,integer_to_list,[unknown]},{vts,result_summary_body,1},{vts,result_summary_frame1,1},{vts,loop,1}]} > > > Minimal test case: > > -module(vts_crash_SUITE). > > -include_lib("common_test/include/ct.hrl"). > > -export([all/0, groups/0]). > -export([noop/1]). > > all() -> > [{group, main}]. > > groups() -> > [{main, [{repeat, 2}], [noop]}]. > % {repeat, 1} does not crash > > noop(_Config) -> > ok. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From per.melin@REDACTED Tue Apr 5 09:35:57 2011 From: per.melin@REDACTED (Per Melin) Date: Tue, 5 Apr 2011 09:35:57 +0200 Subject: [erlang-bugs] Re: Crash in VTS (Common Test) In-Reply-To: References: Message-ID: On Tue, Apr 5, 2011 at 9:20 AM, Peter Andersson wrote: > > Hi Per, > > How did you start your test (with which parameters)? Put the test case in an otherwise empty directory. ct_run -vts -suite $(pwd)/vts_crash_SUITE -browser open Click Run. Click Run Test. (The "open" parameter for -browser will open the default browser on OS X.) From peppe@REDACTED Tue Apr 5 10:06:56 2011 From: peppe@REDACTED (Peter Andersson) Date: Tue, 5 Apr 2011 10:06:56 +0200 Subject: [erlang-bugs] Re: Crash in VTS (Common Test) In-Reply-To: References: Message-ID: Thanks for reporting! I'll have a look at this and get back to you. /Peter On Tue, 5 Apr 2011, Per Melin wrote: > On Tue, Apr 5, 2011 at 9:20 AM, Peter Andersson wrote: >> >> Hi Per, >> >> How did you start your test (with which parameters)? > > Put the test case in an otherwise empty directory. > > ct_run -vts -suite $(pwd)/vts_crash_SUITE -browser open > > Click Run. > Click Run Test. > > (The "open" parameter for -browser will open the default browser on OS X.) > From Benjamin.Winkler@REDACTED Thu Apr 7 09:53:05 2011 From: Benjamin.Winkler@REDACTED (Benjamin Winkler) Date: Thu, 07 Apr 2011 09:53:05 +0200 Subject: [erlang-bugs] erl_interface and threads Message-ID: <4D9D6D61.4040907@specs.com> Hi! We are using Erlang and specifically the erl_interface for C (Visual Studio C++ 2008, Windows 7) to connect to our Erlang servers. We have noticed weird errors when creating (and freeing) terms in different threads. It seems to me that the memory allocation module is not thread-aware. I have managed to isolate the problem and written an exemplary program (see end of mail) where several threads create and free erlang terms (tuples "{hello,world}"). The terms are continously checked for correctness by assertions (assert(type != ERL_UNDEF)). Note, that the terms are local in regard to the thread. When running a single thread, everything is just fine. No memory leaks, no exceptions, no assertions. However, when I use multiple threads something goes wrong (usually just several milliseconds after starting) and I get completely unpredictable results: - sometimes an atom that I have just created in the preceding line is suddenly a tuple (assertion fails) - sometimes a tuple references itself as a child, thus creating a recursion and a stack overflow when checking its children - sometimes the type of a term becomes ERL_UNDEF - etc. I have tried this with the precompiled binaries for version R12B05 and with the most recent version R14B02. (In the latter case I had to link with "ei_md.lib" and "erl_interface_md.lib", since I don't have the corresponding VS2005-Debug-Runtime-DLLs) Am I missing something obvious? Is this problem known or worked upon or is there any fix? I have searched the documentation and the web but I only found vague references to a compiler flag _REENTRANT, which would fix some pthreads concurrency issues. But judging from the Makefile I am using Win32-Threads (also I would like to get around having to build erl_interface with cygwin). Any help would be greatly appreciated, since this is a real show-stopper. Thanks in advance, Benni Here is the source code: #include #include #include #include #include #include // // select the number of threads that simultaneously allocate and // deallocate erlang terms: // const int numberOfThreads = 3; volatile bool abortThread = false; // // check whether the term is valid; recurse if we have a tuple // void checkTerm(const ETERM* p) { if (p) { int type = ERL_TYPE(p); assert( (type != ERL_UNDEF) && "invalid erlang term!" ); if (ERL_IS_TUPLE(p)) { for (int i = 0; i < ERL_TUPLE_SIZE(p); ++i) checkTerm( ERL_TUPLE_ELEMENT(p, i) ); } } } // // free the term; recurse if we have a tuple // (I could have used erl_free_compound() instead) // void deleteTerm(ETERM* p) { if (p) { if (ERL_IS_TUPLE(p)) { for (int i = 0; i < ERL_TUPLE_SIZE(p); ++i) deleteTerm( ERL_TUPLE_ELEMENT(p, i) ); } erl_free_term(p); } } // // the thread routine: // // holds 64 erlang terms (locally!), which are initially NULL. // in every iteration: // - one of the terms is replaced by a tuple {hello, world} // - every created tuple is checked for validity // - all 64 tuples are checked for validity as well // void threadRoutine() { // hold 64 erlang elements std::vector terms(64, (ETERM*)0); while (!abortThread) { // check all terms for (std::size_t i = 0; i < terms.size(); ++i) checkTerm( terms[i] ); // pick random term int idx = rand() % (int)(terms.size()); // create atom ETERM* a = erl_mk_atom("hello"); checkTerm( a ); // create atom ETERM* b = erl_mk_atom("world"); checkTerm( b ); // create tuple {hello, world} ETERM* hw[2]; hw[0] = a; hw[1] = b; ETERM* tuple = erl_mk_tuple(hw, 2); checkTerm( tuple ); // replace current term with this tuple deleteTerm( terms[idx] ); terms[idx] = tuple; } // release all terms for (std::size_t i = 0; i < terms.size(); ++i) deleteTerm( terms[i] ); } typedef boost::shared_ptr< boost::thread > thread_ptr; // // main routine: // start the threads, wait for , stop the threads // int main(int argc, char* argv[]) { // init erl_init(NULL, 0); srand( (unsigned)time(NULL) ); // start threads std::vector< thread_ptr > threads; for (int i = 0; i < numberOfThreads; ++i) threads.push_back( thread_ptr( new boost::thread(&threadRoutine) ) ); // wait std::cout << "Press Return to stop" << std::endl; std::string str; std::getline(std::cin, str); // wait for threads abortThread = true; for (std::size_t i = 0; i < threads.size(); ++i) threads[i]->join(); } -- Benjamin Winkler Software Engineer SPECS Surface Nano Analysis GmbH Voltastrasse 5 13355 Berlin Germany Tel.: +49 30 46 78 24-92 47 Fax: +49 30 46 42 083 Email: Benjamin.Winkler@REDACTED Web: www.specs.com SPECS Surface Nano Analysis GmbH Innovation in Surface Spectroscopy and Microscopy Systems CEO: Reinhard Lembke Registered Office: Berlin Companies Commercial Register No.: 93 HRB 21390 Register Court: Charlottenburg This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From michael.santos@REDACTED Thu Apr 7 19:08:37 2011 From: michael.santos@REDACTED (Michael Santos) Date: Thu, 7 Apr 2011 13:08:37 -0400 Subject: [erlang-bugs] Re: erl_interface and threads In-Reply-To: <4D9D6D61.4040907@specs.com> References: <4D9D6D61.4040907@specs.com> Message-ID: <20110407170837.GA29038@ecn.lan> On Thu, Apr 07, 2011 at 09:53:05AM +0200, Benjamin Winkler wrote: > Hi! > > We are using Erlang and specifically the erl_interface for C (Visual > Studio C++ 2008, Windows 7) to connect to our Erlang servers. We have > noticed weird errors when creating (and freeing) terms in different > threads. It seems to me that the memory allocation module is not > thread-aware. This isn't helpful with solving your problem with erl_interface but have you looked at the newer ei interface? It lets you manage the memory yourself (or allocates memory for you if you use the ei_x_* functions). The documentation is here: http://www.erlang.org/doc/man/ei.html From andrew@REDACTED Thu Apr 7 20:15:20 2011 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 7 Apr 2011 14:15:20 -0400 Subject: [erlang-bugs] Re: erl_interface and threads In-Reply-To: <20110407170837.GA29038@ecn.lan> References: <4D9D6D61.4040907@specs.com> <20110407170837.GA29038@ecn.lan> Message-ID: <20110407181520.GK24843@hijacked.us> On Thu, Apr 07, 2011 at 01:08:37PM -0400, Michael Santos wrote: > On Thu, Apr 07, 2011 at 09:53:05AM +0200, Benjamin Winkler wrote: > > Hi! > > > > We are using Erlang and specifically the erl_interface for C (Visual > > Studio C++ 2008, Windows 7) to connect to our Erlang servers. We have > > noticed weird errors when creating (and freeing) terms in different > > threads. It seems to me that the memory allocation module is not > > thread-aware. > > This isn't helpful with solving your problem with erl_interface but > have you looked at the newer ei interface? It lets you manage the memory > yourself (or allocates memory for you if you use the ei_x_* functions). > I'm pretty sure that the whole point of ei is to be a thread-safe replacement for erl_interface. Andrew From eric.pailleau@REDACTED Thu Apr 7 22:32:57 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 07 Apr 2011 22:32:57 +0200 Subject: [erlang-bugs] Re: Missing init:get_args() function ? In-Reply-To: <4D94DBD7.2000306@wanadoo.fr> References: <4D94DBD7.2000306@wanadoo.fr> Message-ID: <4D9E1F79.2070006@wanadoo.fr> Hello, no answer to this ? Should init:get_args/0 not any more used ? Regards. Le 31/03/2011 21:53, PAILLEAU Eric a ?crit : > $> erl -sname titi -config toto > > Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> init:get_args(). > ** exception error: undefined function init:get_args/0 > > while > > 2> init:get_plain_arguments(). > [] > > Looks like init:get_args() does not exists while still in last > documentation. > > Did I miss something in doc, or is it a bug ? > > Regards. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From bengt.kleberg@REDACTED Fri Apr 8 06:59:59 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 8 Apr 2011 06:59:59 +0200 Subject: [erlang-bugs] Re: Missing init:get_args() function ? In-Reply-To: <4D9E1F79.2070006@wanadoo.fr> References: <4D94DBD7.2000306@wanadoo.fr> <4D9E1F79.2070006@wanadoo.fr> Message-ID: <1302238799.5058.1.camel@seasc1137> Greetings, init:get_args/0 is in the documentation, without restrictions. Therefore this is a bug. Either in the code or the documentation. ebngt On Thu, 2011-04-07 at 22:32 +0200, PAILLEAU Eric wrote: > Hello, > > no answer to this ? > > Should init:get_args/0 not any more used ? > > Regards. > > Le 31/03/2011 21:53, PAILLEAU Eric a ?crit : > > $> erl -sname titi -config toto > > > > Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] > > [hipe] [kernel-poll:false] > > > > Eshell V5.8.3 (abort with ^G) > > 1> init:get_args(). > > ** exception error: undefined function init:get_args/0 > > > > while > > > > 2> init:get_plain_arguments(). > > [] > > > > Looks like init:get_args() does not exists while still in last > > documentation. > > > > Did I miss something in doc, or is it a bug ? > > > > 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 From pan@REDACTED Fri Apr 8 11:42:28 2011 From: pan@REDACTED (pan@REDACTED) Date: Fri, 8 Apr 2011 11:42:28 +0200 Subject: [erlang-bugs] Missing init:get_args() function ? In-Reply-To: <1302238799.5058.1.camel@seasc1137> References: <4D94DBD7.2000306@wanadoo.fr> <4D9E1F79.2070006@wanadoo.fr> <1302238799.5058.1.camel@seasc1137> Message-ID: Hi! init:get_args got deprecated in R9C (!) and was removed in R12. Why it wasn't removed from documentation is a mystery yet unsolved... So - confirmed documentation bug, it will be corrected in the next release. Thank's for reporting! Cheers, /Patrik On Fri, 8 Apr 2011, Bengt Kleberg wrote: > Greetings, > > init:get_args/0 is in the documentation, without restrictions. Therefore > this is a bug. Either in the code or the documentation. > > > ebngt > > On Thu, 2011-04-07 at 22:32 +0200, PAILLEAU Eric wrote: >> Hello, >> >> no answer to this ? >> >> Should init:get_args/0 not any more used ? >> >> Regards. >> >> Le 31/03/2011 21:53, PAILLEAU Eric a ?crit : >>> $> erl -sname titi -config toto >>> >>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>> [hipe] [kernel-poll:false] >>> >>> Eshell V5.8.3 (abort with ^G) >>> 1> init:get_args(). >>> ** exception error: undefined function init:get_args/0 >>> >>> while >>> >>> 2> init:get_plain_arguments(). >>> [] >>> >>> Looks like init:get_args() does not exists while still in last >>> documentation. >>> >>> Did I miss something in doc, or is it a bug ? >>> >>> 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 > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From alessandro.sivieri@REDACTED Fri Apr 8 12:26:59 2011 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Fri, 8 Apr 2011 12:26:59 +0200 Subject: [erlang-bugs] Implicit declaration of function erl_malloc in legacy erl_timeout, R14B02 Message-ID: Hi all, I was trying to create Ubuntu packages for Erlang R14B02 in my private PPA, but the system failed to build them on 64bit architecture because of the following: [...] x86_64-linux-gnu-gcc -g -O2 -fno-strict-aliasing -DEI_64BIT -fPIC -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -fno-strict-aliasing -I. -I../include -Iconnect -Iencode -Idecode -Imisc -Iepmd -Iregistry -Ix86_64-pc-linux-gnu -c legacy/erl_timeout.c -o /build/buildd/erlang-14.b.2-dfsg/lib/erl_interface/ obj.st/x86_64-pc-linux-gnu/erl_timeout.o legacy/erl_timeout.c: In function 'timeout_setup': legacy/erl_timeout.c:77: warning: implicit declaration of function 'erl_malloc' legacy/erl_timeout.c:77: warning: nested extern declaration of 'erl_malloc' legacy/erl_timeout.c:77: warning: assignment makes pointer from integer without a cast Function `erl_malloc' implicitly converted to pointer at legacy/erl_timeout.c:77 [...] (and other three identical instances) The PPA system considers this kind of errors as possibly fatal for 64bit architectures ("always on ia64", using their words). I thought that this was the right place to report it. -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ http://www.poul.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.santos@REDACTED Fri Apr 8 14:10:15 2011 From: michael.santos@REDACTED (Michael Santos) Date: Fri, 8 Apr 2011 08:10:15 -0400 Subject: [erlang-bugs] Implicit declaration of function erl_malloc in legacy erl_timeout, R14B02 In-Reply-To: References: Message-ID: <20110408121015.GA30058@ecn.lan> On Fri, Apr 08, 2011 at 12:26:59PM +0200, Alessandro Sivieri wrote: > Hi all, > > I was trying to create Ubuntu packages for Erlang R14B02 in my private PPA, > but the system failed to build them on 64bit architecture because of the > following: > > [...] > x86_64-linux-gnu-gcc -g -O2 -fno-strict-aliasing -DEI_64BIT -fPIC -Wall > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -Winline -fno-strict-aliasing -I. -I../include -Iconnect > -Iencode -Idecode -Imisc -Iepmd -Iregistry -Ix86_64-pc-linux-gnu -c > legacy/erl_timeout.c -o /build/buildd/erlang-14.b.2-dfsg/lib/erl_interface/ > obj.st/x86_64-pc-linux-gnu/erl_timeout.o > legacy/erl_timeout.c: In function 'timeout_setup': > legacy/erl_timeout.c:77: warning: implicit declaration of function > 'erl_malloc' > legacy/erl_timeout.c:77: warning: nested extern declaration of 'erl_malloc' > legacy/erl_timeout.c:77: warning: assignment makes pointer from integer > without a cast > Function `erl_malloc' implicitly converted to pointer at > legacy/erl_timeout.c:77 > [...] > (and other three identical instances) > > The PPA system considers this kind of errors as possibly fatal for 64bit > architectures ("always on ia64", using their words). I thought that this was > the right place to report it. I think I broke this. Thanks for catching it! Does the attached patch fix the error? diff --git a/lib/erl_interface/src/legacy/erl_timeout.c b/lib/erl_interface/src/legacy/erl_timeout.c index d9560ee..146a106 100644 --- a/lib/erl_interface/src/legacy/erl_timeout.c +++ b/lib/erl_interface/src/legacy/erl_timeout.c @@ -43,6 +43,7 @@ # endif #endif +#include "erl_interface.h" #include "erl_timeout.h" typedef struct jmp_s { From alessandro.sivieri@REDACTED Fri Apr 8 15:15:02 2011 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Fri, 8 Apr 2011 15:15:02 +0200 Subject: [erlang-bugs] Implicit declaration of function erl_malloc in legacy erl_timeout, R14B02 In-Reply-To: <20110408121015.GA30058@ecn.lan> References: <20110408121015.GA30058@ecn.lan> Message-ID: On Fri, Apr 8, 2011 at 2:10 PM, Michael Santos wrote: > I think I broke this. Thanks for catching it! Does the attached patch > fix the error? > > Looks like it does, at least on my computer :) -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ http://www.poul.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.santos@REDACTED Fri Apr 8 16:40:10 2011 From: michael.santos@REDACTED (Michael Santos) Date: Fri, 8 Apr 2011 10:40:10 -0400 Subject: [erlang-bugs] Implicit declaration of function erl_malloc in legacy erl_timeout, R14B02 In-Reply-To: References: <20110408121015.GA30058@ecn.lan> Message-ID: <20110408144010.GB30058@ecn.lan> On Fri, Apr 08, 2011 at 03:15:02PM +0200, Alessandro Sivieri wrote: > On Fri, Apr 8, 2011 at 2:10 PM, Michael Santos wrote: > > > I think I broke this. Thanks for catching it! Does the attached patch > > fix the error? > > > > > Looks like it does, at least on my computer :) Awesome, thanks for testing it! I will submit a patch. From alessandro.sivieri@REDACTED Fri Apr 8 16:52:46 2011 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Fri, 8 Apr 2011 16:52:46 +0200 Subject: [erlang-bugs] Implicit declaration of function erl_malloc in legacy erl_timeout, R14B02 In-Reply-To: <20110408144010.GB30058@ecn.lan> References: <20110408121015.GA30058@ecn.lan> <20110408144010.GB30058@ecn.lan> Message-ID: On Fri, Apr 8, 2011 at 4:40 PM, Michael Santos wrote: > Awesome, thanks for testing it! I will submit a patch. > Ok, it works on Launchpad too. Thank you very much for your quick answer! -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ http://www.poul.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gopienko@REDACTED Mon Apr 11 06:49:54 2011 From: gopienko@REDACTED (Andrew Gopienko) Date: Mon, 11 Apr 2011 11:49:54 +0700 Subject: [erlang-bugs] Reltool and code clash Message-ID: In case of code clash between applications reltool skips beam files in generated release. I have Tsung installed under /usr/local/lib/erlang/lib and my release directory (rebar based) with mochiweb application. Tsung and mochiweb have same beams - mochijson2, mochinum, mochiweb_charref, mochiweb_html. Key fragment of reltool.config {app, mochiweb, [{incl_cond, include}]}, {app, 'tsung-1.4.0a', [{incl_cond, exclude}]}, For such configuration reltool generates release in which there are no files mochijson2.beam, mochinum.beam, mochiweb_charref.beam, mochiweb_html.beam in mochiweb application. I think, in this situation, reltool can return an error or using the hint {incl_cond, exclude} to generate the proper release spec. Andrew Gopienko ThreeLine LLC trxline.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From Benjamin.Winkler@REDACTED Mon Apr 11 09:34:20 2011 From: Benjamin.Winkler@REDACTED (Benjamin Winkler) Date: Mon, 11 Apr 2011 09:34:20 +0200 Subject: [erlang-bugs] erl_interface and threads In-Reply-To: <20110407181520.GK24843@hijacked.us> References: <4D9D6D61.4040907@specs.com> <20110407170837.GA29038@ecn.lan> <20110407181520.GK24843@hijacked.us> Message-ID: <4DA2AEFC.3060908@specs.com> Am 07.04.2011 20:15, schrieb Andrew Thompson: > On Thu, Apr 07, 2011 at 01:08:37PM -0400, Michael Santos wrote: >> On Thu, Apr 07, 2011 at 09:53:05AM +0200, Benjamin Winkler wrote: >>> Hi! >>> >>> We are using Erlang and specifically the erl_interface for C (Visual >>> Studio C++ 2008, Windows 7) to connect to our Erlang servers. We have >>> noticed weird errors when creating (and freeing) terms in different >>> threads. It seems to me that the memory allocation module is not >>> thread-aware. >> This isn't helpful with solving your problem with erl_interface but >> have you looked at the newer ei interface? It lets you manage the memory >> yourself (or allocates memory for you if you use the ei_x_* functions). > I'm pretty sure that the whole point of ei is to be a thread-safe > replacement for erl_interface. Yes, that is what I ultimately did to solve the problem. Plus using a mutex to lock every single call to ETERM-allocation functions such as erl_mk_atom() and erl_free_term(). Tedious. However, I did not find any notice of that behaviour in the erl_interface documentation. Also, ei provides a function ei_decode_term() which references the erl_interface library, and I'm pretty sure that this is not thread-safe as well as the whole problem seems to be the memory allocation for erlang terms. So all in all the conclusion would be: stay away from ETERM? Benni From xramtsov@REDACTED Tue Apr 12 08:25:21 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Tue, 12 Apr 2011 16:25:21 +1000 Subject: [erlang-bugs] Bug in the resolver? Message-ID: <4DA3F051.2000303@gmail.com> We have a weird problem with inet_res in R14B02. Here is a snippet: =ERROR REPORT==== 2011-04-11 18:45:50 === ** State machine <0.6000.0> terminating .... ** Reason for termination = ** {{case_clause,{{1302,533150,198860},undefined}}, [{inet_res,do_udp_recv,5}, {inet_res,query_udp_recv,6}, {inet_res,query_ns,10}, {inet_res,query_nss_dns,7}, {inet_res,query_retries,6}, {inet_res,res_getby_query,4}, {inet_res,res_getby_search,6}, {inet_res,getbyname,3}]} Any clue how to debug this? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From spawn.think@REDACTED Tue Apr 12 10:27:48 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 12 Apr 2011 10:27:48 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <4DA3F051.2000303@gmail.com> References: <4DA3F051.2000303@gmail.com> Message-ID: Any steps to reproduce it? On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: > We have a weird problem with inet_res in R14B02. Here is a snippet: > > =ERROR REPORT==== 2011-04-11 18:45:50 === > ** State machine <0.6000.0> terminating > .... > ** Reason for termination = > ** {{case_clause,{{1302,533150,198860},undefined}}, > [{inet_res,do_udp_recv,5}, > {inet_res,query_udp_recv,6}, > {inet_res,query_ns,10}, > {inet_res,query_nss_dns,7}, > {inet_res,query_retries,6}, > {inet_res,res_getby_query,4}, > {inet_res,res_getby_search,6}, > {inet_res,getbyname,3}]} > > Any clue how to debug this? > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Tue Apr 12 10:34:54 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 12 Apr 2011 10:34:54 +0200 Subject: [erlang-bugs] Dialyzer unmatched_returns generates false positives Message-ID: <4DA40EAE.3090409@erlang-solutions.com> Hi, Using the option unmatched_returns in dialyzer seems to generate false positives inside list comprehensions. Consider the following code: f() -> ok. g() -> [f() || _E <- lists:seq(1,3)], ok. It generates the following warning: Expression produces a value of type ['ok'], but this value is unmatched. This is okay, because we don't actually match on the return from f(). I would think that the following fix removes the warning, but it does not: g() -> [ok = f() || E <- lists:seq(1,3)], ok. For a list of variable length, the only alternative would be the following (which dialyzer does not complain about): g() -> lists:all(fun(ok) -> true end, [ok = f() || _E <- lists:seq(1,3)]), ok. But it doesn't have the same behavior (will generate a function clause error instead of a badmatch error if something fails). Cheers, Adam From spawn.think@REDACTED Tue Apr 12 10:52:01 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 12 Apr 2011 10:52:01 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> Message-ID: Actually it might be a bug. There's a clause in do_udp_recv/4 that will call do_upd_recv/5 with the value of Then as undefined. If this value passed to now_ms/2 , it will crash. The crash reason is converted to case_clause instead of function_clause because now_ms/2 is inlined. On Tue, Apr 12, 2011 at 10:27 AM, Ahmed Omar wrote: > Any steps to reproduce it? > > > On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: > >> We have a weird problem with inet_res in R14B02. Here is a snippet: >> >> =ERROR REPORT==== 2011-04-11 18:45:50 === >> ** State machine <0.6000.0> terminating >> .... >> ** Reason for termination = >> ** {{case_clause,{{1302,533150,198860},undefined}}, >> [{inet_res,do_udp_recv,5}, >> {inet_res,query_udp_recv,6}, >> {inet_res,query_ns,10}, >> {inet_res,query_nss_dns,7}, >> {inet_res,query_retries,6}, >> {inet_res,res_getby_query,4}, >> {inet_res,res_getby_search,6}, >> {inet_res,getbyname,3}]} >> >> Any clue how to debug this? >> >> -- >> Regards, >> Evgeniy Khramtsov, ProcessOne. >> xmpp:xram@REDACTED >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue Apr 12 10:50:53 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 12 Apr 2011 11:50:53 +0300 Subject: [erlang-bugs] Dialyzer unmatched_returns generates false positives In-Reply-To: <4DA40EAE.3090409@erlang-solutions.com> References: <4DA40EAE.3090409@erlang-solutions.com> Message-ID: <4DA4126D.1030401@cs.ntua.gr> Adam Lindberg wrote: > Hi, > > Using the option unmatched_returns in dialyzer seems to generate false > positives inside list comprehensions. Consider the following code: > > f() -> ok. > > g() -> [f() || _E <- lists:seq(1,3)], ok. > > It generates the following warning: > > Expression produces a value of type ['ok'], but this value is unmatched. > > This is okay, because we don't actually match on the return from f(). I > would think that the following fix removes the warning, but it does not: > > g() -> [ok = f() || E <- lists:seq(1,3)], ok. > > For a list of variable length, the only alternative would be the > following (which dialyzer does not complain about): > > g() -> lists:all(fun(ok) -> true end, [ok = f() || _E <- > lists:seq(1,3)]), ok. > > But it doesn't have the same behavior (will generate a function clause > error instead of a badmatch error if something fails). You misunderstand both the warning and how to fix it. Dialyzer does not complain that the f() return is unmatched, but it complains that the return from the list comprehension is unmatched. Note that the warning does not say 'ok' but it says ['ok'] (i.e., that a list of 'ok' values is unmatched). And indeed it is as far as *Erlang* is concerned. Now, it's true that the BEAM compiler performs an optimization that does not construct this list, but this is not something that is reflected in the operational semantics of Erlang. Because dialyzer is based on Core Erlang and aims to be compiler independent (it's conceivable that in the future some other compiler may take the place of BEAM) it does not model its optimizations. Anyway, this is not a false positive. It's a bit unfortunate, but it's intentional. The proper way to write this in order not to get the dialyzer warning with unmatched return is to write the following: g() -> lists:foreach(fun(_E) -> f() end, lists:seq(1,3)), ok. If you want to write it with the list comprehension, the kosher way to write it is: g() -> _ = [f() || E <- lists:seq(1,3)], ok. Kostis From adam@REDACTED Tue Apr 12 11:05:37 2011 From: adam@REDACTED (Adam Lindberg) Date: Tue, 12 Apr 2011 11:05:37 +0200 Subject: [erlang-bugs] Dialyzer unmatched_returns generates false positives In-Reply-To: <4DA4126D.1030401@cs.ntua.gr> References: <4DA40EAE.3090409@erlang-solutions.com> <4DA4126D.1030401@cs.ntua.gr> Message-ID: <4DA415E1.7010300@erlang-solutions.com> Ah, I see. How come dialyzer complains about the list comprehension and not the lists:foreach/2 call? Is there any difference between them that warrants the warning in one case but not the other? As I see it, they still run my code in a sequence and I don't understand why I would be more interested to match the return value in one case but not the other. Cheers, Adam Kostis Sagonas wrote: > Adam Lindberg wrote: >> Hi, >> >> Using the option unmatched_returns in dialyzer seems to generate false >> positives inside list comprehensions. Consider the following code: >> >> f() -> ok. >> >> g() -> [f() || _E <- lists:seq(1,3)], ok. >> >> It generates the following warning: >> >> Expression produces a value of type ['ok'], but this value is unmatched. >> >> This is okay, because we don't actually match on the return from f(). >> I would think that the following fix removes the warning, but it does >> not: >> >> g() -> [ok = f() || E <- lists:seq(1,3)], ok. >> >> For a list of variable length, the only alternative would be the >> following (which dialyzer does not complain about): >> >> g() -> lists:all(fun(ok) -> true end, [ok = f() || _E <- >> lists:seq(1,3)]), ok. >> >> But it doesn't have the same behavior (will generate a function clause >> error instead of a badmatch error if something fails). > > You misunderstand both the warning and how to fix it. Dialyzer does not > complain that the f() return is unmatched, but it complains that the > return from the list comprehension is unmatched. Note that the warning > does not say 'ok' but it says ['ok'] (i.e., that a list of 'ok' values > is unmatched). And indeed it is as far as *Erlang* is concerned. > > Now, it's true that the BEAM compiler performs an optimization that does > not construct this list, but this is not something that is reflected in > the operational semantics of Erlang. Because dialyzer is based on Core > Erlang and aims to be compiler independent (it's conceivable that in the > future some other compiler may take the place of BEAM) it does not model > its optimizations. > > Anyway, this is not a false positive. It's a bit unfortunate, but it's > intentional. The proper way to write this in order not to get the > dialyzer warning with unmatched return is to write the following: > > g() -> > lists:foreach(fun(_E) -> f() end, lists:seq(1,3)), > ok. > > If you want to write it with the list comprehension, the kosher way to > write it is: > > g() -> > _ = [f() || E <- lists:seq(1,3)], > ok. > > Kostis From spawn.think@REDACTED Tue Apr 12 11:24:28 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 12 Apr 2011 11:24:28 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> Message-ID: I think this should solve it, but i think someone from OTP team can verify it index de0f23b..9151cac 100644 --- a/lib/kernel/src/inet_res.erl +++ b/lib/kernel/src/inet_res.erl @@ -552,10 +552,10 @@ do_udp_recv(Recv, IP, Port, Timeout) -> do_udp_recv(Recv, IP, Port, Timeout, Then) -> case Recv(Timeout) of + {ok,_} when Timeout =:= 0 -> + {error,timeout}; {ok,{IP,Port,Answer}} -> {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; - {ok,_} when Timeout =:= 0 -> - {error,timeout}; {ok,_} -> Now = erlang:now(), T = erlang:max(0, Timeout - now_ms(Now, Then)), On Tue, Apr 12, 2011 at 10:52 AM, Ahmed Omar wrote: > Actually it might be a bug. There's a clause in do_udp_recv/4 that will > call do_upd_recv/5 with the value of Then as undefined. > If this value passed to now_ms/2 , it will crash. The crash reason is > converted to case_clause instead of function_clause because now_ms/2 is > inlined. > > > On Tue, Apr 12, 2011 at 10:27 AM, Ahmed Omar wrote: > >> Any steps to reproduce it? >> >> >> On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: >> >>> We have a weird problem with inet_res in R14B02. Here is a snippet: >>> >>> =ERROR REPORT==== 2011-04-11 18:45:50 === >>> ** State machine <0.6000.0> terminating >>> .... >>> ** Reason for termination = >>> ** {{case_clause,{{1302,533150,198860},undefined}}, >>> [{inet_res,do_udp_recv,5}, >>> {inet_res,query_udp_recv,6}, >>> {inet_res,query_ns,10}, >>> {inet_res,query_nss_dns,7}, >>> {inet_res,query_retries,6}, >>> {inet_res,res_getby_query,4}, >>> {inet_res,res_getby_search,6}, >>> {inet_res,getbyname,3}]} >>> >>> Any clue how to debug this? >>> >>> -- >>> Regards, >>> Evgeniy Khramtsov, ProcessOne. >>> xmpp:xram@REDACTED >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick@REDACTED Tue Apr 12 11:49:31 2011 From: nick@REDACTED (Niclas Eklund) Date: Tue, 12 Apr 2011 11:49:31 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> Message-ID: Perhaps this got something to do with it: 1> calendar:now_to_datetime({1302,533150,198860}). {{2011,4,11},{14,45,50}} I.e. passing wrong kind of argument. Best Regards, Niclas @ Erlang/OTP On Tue, 12 Apr 2011, Ahmed Omar wrote: > Any steps to reproduce it? > > On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: > >> We have a weird problem with inet_res in R14B02. Here is a snippet: >> >> =ERROR REPORT==== 2011-04-11 18:45:50 === >> ** State machine <0.6000.0> terminating >> .... >> ** Reason for termination = >> ** {{case_clause,{{1302,533150,198860},undefined}}, >> [{inet_res,do_udp_recv,5}, >> {inet_res,query_udp_recv,6}, >> {inet_res,query_ns,10}, >> {inet_res,query_nss_dns,7}, >> {inet_res,query_retries,6}, >> {inet_res,res_getby_query,4}, >> {inet_res,res_getby_search,6}, >> {inet_res,getbyname,3}]} >> >> Any clue how to debug this? >> >> -- >> Regards, >> Evgeniy Khramtsov, ProcessOne. >> xmpp:xram@REDACTED >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > From raimo+erlang-bugs@REDACTED Tue Apr 12 12:30:08 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 12 Apr 2011 12:30:08 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> Message-ID: <20110412103007.GA2965@erix.ericsson.se> On Tue, Apr 12, 2011 at 10:27:48AM +0200, Ahmed Omar wrote: > Any steps to reproduce it? > > On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: > > > We have a weird problem with inet_res in R14B02. Here is a snippet: > > > > =ERROR REPORT==== 2011-04-11 18:45:50 === > > ** State machine <0.6000.0> terminating > > .... > > ** Reason for termination = > > ** {{case_clause,{{1302,533150,198860},undefined}}, > > [{inet_res,do_udp_recv,5}, > > {inet_res,query_udp_recv,6}, > > {inet_res,query_ns,10}, > > {inet_res,query_nss_dns,7}, > > {inet_res,query_retries,6}, > > {inet_res,res_getby_query,4}, > > {inet_res,res_getby_search,6}, > > {inet_res,getbyname,3}]} > > > > Any clue how to debug this? The stacktrace was enough. You must have called inet_res:getbyname(Name, Type, infinity), and that was apparently not tested. The functions that calculate the remaining time for do_udp_recv/5 are not written for a timeout of 'infinity' and crash for the subtraction of Now - 'undefined'. This is a bug. Thank you for reporting it. You should be able to work around it by using a long timeout value. > > > > -- > > Regards, > > Evgeniy Khramtsov, ProcessOne. > > xmpp:xram@REDACTED > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From xramtsov@REDACTED Tue Apr 12 13:13:10 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Tue, 12 Apr 2011 21:13:10 +1000 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110412103007.GA2965@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> Message-ID: <4DA433C6.9050908@gmail.com> 12.04.2011 20:30, Raimo Niskanen wrote: > > You must have called inet_res:getbyname(Name, Type, infinity), > and that was apparently not tested. The functions that calculate > the remaining time for do_udp_recv/5 are not written for a timeout of > 'infinity' and crash for the subtraction of Now - 'undefined'. > Strange. There is inet_res:getbyname(String, srv, 10000) actually. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From raimo+erlang-bugs@REDACTED Tue Apr 12 13:35:33 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 12 Apr 2011 13:35:33 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> Message-ID: <20110412113533.GA6292@erix.ericsson.se> On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: > Hmmm, the crash doesn't look to be in subtraction (otherwise it would have > been badarg?), it's a crash because of a function clause in now_ms (because > undefined won't match) > (and undefined looks to be generated only when timeout is 0 ) Well, I ment _conceptually_ subtract since now_ms/2 is supposed to return the number of elapsed microseconds i.e subtract its now() arguments, and now got 'undefined' instead of {MegaSec,Sec,MicroSec) as second argumnent. 'undefined' must be a leftover from an unfinished implementation of either the case when you have timed out or when the timeout is 'infinity'. Nevertheless it is incorrect. The Timeout variable is how long time still remains to wait of the initial user interface timeout. > > Maybe I'm missing something or my coffee doesn't work :) > > On Tue, Apr 12, 2011 at 12:30 PM, Raimo Niskanen < > raimo+erlang-bugs@REDACTED> wrote: > > > On Tue, Apr 12, 2011 at 10:27:48AM +0200, Ahmed Omar wrote: > > > Any steps to reproduce it? > > > > > > On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov > >wrote: > > > > > > > We have a weird problem with inet_res in R14B02. Here is a snippet: > > > > > > > > =ERROR REPORT==== 2011-04-11 18:45:50 === > > > > ** State machine <0.6000.0> terminating > > > > .... > > > > ** Reason for termination = > > > > ** {{case_clause,{{1302,533150,198860},undefined}}, > > > > [{inet_res,do_udp_recv,5}, > > > > {inet_res,query_udp_recv,6}, > > > > {inet_res,query_ns,10}, > > > > {inet_res,query_nss_dns,7}, > > > > {inet_res,query_retries,6}, > > > > {inet_res,res_getby_query,4}, > > > > {inet_res,res_getby_search,6}, > > > > {inet_res,getbyname,3}]} > > > > > > > > Any clue how to debug this? > > > > The stacktrace was enough. > > > > You must have called inet_res:getbyname(Name, Type, infinity), > > and that was apparently not tested. The functions that calculate > > the remaining time for do_udp_recv/5 are not written for a timeout of > > 'infinity' and crash for the subtraction of Now - 'undefined'. > > > > This is a bug. Thank you for reporting it. > > > > You should be able to work around it by using a long timeout value. > > > > > > > > > > -- > > > > Regards, > > > > Evgeniy Khramtsov, ProcessOne. > > > > xmpp:xram@REDACTED > > > > > > > > _______________________________________________ > > > > erlang-bugs mailing list > > > > erlang-bugs@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > > > > > > > -- > > > Best Regards, > > > - Ahmed Omar > > > http://nl.linkedin.com/in/adiaa > > > Follow me on twitter > > > @spawn_think > > > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Tue Apr 12 13:46:05 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 12 Apr 2011 13:46:05 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <4DA433C6.9050908@gmail.com> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <4DA433C6.9050908@gmail.com> Message-ID: <20110412114605.GB6292@erix.ericsson.se> On Tue, Apr 12, 2011 at 09:13:10PM +1000, Evgeniy Khramtsov wrote: > 12.04.2011 20:30, Raimo Niskanen wrote: > > > >You must have called inet_res:getbyname(Name, Type, infinity), > >and that was apparently not tested. The functions that calculate > >the remaining time for do_udp_recv/5 are not written for a timeout of > >'infinity' and crash for the subtraction of Now - 'undefined'. > > > > Strange. There is inet_res:getbyname(String, srv, 10000) actually. Sorry, I misread the condition in the code. To get to where your stacktrace tells me the value of Timeout to inet_res:do_udp_receive/5 must be 0. Then it seems the code accidentally loops exactly when 0 milliseconds remain to wait for the whole user interface timeout. If a lower level timeout of 5 seconds (which sounds familiar) is involved, then two such UDP timeouts could make the code loop after exactly 10 seconds and get a rest timeout of 0 ms. Try a timeout value of 11111 ms instead. If this guess is correct the bug is more serious than I first assumed. > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Tue Apr 12 13:51:28 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 12 Apr 2011 13:51:28 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110412113533.GA6292@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <20110412113533.GA6292@erix.ericsson.se> Message-ID: <20110412115128.GA6987@erix.ericsson.se> On Tue, Apr 12, 2011 at 01:35:33PM +0200, Raimo Niskanen wrote: > On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: > > Hmmm, the crash doesn't look to be in subtraction (otherwise it would have > > been badarg?), it's a crash because of a function clause in now_ms (because > > undefined won't match) > > (and undefined looks to be generated only when timeout is 0 ) > > Well, I ment _conceptually_ subtract since now_ms/2 is supposed to > return the number of elapsed microseconds i.e subtract Milliseconds. Sorry. That should be milliseconds. > its now() arguments, and now got 'undefined' instead > of {MegaSec,Sec,MicroSec) as second argumnent. > > 'undefined' must be a leftover from an unfinished implementation > of either the case when you have timed out or when the > timeout is 'infinity'. Nevertheless it is incorrect. > > The Timeout variable is how long time still remains to wait of the > initial user interface timeout. > > > > > Maybe I'm missing something or my coffee doesn't work :) > > : : > > Follow me on twitter > > @spawn_think > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From spawn.think@REDACTED Tue Apr 12 13:56:26 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 12 Apr 2011 13:56:26 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110412115128.GA6987@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <20110412113533.GA6292@erix.ericsson.se> <20110412115128.GA6987@erix.ericsson.se> Message-ID: Then going back to my original message, the order of case clauses doesn't sound right {ok,{IP,Port,Answer}} -> {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; {ok,_} when Timeout =:= 0 -> {error,timeout}; Cause even when the timeout is 0 now, now_ms/2 will be called with Then = undefined On Tue, Apr 12, 2011 at 1:51 PM, Raimo Niskanen < raimo+erlang-bugs@REDACTED> wrote: > On Tue, Apr 12, 2011 at 01:35:33PM +0200, Raimo Niskanen wrote: > > On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: > > > Hmmm, the crash doesn't look to be in subtraction (otherwise it would > have > > > been badarg?), it's a crash because of a function clause in now_ms > (because > > > undefined won't match) > > > (and undefined looks to be generated only when timeout is 0 ) > > > > Well, I ment _conceptually_ subtract since now_ms/2 is supposed to > > return the number of elapsed microseconds i.e subtract > > Milliseconds. Sorry. That should be milliseconds. > > > its now() arguments, and now got 'undefined' instead > > of {MegaSec,Sec,MicroSec) as second argumnent. > > > > 'undefined' must be a leftover from an unfinished implementation > > of either the case when you have timed out or when the > > timeout is 'infinity'. Nevertheless it is incorrect. > > > > The Timeout variable is how long time still remains to wait of the > > initial user interface timeout. > > > > > > > > Maybe I'm missing something or my coffee doesn't work :) > > > > : : > > > Follow me on twitter > > > @spawn_think > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > 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 > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue Apr 12 18:36:52 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 12 Apr 2011 19:36:52 +0300 Subject: [erlang-bugs] Dialyzer unmatched_returns generates false positives In-Reply-To: <4DA415E1.7010300@erlang-solutions.com> References: <4DA40EAE.3090409@erlang-solutions.com> <4DA4126D.1030401@cs.ntua.gr> <4DA415E1.7010300@erlang-solutions.com> Message-ID: <4DA47FA4.60501@cs.ntua.gr> Adam Lindberg wrote: > Ah, I see. > > How come dialyzer complains about the list comprehension and not the > lists:foreach/2 call? Is there any difference between them that warrants > the warning in one case but not the other? This is a fair question. Dialyzer suppresses the warnings for unmatched returns when the return is a single *atomic* value (e.g., an atom like 'ok' as in the lists:foreach/2 case or an integer like 42). It complains in all other cases (i.e., when the return is a structured term like a list or a tuple or when there are multiple returns like 'ok' | 'error'). Hope this clears the issue now. Kostis From adam@REDACTED Wed Apr 13 10:31:23 2011 From: adam@REDACTED (Adam Lindberg) Date: Wed, 13 Apr 2011 10:31:23 +0200 Subject: [erlang-bugs] Dialyzer unmatched_returns generates false positives In-Reply-To: <4DA47FA4.60501@cs.ntua.gr> References: <4DA40EAE.3090409@erlang-solutions.com> <4DA4126D.1030401@cs.ntua.gr> <4DA415E1.7010300@erlang-solutions.com> <4DA47FA4.60501@cs.ntua.gr> Message-ID: <4DA55F5B.2000309@erlang-solutions.com> Thanks for clearing it up! Cheers, Adam Kostis Sagonas wrote: > Adam Lindberg wrote: >> Ah, I see. >> >> How come dialyzer complains about the list comprehension and not the >> lists:foreach/2 call? Is there any difference between them that >> warrants the warning in one case but not the other? > > This is a fair question. Dialyzer suppresses the warnings for unmatched > returns when the return is a single *atomic* value (e.g., an atom like > 'ok' as in the lists:foreach/2 case or an integer like 42). It complains > in all other cases (i.e., when the return is a structured term like a > list or a tuple or when there are multiple returns like 'ok' | 'error'). > > Hope this clears the issue now. > > Kostis From raimo+erlang-bugs@REDACTED Wed Apr 13 10:36:46 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 13 Apr 2011 10:36:46 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> Message-ID: <20110413083646.GA28493@erix.ericsson.se> On Tue, Apr 12, 2011 at 11:24:28AM +0200, Ahmed Omar wrote: > I think this should solve it, but i think someone from OTP team can verify > it > > index de0f23b..9151cac 100644 > --- a/lib/kernel/src/inet_res.erl > +++ b/lib/kernel/src/inet_res.erl > @@ -552,10 +552,10 @@ do_udp_recv(Recv, IP, Port, Timeout) -> > > do_udp_recv(Recv, IP, Port, Timeout, Then) -> > case Recv(Timeout) of > + {ok,_} when Timeout =:= 0 -> > + {error,timeout}; > {ok,{IP,Port,Answer}} -> > {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; > - {ok,_} when Timeout =:= 0 -> > - {error,timeout}; > {ok,_} -> > Now = erlang:now(), > T = erlang:max(0, Timeout - now_ms(Now, Then)), Would not that throw away an answer coming in at the last millisecond? > > > On Tue, Apr 12, 2011 at 10:52 AM, Ahmed Omar wrote: > > > Actually it might be a bug. There's a clause in do_udp_recv/4 that will > > call do_upd_recv/5 with the value of Then as undefined. > > If this value passed to now_ms/2 , it will crash. The crash reason is > > converted to case_clause instead of function_clause because now_ms/2 is > > inlined. > > > > > > On Tue, Apr 12, 2011 at 10:27 AM, Ahmed Omar wrote: > > > >> Any steps to reproduce it? > >> > >> > >> On Tue, Apr 12, 2011 at 8:25 AM, Evgeniy Khramtsov wrote: > >> > >>> We have a weird problem with inet_res in R14B02. Here is a snippet: > >>> > >>> =ERROR REPORT==== 2011-04-11 18:45:50 === > >>> ** State machine <0.6000.0> terminating > >>> .... > >>> ** Reason for termination = > >>> ** {{case_clause,{{1302,533150,198860},undefined}}, > >>> [{inet_res,do_udp_recv,5}, > >>> {inet_res,query_udp_recv,6}, > >>> {inet_res,query_ns,10}, > >>> {inet_res,query_nss_dns,7}, > >>> {inet_res,query_retries,6}, > >>> {inet_res,res_getby_query,4}, > >>> {inet_res,res_getby_search,6}, > >>> {inet_res,getbyname,3}]} > >>> > >>> Any clue how to debug this? > >>> > >>> -- > >>> Regards, > >>> Evgeniy Khramtsov, ProcessOne. > >>> xmpp:xram@REDACTED > >>> > >>> _______________________________________________ > >>> erlang-bugs mailing list > >>> erlang-bugs@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-bugs > >>> > >> > >> > >> > >> -- > >> Best Regards, > >> - Ahmed Omar > >> http://nl.linkedin.com/in/adiaa > >> Follow me on twitter > >> @spawn_think > >> > >> > > > > > > -- > > Best Regards, > > - Ahmed Omar > > http://nl.linkedin.com/in/adiaa > > Follow me on twitter > > @spawn_think > > > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Wed Apr 13 10:43:24 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 13 Apr 2011 10:43:24 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <20110412113533.GA6292@erix.ericsson.se> <20110412115128.GA6987@erix.ericsson.se> Message-ID: <20110413084324.GA28820@erix.ericsson.se> On Tue, Apr 12, 2011 at 01:56:26PM +0200, Ahmed Omar wrote: > Then going back to my original message, the order of case clauses doesn't > sound right > {ok,{IP,Port,Answer}} -> > {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; > {ok,_} when Timeout =:= 0 -> > {error,timeout}; > > > Cause even when the timeout is 0 now, now_ms/2 will be called with Then = > undefined I will dig into this in a few days, after my current tasks, and will post a diff when the yet unwritten testcases start working... > > On Tue, Apr 12, 2011 at 1:51 PM, Raimo Niskanen < > raimo+erlang-bugs@REDACTED> wrote: > > > On Tue, Apr 12, 2011 at 01:35:33PM +0200, Raimo Niskanen wrote: > > > On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: > > > > Hmmm, the crash doesn't look to be in subtraction (otherwise it would > > have > > > > been badarg?), it's a crash because of a function clause in now_ms > > (because > > > > undefined won't match) > > > > (and undefined looks to be generated only when timeout is 0 ) > > > > > > Well, I ment _conceptually_ subtract since now_ms/2 is supposed to > > > return the number of elapsed microseconds i.e subtract > > > > Milliseconds. Sorry. That should be milliseconds. > > > > > its now() arguments, and now got 'undefined' instead > > > of {MegaSec,Sec,MicroSec) as second argumnent. > > > > > > 'undefined' must be a leftover from an unfinished implementation > > > of either the case when you have timed out or when the > > > timeout is 'infinity'. Nevertheless it is incorrect. > > > > > > The Timeout variable is how long time still remains to wait of the > > > initial user interface timeout. > > > > > > > > > > > Maybe I'm missing something or my coffee doesn't work :) > > > > > > : : > > > > Follow me on twitter > > > > @spawn_think > > > > > > -- > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > > > 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 > > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From spawn.think@REDACTED Wed Apr 13 11:06:20 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 13 Apr 2011 11:06:20 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110413084324.GA28820@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <20110412113533.GA6292@erix.ericsson.se> <20110412115128.GA6987@erix.ericsson.se> <20110413084324.GA28820@erix.ericsson.se> Message-ID: Indeed you are correct. I wrote it in a different way, removed the undefined and avoided subtraction if Timeout is 0 diff --git a/lib/kernel/src/inet_res.erl b/lib/kernel/src/inet_res.erl index de0f23b..0ba5969 100644 --- a/lib/kernel/src/inet_res.erl +++ b/lib/kernel/src/inet_res.erl @@ -547,15 +547,16 @@ udp_recv(#sock{inet=I}, {A,B,C,D}=IP, Port, Timeout) do_udp_recv(fun(T) -> gen_udp:recv(I, 0, T) end, IP, Port, Timeout). do_udp_recv(Recv, IP, Port, Timeout) -> - do_udp_recv(Recv, IP, Port, Timeout, - if Timeout =/= 0 -> erlang:now(); true -> undefined end). + do_udp_recv(Recv, IP, Port, Timeout, erlang:now()). do_udp_recv(Recv, IP, Port, Timeout, Then) -> case Recv(Timeout) of + {ok,{IP,Port,Answer}} when Timeout =:= 0-> + {ok, Answer, Timeout}; {ok,{IP,Port,Answer}} -> {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; - {ok,_} when Timeout =:= 0 -> - {error,timeout}; + {ok,_} when Timeout =:= 0 -> + {error,timeout}; {ok,_} -> Now = erlang:now(), T = erlang:max(0, Timeout - now_ms(Now, Then)), On Wed, Apr 13, 2011 at 10:43 AM, Raimo Niskanen < raimo+erlang-bugs@REDACTED> wrote: > On Tue, Apr 12, 2011 at 01:56:26PM +0200, Ahmed Omar wrote: > > Then going back to my original message, the order of case clauses doesn't > > sound right > > {ok,{IP,Port,Answer}} -> > > {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; > > {ok,_} when Timeout =:= 0 -> > > {error,timeout}; > > > > > > Cause even when the timeout is 0 now, now_ms/2 will be called with Then = > > undefined > > I will dig into this in a few days, after my current tasks, and will > post a diff when the yet unwritten testcases start working... > > > > > On Tue, Apr 12, 2011 at 1:51 PM, Raimo Niskanen < > > raimo+erlang-bugs@REDACTED> wrote: > > > > > On Tue, Apr 12, 2011 at 01:35:33PM +0200, Raimo Niskanen wrote: > > > > On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: > > > > > Hmmm, the crash doesn't look to be in subtraction (otherwise it > would > > > have > > > > > been badarg?), it's a crash because of a function clause in now_ms > > > (because > > > > > undefined won't match) > > > > > (and undefined looks to be generated only when timeout is 0 ) > > > > > > > > Well, I ment _conceptually_ subtract since now_ms/2 is supposed to > > > > return the number of elapsed microseconds i.e subtract > > > > > > Milliseconds. Sorry. That should be milliseconds. > > > > > > > its now() arguments, and now got 'undefined' instead > > > > of {MegaSec,Sec,MicroSec) as second argumnent. > > > > > > > > 'undefined' must be a leftover from an unfinished implementation > > > > of either the case when you have timed out or when the > > > > timeout is 'infinity'. Nevertheless it is incorrect. > > > > > > > > The Timeout variable is how long time still remains to wait of the > > > > initial user interface timeout. > > > > > > > > > > > > > > Maybe I'm missing something or my coffee doesn't work :) > > > > > > > > : : > > > > > Follow me on twitter > > > > > @spawn_think > > > > > > > > -- > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > -- > > Best Regards, > > - Ahmed Omar > > http://nl.linkedin.com/in/adiaa > > Follow me on twitter > > @spawn_think > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed Apr 13 11:08:09 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 13 Apr 2011 11:08:09 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <20110412113533.GA6292@erix.ericsson.se> <20110412115128.GA6987@erix.ericsson.se> <20110413084324.GA28820@erix.ericsson.se> Message-ID: If you agree with it, i can submit a proper patch On Wed, Apr 13, 2011 at 11:06 AM, Ahmed Omar wrote: > Indeed you are correct. I wrote it in a different way, removed the > undefined and avoided subtraction if Timeout is 0 > diff --git a/lib/kernel/src/inet_res.erl b/lib/kernel/src/inet_res.erl > index de0f23b..0ba5969 100644 > --- a/lib/kernel/src/inet_res.erl > +++ b/lib/kernel/src/inet_res.erl > @@ -547,15 +547,16 @@ udp_recv(#sock{inet=I}, {A,B,C,D}=IP, Port, Timeout) > do_udp_recv(fun(T) -> gen_udp:recv(I, 0, T) end, IP, Port, Timeout). > > do_udp_recv(Recv, IP, Port, Timeout) -> > - do_udp_recv(Recv, IP, Port, Timeout, > - if Timeout =/= 0 -> erlang:now(); true -> undefined end). > + do_udp_recv(Recv, IP, Port, Timeout, erlang:now()). > > do_udp_recv(Recv, IP, Port, Timeout, Then) -> > case Recv(Timeout) of > + {ok,{IP,Port,Answer}} when Timeout =:= 0-> > + {ok, Answer, Timeout}; > {ok,{IP,Port,Answer}} -> > {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), > Then))}; > - {ok,_} when Timeout =:= 0 -> > - {error,timeout}; > + {ok,_} when Timeout =:= 0 -> > + {error,timeout}; > {ok,_} -> > Now = erlang:now(), > T = erlang:max(0, Timeout - now_ms(Now, Then)), > > > On Wed, Apr 13, 2011 at 10:43 AM, Raimo Niskanen < > raimo+erlang-bugs@REDACTED> wrote: > >> On Tue, Apr 12, 2011 at 01:56:26PM +0200, Ahmed Omar wrote: >> > Then going back to my original message, the order of case clauses >> doesn't >> > sound right >> > {ok,{IP,Port,Answer}} -> >> > {ok,Answer,erlang:max(0, Timeout - now_ms(erlang:now(), Then))}; >> > {ok,_} when Timeout =:= 0 -> >> > {error,timeout}; >> > >> > >> > Cause even when the timeout is 0 now, now_ms/2 will be called with Then >> = >> > undefined >> >> I will dig into this in a few days, after my current tasks, and will >> post a diff when the yet unwritten testcases start working... >> >> > >> > On Tue, Apr 12, 2011 at 1:51 PM, Raimo Niskanen < >> > raimo+erlang-bugs@REDACTED> wrote: >> > >> > > On Tue, Apr 12, 2011 at 01:35:33PM +0200, Raimo Niskanen wrote: >> > > > On Tue, Apr 12, 2011 at 01:08:24PM +0200, Ahmed Omar wrote: >> > > > > Hmmm, the crash doesn't look to be in subtraction (otherwise it >> would >> > > have >> > > > > been badarg?), it's a crash because of a function clause in >> now_ms >> > > (because >> > > > > undefined won't match) >> > > > > (and undefined looks to be generated only when timeout is 0 ) >> > > > >> > > > Well, I ment _conceptually_ subtract since now_ms/2 is supposed to >> > > > return the number of elapsed microseconds i.e subtract >> > > >> > > Milliseconds. Sorry. That should be milliseconds. >> > > >> > > > its now() arguments, and now got 'undefined' instead >> > > > of {MegaSec,Sec,MicroSec) as second argumnent. >> > > > >> > > > 'undefined' must be a leftover from an unfinished implementation >> > > > of either the case when you have timed out or when the >> > > > timeout is 'infinity'. Nevertheless it is incorrect. >> > > > >> > > > The Timeout variable is how long time still remains to wait of the >> > > > initial user interface timeout. >> > > > >> > > > > >> > > > > Maybe I'm missing something or my coffee doesn't work :) >> > > > > >> > > : : >> > > > > Follow me on twitter >> > > > > @spawn_think >> > > > >> > > > -- >> > > > >> > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB >> > > > _______________________________________________ >> > > > 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 >> > > >> > >> > >> > >> > -- >> > Best Regards, >> > - Ahmed Omar >> > http://nl.linkedin.com/in/adiaa >> > Follow me on twitter >> > @spawn_think >> >> -- >> >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Wed Apr 13 15:38:30 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 13 Apr 2011 15:38:30 +0200 Subject: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 Message-ID: <4DA5A756.10907@trifork.com> To reproduce: $ erl Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) [snip] 6> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], lists:seq(1,32))). <<>> 7> size(v(-1)). 0 8> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], lists:seq(1,31))). HUGE size (8589934632) Aborted -- So, length 2^31 aborts the VM while 2^32 "simply" returns a wrong result. For size 2^31, I hypothesized that something went wrong when Eshell memorizes the result, but that does not appear to be the case: erik@REDACTED:riak_kv-basho$ erl Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) 1> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], lists:seq(1,31))), ok. HUGE size (8589934632) Aborted These tests were run on: $ uname -a Linux flitwick 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11 19:18:05 UTC 2011 x86_64 GNU/Linux /Erik From paul.joseph.davis@REDACTED Wed Apr 13 16:28:17 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 13 Apr 2011 10:28:17 -0400 Subject: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 In-Reply-To: <4DA5A756.10907@trifork.com> References: <4DA5A756.10907@trifork.com> Message-ID: On Wed, Apr 13, 2011 at 9:38 AM, Erik S?e S?rensen wrote: > To reproduce: > > ? $ erl > ? Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] > ? [async-threads:0] [kernel-poll:false] > > ? Eshell V5.8.1 ?(abort with ^G) > ? [snip] > ? 6> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > ? lists:seq(1,32))). > ? <<>> > ? 7> > ? size(v(-1)). > ? ? ? 0 > ? 8> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > ? lists:seq(1,31))). > ? HUGE size (8589934632) > ? Aborted > > > -- So, length 2^31 aborts the VM while 2^32 "simply" returns a wrong result. > > For size 2^31, I hypothesized that something went wrong when Eshell > memorizes the result, but that does not appear to be the case: > > ? erik@REDACTED:riak_kv-basho$ erl > ? Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] > ? [async-threads:0] [kernel-poll:false] > > ? Eshell V5.8.1 ?(abort with ^G) > ? 1> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > ? lists:seq(1,31))), ok. > ? HUGE size (8589934632) > ? Aborted > > These tests were run on: > $ uname -a > Linux flitwick 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11 19:18:05 UTC 2011 > x86_64 GNU/Linux > > > /Erik > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > My guess is that this is that your lists are recursive. Try changing: fun(_,A) -> [A|A] end into: fun(V,A) -> [V|A] end From ess@REDACTED Wed Apr 13 17:17:01 2011 From: ess@REDACTED (=?iso-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 13 Apr 2011 17:17:01 +0200 Subject: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 Message-ID: <80271EA3-347C-42F2-80A6-BF717ED1DA27@trifork.com> That would defeat the purpose of testing how iolist_to_binary handles large outputs though... :-) ----- Reply message ----- Fra: "Paul Davis" Dato: ons., apr. 13, 2011 16:28 Emne: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 Til: "Erik S?e S?rensen" Cc: "erlang-bugs@REDACTED" On Wed, Apr 13, 2011 at 9:38 AM, Erik S?e S?rensen wrote: > To reproduce: > > $ erl > Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] > [async-threads:0] [kernel-poll:false] > > Eshell V5.8.1 (abort with ^G) > [snip] > 6> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > lists:seq(1,32))). > <<>> > 7> > size(v(-1)). > 0 > 8> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > lists:seq(1,31))). > HUGE size (8589934632) > Aborted > > > -- So, length 2^31 aborts the VM while 2^32 "simply" returns a wrong result. > > For size 2^31, I hypothesized that something went wrong when Eshell > memorizes the result, but that does not appear to be the case: > > erik@REDACTED:riak_kv-basho$ erl > Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] > [async-threads:0] [kernel-poll:false] > > Eshell V5.8.1 (abort with ^G) > 1> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], > lists:seq(1,31))), ok. > HUGE size (8589934632) > Aborted > > These tests were run on: > $ uname -a > Linux flitwick 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11 19:18:05 UTC 2011 > x86_64 GNU/Linux > > > /Erik > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > My guess is that this is that your lists are recursive. Try changing: fun(_,A) -> [A|A] end into: fun(V,A) -> [V|A] end From paul.joseph.davis@REDACTED Wed Apr 13 17:47:31 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 13 Apr 2011 11:47:31 -0400 Subject: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 In-Reply-To: <80271EA3-347C-42F2-80A6-BF717ED1DA27@trifork.com> References: <80271EA3-347C-42F2-80A6-BF717ED1DA27@trifork.com> Message-ID: On Wed, Apr 13, 2011 at 11:17 AM, Erik S?e S?rensen wrote: > > > That would defeat the purpose of testing how iolist_to_binary handles large outputs though... :-) > > ----- Reply message ----- > Fra: "Paul Davis" > Dato: ons., apr. 13, 2011 16:28 > Emne: [erlang-bugs] io_list_to_binary returns wrong result for iolist of length 2^32 > Til: "Erik S?e S?rensen" > Cc: "erlang-bugs@REDACTED" > > On Wed, Apr 13, 2011 at 9:38 AM, Erik S?e S?rensen wrote: >> To reproduce: >> >> ? $ erl >> ? Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] >> ? [async-threads:0] [kernel-poll:false] >> >> ? Eshell V5.8.1 ?(abort with ^G) >> ? [snip] >> ? 6> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], >> ? lists:seq(1,32))). >> ? <<>> >> ? 7> >> ? size(v(-1)). >> ? ? ? 0 >> ? 8> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], >> ? lists:seq(1,31))). >> ? HUGE size (8589934632) >> ? Aborted >> >> >> -- So, length 2^31 aborts the VM while 2^32 "simply" returns a wrong result. >> >> For size 2^31, I hypothesized that something went wrong when Eshell >> memorizes the result, but that does not appear to be the case: >> >> ? erik@REDACTED:riak_kv-basho$ erl >> ? Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] >> ? [async-threads:0] [kernel-poll:false] >> >> ? Eshell V5.8.1 ?(abort with ^G) >> ? 1> iolist_to_binary(lists:foldl(fun(_,A) -> [A|A] end, [64], >> ? lists:seq(1,31))), ok. >> ? HUGE size (8589934632) >> ? Aborted >> >> These tests were run on: >> $ uname -a >> Linux flitwick 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11 19:18:05 UTC 2011 >> x86_64 GNU/Linux >> >> >> /Erik >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > My guess is that this is that your lists are recursive. Try changing: > > fun(_,A) -> [A|A] end > > into: > > fun(V,A) -> [V|A] end > Touch?. I can confirm that I'm getting the same results with R14B on OS X 10.6.7. From raimo+erlang-bugs@REDACTED Thu Apr 14 14:34:20 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 14 Apr 2011 14:34:20 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110412114605.GB6292@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <4DA433C6.9050908@gmail.com> <20110412114605.GB6292@erix.ericsson.se> Message-ID: <20110414123420.GA29368@erix.ericsson.se> On Tue, Apr 12, 2011 at 01:46:05PM +0200, Raimo Niskanen wrote: > On Tue, Apr 12, 2011 at 09:13:10PM +1000, Evgeniy Khramtsov wrote: > > 12.04.2011 20:30, Raimo Niskanen wrote: > > > > > >You must have called inet_res:getbyname(Name, Type, infinity), > > >and that was apparently not tested. The functions that calculate > > >the remaining time for do_udp_recv/5 are not written for a timeout of > > >'infinity' and crash for the subtraction of Now - 'undefined'. > > > > > > > Strange. There is inet_res:getbyname(String, srv, 10000) actually. > > Sorry, I misread the condition in the code. To get to where your stacktrace > tells me the value of Timeout to inet_res:do_udp_receive/5 must be 0. > > Then it seems the code accidentally loops exactly when 0 milliseconds > remain to wait for the whole user interface timeout. If a lower level > timeout of 5 seconds (which sounds familiar) is involved, then > two such UDP timeouts could make the code loop after exactly > 10 seconds and get a rest timeout of 0 ms. > > Try a timeout value of 11111 ms instead. That was rubbish. A long enough timeout seems to be necessary. > > If this guess is correct the bug is more serious than I first assumed. New findings ============ There are two timeout values involved, plus a retry limit. The UDP query timeout values are 2 s and 3 retries. The 3:rd argument to inet_res:getbyname/3 is a timeout limit for that call. It sets an upper limit to the UDP query timeout and retry procedure. If you do not use that 3:rd argument, or set it to 'infinity', the call will timeout anyway after all queries have timed out. They will timeout as follows, from the man page for inet_res: For UDP queries, the resolver options timeout and retry control retransmission. Each nameserver in the nameservers list is tried with a timeout of timeout / retry. Then all nameservers are tried again doubling the timeout, for a total of retry times. So, for default values for UDP query timeouts, it will take (666 + 1333 + 2666) = 4665 ms per nameserver for the whole call to timeout. If any servers are unreachable (ECONNREFUSED, ENETUNREACH) this will decrease the time since such a server is discarded after the first failure. If inet_res has to retry with TCP the time might increase since a timeout value of 5 * (UDP query timeout) is used for every TCP query. Anyway, if you use a 3:rd argument to inet_res that forces it to cut the last UDP query to timeout 0, there is a bug that is triggered by an incoming UDP reply at that late time. Example: For 3 nameservers a 3:rd argument timeout of less than 3 * (666 + 1333) + (3 - 1) * 2666 = 11329 ms combined with an UDP reply arriving so late it is received by the last gen_udp:recv, with timeout 0, will trigger this bug. I have not yet managed to reproduce it and am not sure it is possible with certanity, so this conclusion still might be wrong. Since it seems to be possible to avoid the bug with a long enough timeout value it is not very serious. I am nevertheless rewriting the code and fix the bug to become more confident that it works. > > > > > -- > > Regards, > > Evgeniy Khramtsov, ProcessOne. > > xmpp:xram@REDACTED > > > > _______________________________________________ > > 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Fri Apr 15 10:01:35 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 15 Apr 2011 10:01:35 +0200 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110414123420.GA29368@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <4DA433C6.9050908@gmail.com> <20110412114605.GB6292@erix.ericsson.se> <20110414123420.GA29368@erix.ericsson.se> Message-ID: <20110415080135.GA9319@erix.ericsson.se> Hi. I now have reworked the code. It of course passes our regression tests, but since I have not yet managed to reproduce your bug it would be nice if you could test it. I pushed a branch rn/inet_res-crash-rest-time-0 to my github repository git://github.com/RaimoNiskanen/otp.git from where it can be fetched. The branch has two commits to inet_res.erl. http://github.com/RaimoNiskanen/otp/tree/rn/inet_res-crash-rest-time-0 * Check return values from UDP send functions http://github.com/RaimoNiskanen/otp/commit/24f13b771e84b4baad3fb804e14e85478432e289 * Cleanup timeout handling, fix bug for remaining time =:= 0 http://github.com/RaimoNiskanen/otp/commit/684c8ea15059093d25d9c97c21bf1db091579f08 If it is awkward for you to build from source, and you run R14B02 I have placed the VM executable at http://erlang.org/~raimo/inet_res.beam that you can drop into your erlang installation. Be sure to keep the old around just in case I messed something up... Please report your test results... / Raimo On Thu, Apr 14, 2011 at 02:34:20PM +0200, Raimo Niskanen wrote: > On Tue, Apr 12, 2011 at 01:46:05PM +0200, Raimo Niskanen wrote: > > On Tue, Apr 12, 2011 at 09:13:10PM +1000, Evgeniy Khramtsov wrote: > > > 12.04.2011 20:30, Raimo Niskanen wrote: > > > > > > > >You must have called inet_res:getbyname(Name, Type, infinity), > > > >and that was apparently not tested. The functions that calculate > > > >the remaining time for do_udp_recv/5 are not written for a timeout of > > > >'infinity' and crash for the subtraction of Now - 'undefined'. > > > > > > > > > > Strange. There is inet_res:getbyname(String, srv, 10000) actually. > > > > Sorry, I misread the condition in the code. To get to where your stacktrace > > tells me the value of Timeout to inet_res:do_udp_receive/5 must be 0. > > > > Then it seems the code accidentally loops exactly when 0 milliseconds > > remain to wait for the whole user interface timeout. If a lower level > > timeout of 5 seconds (which sounds familiar) is involved, then > > two such UDP timeouts could make the code loop after exactly > > 10 seconds and get a rest timeout of 0 ms. > > > > Try a timeout value of 11111 ms instead. > > That was rubbish. A long enough timeout seems to be necessary. > > > > > If this guess is correct the bug is more serious than I first assumed. > > New findings > ============ > > There are two timeout values involved, plus a retry limit. > > The UDP query timeout values are 2 s and 3 retries. > > The 3:rd argument to inet_res:getbyname/3 is a timeout limit for that call. > It sets an upper limit to the UDP query timeout and retry procedure. > > If you do not use that 3:rd argument, or set it to 'infinity', the call will > timeout anyway after all queries have timed out. They will timeout > as follows, from the man page for inet_res: > > For UDP queries, the resolver options timeout and retry control > retransmission. Each nameserver in the nameservers list is tried with > a timeout of timeout / retry. Then all nameservers are tried again > doubling the timeout, for a total of retry times. > > So, for default values for UDP query timeouts, it will take > (666 + 1333 + 2666) = 4665 ms per nameserver for the whole call to timeout. > If any servers are unreachable (ECONNREFUSED, ENETUNREACH) this will > decrease the time since such a server is discarded after the first failure. > If inet_res has to retry with TCP the time might increase since a timeout > value of 5 * (UDP query timeout) is used for every TCP query. > > Anyway, if you use a 3:rd argument to inet_res that forces it to cut > the last UDP query to timeout 0, there is a bug that is triggered > by an incoming UDP reply at that late time. > > Example: For 3 nameservers a 3:rd argument timeout of less than > 3 * (666 + 1333) + (3 - 1) * 2666 = 11329 ms combined with an UDP reply > arriving so late it is received by the last gen_udp:recv, with timeout 0, > will trigger this bug. > > I have not yet managed to reproduce it and am not sure it is possible > with certanity, so this conclusion still might be wrong. > > Since it seems to be possible to avoid the bug with a long enough > timeout value it is not very serious. I am nevertheless rewriting > the code and fix the bug to become more confident that it works. > > > > > > > > > -- > > > Regards, > > > Evgeniy Khramtsov, ProcessOne. > > > xmpp:xram@REDACTED > > > > > > _______________________________________________ > > > 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 > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From xramtsov@REDACTED Fri Apr 15 13:34:33 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Fri, 15 Apr 2011 21:34:33 +1000 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <20110415080135.GA9319@erix.ericsson.se> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <4DA433C6.9050908@gmail.com> <20110412114605.GB6292@erix.ericsson.se> <20110414123420.GA29368@erix.ericsson.se> <20110415080135.GA9319@erix.ericsson.se> Message-ID: <4DA82D49.2090002@gmail.com> 15.04.2011 18:01, Raimo Niskanen wrote: > Hi. > > I now have reworked the code. It of course passes our regression tests, > but since I have not yet managed to reproduce your bug it would be > nice if you could test it. I pushed a branch rn/inet_res-crash-rest-time-0 > to my github repository git://github.com/RaimoNiskanen/otp.git from > where it can be fetched. The branch has two commits to inet_res.erl. > > http://github.com/RaimoNiskanen/otp/tree/rn/inet_res-crash-rest-time-0 > * Check return values from UDP send functions > http://github.com/RaimoNiskanen/otp/commit/24f13b771e84b4baad3fb804e14e85478432e289 > * Cleanup timeout handling, fix bug for remaining time =:= 0 > http://github.com/RaimoNiskanen/otp/commit/684c8ea15059093d25d9c97c21bf1db091579f08 > > If it is awkward for you to build from source, and you run R14B02 > I have placed the VM executable at http://erlang.org/~raimo/inet_res.beam > that you can drop into your erlang installation. Be sure to keep > the old around just in case I messed something up... > > Please report your test results... Thank you very much. I'm trying your beam (I have R14B02 installed). By the way, the problem is rare, so it can take a day to catch the error on heavily loaded machines. I'll report the result. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From lcastro@REDACTED Fri Apr 15 17:31:40 2011 From: lcastro@REDACTED (Laura M. Castro) Date: Fri, 15 Apr 2011 17:31:40 +0200 Subject: [erlang-bugs] ODBC problem: varchar column contents truncated to 255 chars Message-ID: Hello, When accessing a data source using the ODBC application, retrieved contents of columns with type 'varchar' are truncated to 255 chars. Here's an example: PostgreSQL table 'prueba': postgres=# \d prueba Table "public.prueba" Column | Type | Modifiers -------------+-------------------+----------- oid | integer | description | character varying | Table 'prueba' contains a single row, which 'description' field is 300 chars long: postgres=# select * from prueba; oid | description -----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (1 row) But when the field is retrieved using Erlang+ODBC, only 255 chars are returned: Erlang R14A (erts-5.8) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8 (abort with ^G) 1> application:start(odbc). ok 2> {ok,C}=odbc:connect("DSN=postgres",[]). {ok,<0.39.0>} 3> {selected, Columns, [{ID, LongString}]} = odbc:sql_query(C, "SELECT * FROM prueba"). {selected,["oid","description"], [{3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]} 4> length(LongString). 255 Accessing the same data source using other tools that also use the underlying ODBC driver (unixODBC), such as Squirrel-SQL or OpenOffice Base, data is retrieved correctly. I have reproduced this behaviour on the following environments: Debian GNU/Linux 2.6.38-2-amd64 #1 SMP x86_64 GNU/Linux Erlang R14A (SMP,ASYNC_THREADS) (BEAM) emulator version 5.8 unixODBC 2.2.14p2-2 Ubuntu GNU/Linux 2.6.35-28-generic #49-Ubuntu SMP x86_64 GNU/Linux Erlang R13B03 (SMP,ASYNC_THREADS,HIPE) (BEAM) emulator version 5.7.4 unixODBC 2.2.14p2-1ubuntu1 Red Hat Linux 5 2.6.18-164.el5 #1 SMP i686 i386 GNU/Linux Erlang R12B-5.6.el5.1 (ASYNC_THREADS,HIPE) (BEAM) emulator version 5.6.5 unixODBC 2.2.11-7.1 Red Hat Linux 2.6.18-194.11.1.el5 #1 SMP i686 i386 GNU/Linux Erlang R12B-5.6.el5.1 (THREADS,HIPE) (BEAM) emulator version 5.4.9 unixODBC 2.2.11-7.1 -- Laura M. Castro Department of Computer Science University of A Coru?a http://www.madsgroup.org/staff/laura From michael.santos@REDACTED Sat Apr 16 00:40:30 2011 From: michael.santos@REDACTED (Michael Santos) Date: Fri, 15 Apr 2011 18:40:30 -0400 Subject: [erlang-bugs] ODBC problem: varchar column contents truncated to 255 chars In-Reply-To: References: Message-ID: <20110415224030.GA23966@ecn.lan> On Fri, Apr 15, 2011 at 05:31:40PM +0200, Laura M. Castro wrote: > Hello, > > When accessing a data source using the ODBC application, retrieved > contents of columns with type 'varchar' are truncated to 255 chars. > Here's an example: > > PostgreSQL table 'prueba': > > postgres=# \d prueba > Table "public.prueba" > Column | Type | Modifiers > -------------+-------------------+----------- > oid | integer | > description | character varying | > > Table 'prueba' contains a single row, which 'description' field is > 300 chars long: > > postgres=# select * from prueba; > oid | > > description > -----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > 1 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > (1 row) > > But when the field is retrieved using Erlang+ODBC, only 255 chars > are returned: > > Erlang R14A (erts-5.8) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [kernel-poll:false] > Eshell V5.8 (abort with ^G) > 1> application:start(odbc). > ok > 2> {ok,C}=odbc:connect("DSN=postgres",[]). > {ok,<0.39.0>} > 3> {selected, Columns, [{ID, LongString}]} = odbc:sql_query(C, "SELECT > * FROM prueba"). > {selected,["oid","description"], > [{3, > "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]} > 4> length(LongString). > 255 > > Accessing the same data source using other tools that also use the > underlying ODBC driver (unixODBC), such as Squirrel-SQL or OpenOffice > Base, data is retrieved correctly. Works for me with R14B02. dpkg says I'm using unixodbc 2.2.11-16build1 and odbc-postgresql 1:08.01.0200-2.1. Maybe casting the varchar to text is a workaround: odbc:sql_query(C, "SELECT description::text FROM prueba"). or: odbc:sql_query(C, "SELECT CAST(description as TEXT) FROM prueba"). From lcastro@REDACTED Sat Apr 16 12:03:55 2011 From: lcastro@REDACTED (Laura M. Castro) Date: Sat, 16 Apr 2011 12:03:55 +0200 Subject: [erlang-bugs] ODBC problem: varchar column contents truncated to 255 chars In-Reply-To: <20110415224030.GA23966@ecn.lan> References: <20110415224030.GA23966@ecn.lan> Message-ID: Hello, > Maybe casting the varchar to text is a workaround: > > odbc:sql_query(C, "SELECT description::text FROM prueba"). > > or: > > odbc:sql_query(C, "SELECT CAST(description as TEXT) FROM prueba"). Thank you so much for the workaround! It works both ways. Deeply appreciated, -- Laura M. Castro Department of Computer Science University of A Coru?a http://www.madsgroup.org/staff/laura From erlangsiri@REDACTED Mon Apr 18 09:19:10 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Mon, 18 Apr 2011 09:19:10 +0200 Subject: [erlang-bugs] Reltool and code clash In-Reply-To: References: Message-ID: Hi Andrew! Thank you for reporting this. I will look into it for the coming release. Regards /siri@REDACTED 2011/4/11 Andrew Gopienko > In case of code clash between applications reltool skips beam files in > generated release. > > I have Tsung installed under /usr/local/lib/erlang/lib and > my release directory (rebar based) with mochiweb application. > Tsung and mochiweb have same beams - mochijson2, mochinum, > mochiweb_charref, mochiweb_html. > Key fragment of reltool.config > {app, mochiweb, [{incl_cond, include}]}, > {app, 'tsung-1.4.0a', [{incl_cond, exclude}]}, > > For such configuration reltool generates release in which there are no > files > mochijson2.beam, mochinum.beam, mochiweb_charref.beam, mochiweb_html.beam > in mochiweb application. > > I think, in this situation, reltool can return an error or using the hint > {incl_cond, exclude} to generate the proper release spec. > > > Andrew Gopienko > ThreeLine LLC > trxline.ru > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xramtsov@REDACTED Mon Apr 18 12:46:43 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Mon, 18 Apr 2011 20:46:43 +1000 Subject: [erlang-bugs] Bug in the resolver? In-Reply-To: <4DA82D49.2090002@gmail.com> References: <4DA3F051.2000303@gmail.com> <20110412103007.GA2965@erix.ericsson.se> <4DA433C6.9050908@gmail.com> <20110412114605.GB6292@erix.ericsson.se> <20110414123420.GA29368@erix.ericsson.se> <20110415080135.GA9319@erix.ericsson.se> <4DA82D49.2090002@gmail.com> Message-ID: <4DAC1693.5080709@gmail.com> 15.04.2011 21:34, Evgeniy Khramtsov wrote: > 15.04.2011 18:01, Raimo Niskanen wrote: >> Hi. >> >> I now have reworked the code. It of course passes our regression tests, >> but since I have not yet managed to reproduce your bug it would be >> nice if you could test it. I pushed a branch >> rn/inet_res-crash-rest-time-0 >> to my github repository git://github.com/RaimoNiskanen/otp.git from >> where it can be fetched. The branch has two commits to inet_res.erl. >> >> >> http://github.com/RaimoNiskanen/otp/tree/rn/inet_res-crash-rest-time-0 >> * Check return values from UDP send functions >> >> http://github.com/RaimoNiskanen/otp/commit/24f13b771e84b4baad3fb804e14e85478432e289 >> >> * Cleanup timeout handling, fix bug for remaining time =:= 0 >> >> http://github.com/RaimoNiskanen/otp/commit/684c8ea15059093d25d9c97c21bf1db091579f08 >> >> >> If it is awkward for you to build from source, and you run R14B02 >> I have placed the VM executable at >> http://erlang.org/~raimo/inet_res.beam >> that you can drop into your erlang installation. Be sure to keep >> the old around just in case I messed something up... >> >> Please report your test results... > > Thank you very much. I'm trying your beam (I have R14B02 installed). > By the way, the problem is rare, so it can take a day to catch the > error on heavily loaded machines. I'll report the result. > Ok, 3 days left and we got no errors with the new beam. So I think your patch solves the problem. Thank you very much! -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From xramtsov@REDACTED Mon Apr 25 13:03:23 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Mon, 25 Apr 2011 21:03:23 +1000 Subject: [erlang-bugs] lists:delete on tmp supervisors Message-ID: <4DB554FB.2050004@gmail.com> Temporary supervisors use lists to keep the children data, and, thus are extremely slow when there are lots of children added/deleted. I've noticed a huge message queue overload on stress tests with current_function being lists:delete. Is it a bug or a feature? It seems like it was introduced recently, at least the issue presents in R14B02. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From xramtsov@REDACTED Wed Apr 27 05:39:20 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Wed, 27 Apr 2011 13:39:20 +1000 Subject: [erlang-bugs] lists:delete on tmp supervisors In-Reply-To: <4DB554FB.2050004@gmail.com> References: <4DB554FB.2050004@gmail.com> Message-ID: <4DB78FE8.6040807@gmail.com> 25.04.2011 21:03, Evgeniy Khramtsov wrote: > Temporary supervisors use lists to keep the children data, and, thus > are extremely slow when there are lots of children added/deleted. I've > noticed a huge message queue overload on stress tests with > current_function being lists:delete. > > Is it a bug or a feature? It seems like it was introduced recently, at > least the issue presents in R14B02. > A simple patch against the 'dev' branch is attached. If you are not convenient with sets, you can try gb_sets (since the former consumes a bit more memory). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: supervisor-tmp-lists.patch Type: text/x-diff Size: 3093 bytes Desc: not available URL: From erlangsiri@REDACTED Wed Apr 27 12:02:26 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 27 Apr 2011 12:02:26 +0200 Subject: [erlang-bugs] lists:delete on tmp supervisors In-Reply-To: <4DB78FE8.6040807@gmail.com> References: <4DB554FB.2050004@gmail.com> <4DB78FE8.6040807@gmail.com> Message-ID: Hello Evgeniy! Thank you for this contribution. The list representation was introduced by a correction that was done in R14B02, where it was decided not to save the initial arguments for dynamic temporary processes. Thus the original dict was no longer needed for this type of processes, and a list was used instead. I think your patch is a good improvement. I will try to fit it into the coming release. Regards /siri 2011/4/27 Evgeniy Khramtsov > 25.04.2011 21:03, Evgeniy Khramtsov wrote: > >> Temporary supervisors use lists to keep the children data, and, thus are >> extremely slow when there are lots of children added/deleted. I've noticed a >> huge message queue overload on stress tests with current_function being >> lists:delete. >> >> Is it a bug or a feature? It seems like it was introduced recently, at >> least the issue presents in R14B02. >> >> > A simple patch against the 'dev' branch is attached. If you are not > convenient with sets, you can try gb_sets (since the former consumes a bit > more memory). > > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Wed Apr 27 21:45:56 2011 From: matthias@REDACTED (Matthias Lang) Date: Wed, 27 Apr 2011 21:45:56 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) Message-ID: <20110427194556.GA3947@corelatus.se> Hi, This is not an Erlang bug, but rather a gcc bug tripped by building Erlang. Building R14B02 on an x86-64 machine with gcc 4.5.2 (Debian "testing") fails partway through with: beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. This looks like GCC bugs 48000 and 48060, though I'm not sure if they apply to 4.5.2 or only to 4.6: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 I worked around it by using gcc 4.4 instead. Matt From mikpe@REDACTED Thu Apr 28 00:23:39 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 28 Apr 2011 00:23:39 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <20110427194556.GA3947@corelatus.se> References: <20110427194556.GA3947@corelatus.se> Message-ID: <19896.38763.587926.218428@pilspetsen.it.uu.se> Matthias Lang writes: > Hi, > > This is not an Erlang bug, but rather a gcc bug tripped by building Erlang. > > Building R14B02 on an x86-64 machine with gcc 4.5.2 (Debian "testing") > fails partway through with: > > beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. I'm unable to reproduce this with either gcc-4.5.2 or gcc-4.5-20110421, both vanilla unpatched FSF sources, on an x86-64 box running Fedora 13. Looks like a Debian bug to me. From matthias@REDACTED Thu Apr 28 07:43:49 2011 From: matthias@REDACTED (Matthias Lang) Date: Thu, 28 Apr 2011 07:43:49 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <19896.38763.587926.218428@pilspetsen.it.uu.se> References: <20110427194556.GA3947@corelatus.se> <19896.38763.587926.218428@pilspetsen.it.uu.se> Message-ID: <20110428054348.GA2303@corelatus.se> Hi, > I'm unable to reproduce this with either gcc-4.5.2 or gcc-4.5-20110421, > both vanilla unpatched FSF sources, on an x86-64 box running Fedora 13. > Looks like a Debian bug to me. Thanks, agree. I glanced at Debian's patches, but they're 200k lines long. Did not feel like digging through that to try and understand what they've done. Feels like "report and forget" time. Anything more than the rest of this mail I should send to Debian? -------------------- gcc -v: gcc version 4.5.2 (Debian 4.5.2-11) uname -a: Linux contorpis.corelatus.se 2.6.38-2-amd64 #1 SMP Thu Apr 7 04:28:07 UTC 2011 x86_64 GNU/Linux how to reproduce: cd /tmp wget www.corelatus.se/~matthias/preprocessed.i gcc -O3 -c preprocessed.i here's what it looks like on my machine: > gcc -O3 -c preprocessed.i beam/dist.c: In function ?erts_do_net_exits?: beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. MD5: 616c74a08f57cb9263a9af62d845fb19 preprocessed.i Problem does not occur with "gcc version 4.4.5 (Debian 4.4.5-15)" Can't find a similar problem at bugs.debian.org. Similar problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 Matt From mikpe@REDACTED Thu Apr 28 09:29:26 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 28 Apr 2011 09:29:26 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <20110428054348.GA2303@corelatus.se> References: <20110427194556.GA3947@corelatus.se> <19896.38763.587926.218428@pilspetsen.it.uu.se> <20110428054348.GA2303@corelatus.se> Message-ID: <19897.5974.659362.789149@pilspetsen.it.uu.se> Matthias Lang writes: > Hi, > > > I'm unable to reproduce this with either gcc-4.5.2 or gcc-4.5-20110421, > > both vanilla unpatched FSF sources, on an x86-64 box running Fedora 13. > > Looks like a Debian bug to me. > > Thanks, agree. > > I glanced at Debian's patches, but they're 200k lines long. Did not > feel like digging through that to try and understand what they've > done. Feels like "report and forget" time. > > Anything more than the rest of this mail I should send to Debian? > > -------------------- > > gcc -v: gcc version 4.5.2 (Debian 4.5.2-11) This bit looks incomplete. 'gcc -v' normally includes a list of configuration options, that sometimes do matter. Of course, Debian should know what "4.5.2-11" means exactly, so it may not matter. It would matter for bug reports to FSF GCC. Apart from that, the bug report looks complete. > > uname -a: Linux contorpis.corelatus.se 2.6.38-2-amd64 #1 SMP Thu Apr 7 04:28:07 UTC 2011 x86_64 GNU/Linux > > how to reproduce: > > cd /tmp > wget www.corelatus.se/~matthias/preprocessed.i > gcc -O3 -c preprocessed.i > > here's what it looks like on my machine: > > > gcc -O3 -c preprocessed.i > beam/dist.c: In function ???erts_do_net_exits???: > beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > MD5: 616c74a08f57cb9263a9af62d845fb19 preprocessed.i > > Problem does not occur with "gcc version 4.4.5 (Debian 4.4.5-15)" > > Can't find a similar problem at bugs.debian.org. > Similar problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 > > Matt > From erlang@REDACTED Thu Apr 28 10:35:32 2011 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 28 Apr 2011 10:35:32 +0200 Subject: [erlang-bugs] bug: missing warning statement Message-ID: %% How come no warnings for functions a .. c. %% I'd expected a warning as in d -module(bug). -compile(export_all). -define(IS_DIGIT(X),($0= a; a("0x" ++ _) -> b. b([X|_]) when $0= a; b("0x" ++ _) -> b. c([X|_]) when X == $0 -> a; c("0x" ++ _) -> b. d([$0|_]) -> a; d("0x" ++ _) -> b. %% erlc bug.erl %% ./bug.erl:16: Warning: this clause cannot match because a previous clause at line 15 always matches /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Apr 28 11:03:33 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 28 Apr 2011 12:03:33 +0300 Subject: [erlang-bugs] bug: missing warning statement In-Reply-To: References: Message-ID: <4DB92D65.5010802@cs.ntua.gr> Joe Armstrong wrote: > %% How come no warnings for functions a .. c. > %% I'd expected a warning as in d > > -module(bug). > -compile(export_all). > > -define(IS_DIGIT(X),($0= > a([X|_]) when ?IS_DIGIT(X) -> a; > a("0x" ++ _) -> b. > > b([X|_]) when $0= a; > b("0x" ++ _) -> b. > > c([X|_]) when X == $0 -> a; > c("0x" ++ _) -> b. > > d([$0|_]) -> a; > d("0x" ++ _) -> b. > > > %% erlc bug.erl > %% ./bug.erl:16: Warning: this clause cannot match because a previous > clause at line 15 always matches Somebody designed the ==, =<, etc. operators to have very weird semantics Joe :-), and not be equivalent to matching (i.e., exact arithmetic equality), as in the last case. I suppose the compiler could be a bit more clever and have some simple logic e.g. that Var == Integer implies Var =:= Integer, but apparently this is not there yet. (The logic needed for intervals is even more involved, I am afraid.) But I agree with you that it would be nice for the compiler to generate warnings for some/all of these cases. Cheers, Kostis From rapsey@REDACTED Thu Apr 28 12:00:08 2011 From: rapsey@REDACTED (Rapsey) Date: Thu, 28 Apr 2011 12:00:08 +0200 Subject: [erlang-bugs] filename:split does not work for windows paths anymore Message-ID: In R14B02 copy paste example from documentation: 55> filename:split("a:\\msdev\\include"). ["a:\\msdev\\include"] >From documentation: 26> filename:split("a:\\msdev\\include"). ["a:/","msdev","include"] Sergej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rapsey@REDACTED Thu Apr 28 12:06:44 2011 From: rapsey@REDACTED (Rapsey) Date: Thu, 28 Apr 2011 12:06:44 +0200 Subject: [erlang-bugs] filename:split does not work for windows paths anymore In-Reply-To: References: Message-ID: Or is it because I ran it on OSX and not windows? :) Thats probably it. Sergej On Thu, Apr 28, 2011 at 12:00 PM, Rapsey wrote: > In R14B02 copy paste example from documentation: > > 55> filename:split("a:\\msdev\\include"). > ["a:\\msdev\\include"] > > From documentation: > 26> filename:split("a:\\msdev\\include"). > ["a:/","msdev","include"] > > > > > Sergej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Thu Apr 28 12:11:13 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 28 Apr 2011 12:11:13 +0200 Subject: [erlang-bugs] filename:split does not work for windows paths anymore In-Reply-To: References: Message-ID: Yes, the function checks your OS first to decide which split function to use, i suggest the documentation should clarify that On Thu, Apr 28, 2011 at 12:06 PM, Rapsey wrote: > Or is it because I ran it on OSX and not windows? :) > Thats probably it. > > > Sergej > > > On Thu, Apr 28, 2011 at 12:00 PM, Rapsey wrote: > >> In R14B02 copy paste example from documentation: >> >> 55> filename:split("a:\\msdev\\include"). >> ["a:\\msdev\\include"] >> >> From documentation: >> 26> filename:split("a:\\msdev\\include"). >> ["a:/","msdev","include"] >> >> >> >> >> Sergej >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Apr 28 14:06:26 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 28 Apr 2011 14:06:26 +0200 Subject: [erlang-bugs] lists:delete on tmp supervisors In-Reply-To: <4DB554FB.2050004@gmail.com> References: <4DB554FB.2050004@gmail.com> Message-ID: Hi Evgeniy - could you just give a short description of your stress tests and how many processes are added/deleted? Thanks! /siri 2011/4/25 Evgeniy Khramtsov > Temporary supervisors use lists to keep the children data, and, thus are > extremely slow when there are lots of children added/deleted. I've noticed a > huge message queue overload on stress tests with current_function being > lists:delete. > > Is it a bug or a feature? It seems like it was introduced recently, at > least the issue presents in R14B02. > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xramtsov@REDACTED Thu Apr 28 14:18:18 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Thu, 28 Apr 2011 22:18:18 +1000 Subject: [erlang-bugs] lists:delete on tmp supervisors In-Reply-To: References: <4DB554FB.2050004@gmail.com> Message-ID: <4DB95B0A.40005@gmail.com> 28.04.2011 22:06, Siri Hansen wrote: > Hi Evgeniy - could you just give a short description of your stress tests > and how many processes are added/deleted? > I just attached 50k processes to simple_one_for_one supervisor and then stopped them in the same order: such order guarantees that all deletion will be performed at O(N) when lists is used and thus, it takes O(N^2) to delete all childrens :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From olivier.girondel@REDACTED Sat Apr 30 04:01:21 2011 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Sat, 30 Apr 2011 04:01:21 +0200 Subject: [erlang-bugs] Segmentation fault in R14B02/wxErlang/amd64/debian-sid Message-ID: Hello, I have an application that works just fine with R14B02 on i386 / debian sid, but segfaults on amd64 (same configuration, nothing special in the erlang build): ================================ olivier@REDACTED:~$ cat /etc/debian_version wheezy/sid olivier@REDACTED:~$ uname -a Linux yoda 2.6.38-2-amd64 #1 SMP Sat Apr 23 18:47:49 UTC 2011 x86_64 GNU/Linux olivier@REDACTED:~$ erl Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) ================================ Way to reproduce the bug -alas, not related to my application- 1> wx:demo(). Then click on the "gl" example. Segfaults without a core (even with ulimit -c unlimited and write permissions to the cwd) 1> wx:demo(). {wx_ref,35,wxFrame,<0.34.0>} 2> Segmentation fault Backtrace with gdb (erlang was compiled with -g): ================================ olivier@REDACTED:~$ ./erldbg.sh GNU gdb (GDB) 7.2-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/local/lib/erlang/erts-5.8.3/bin/erlexec...done. (gdb) run Starting program: /usr/local/lib/erlang/erts-5.8.3/bin/erlexec process 4030 is executing new program: /usr/local/lib/erlang/erts-5.8.3/bin/beam.smp [Thread debugging using libthread_db enabled] [New Thread 0x7ffff6b87700 (LWP 4033)] [New Thread 0x7ffff7ff8700 (LWP 4034)] [New Thread 0x7ffff6386700 (LWP 4035)] [New Thread 0x7ffff7fe6700 (LWP 4036)] [New Thread 0x7ffff5a84700 (LWP 4037)] [New Thread 0x7ffff5283700 (LWP 4038)] Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> wx:demo(). [New Thread 0x7fffe560e700 (LWP 4041)] {wx_ref,35,wxFrame,<0.34.0>} 2> Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe560e700 (LWP 4041)] 0x00007fffe27266b0 in ?? () (gdb) bt #0 0x00007fffe27266b0 in ?? () #1 0x00007fffe29719c1 in egl_dispatch (op=5314, bp=0x9d38f0 "", port=0x267, caller=659, bins=, bins_sz=) at gen/gl_funcs.cpp:2206 #2 0x00007fffefc34c8e in gl_dispatch (op=5314, bp=0x9d38e0 "", caller=659, bins=0x7ffff0041dc0) at wxe_gl.cpp:158 #3 0x00007fffefc2facf in WxeApp::dispatch (this=0x9ffbb0, batch=0xa8a900, blevel=1, list_type=0) at wxe_impl.cpp:405 #4 0x00007fffefc2fbd7 in WxeApp::dispatch_cmds (this=0x9ffbb0) at wxe_impl.cpp:359 #5 0x00007fffee589955 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #6 0x00007fffee589d3f in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #7 0x00007fffee589df2 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #8 0x00007fffeea70425 in wxAppBase::ProcessIdle() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #9 0x00007fffee9decf2 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #10 0x00007fffeb83c4a3 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #11 0x00007fffeb83cc80 in ?? () from /lib/libglib-2.0.so.0 #12 0x00007fffeb83d2f2 in g_main_loop_run () from /lib/libglib-2.0.so.0 #13 0x00007fffed5ee2b7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x00007fffee9f3098 in wxEventLoop::Run() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #15 0x00007fffeea701db in wxAppBase::MainLoop() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #16 0x00007fffee5379ac in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0 #17 0x00007fffefc2f47c in wxe_main_loop (vpdl=0x96ee38) at wxe_impl.cpp:227 #18 0x0000000000548e0d in erl_drv_thread_wrapper (vdtid=0x9d3888) at beam/erl_drv_thread.c:117 #19 0x000000000060f573 in thr_wrapper (vtwd=0x7ffff527fec0) at pthread/ethread.c:106 #20 0x00007ffff72f98ba in start_thread (arg=) at pthread_create.c:300 #21 0x00007ffff6e583cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #22 0x0000000000000000 in ?? () (gdb) ================================ The fault may be on my side -if not, what can I do to help debugging this ? -- Olivier / http://biniou.net