From sverker@REDACTED Tue Jun 2 14:09:21 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 02 Jun 2009 14:09:21 +0200 Subject: [erlang-questions] R13B stop_select error In-Reply-To: References: <4A0011BA.6040006@erix.ericsson.se> Message-ID: <4A251671.7040003@erix.ericsson.se> Eugene Letuchy wrote on erlang-questions: > I just discovered the following error in the logs of a production > system (running -smp +K true): > > [May 4 12:42:30 2009] [error] driver_select(0x0000000000099dd0, 158, > ERL_DRV_READ ERL_DRV_WRITE ERL_DRV_USE, 0) by tcp_inet driver > #Port<0.119119312> failed: fd=158 (re)selected before stop_select was > called for driver udp_inet Marc Sugiyama wrote on erlang-questions: > =ERROR REPORT==== 8-May-2009::12:58:56 === > driver_select(0x000000000000ca43, 1289, ERL_DRV_READ ERL_DRV_USE, 1) > by tcp_inet driver #Port<0.313923> failed: fd=1289 (re)selected before > stop_select was called for driver tcp_inet > Bug found. Fix will be included in R13B01. /Sverker, Erlang/OTP, Ericsson From thijsterlouw@REDACTED Wed Jun 3 04:27:25 2009 From: thijsterlouw@REDACTED (Thijs Terlouw) Date: Wed, 3 Jun 2009 10:27:25 +0800 Subject: [erlang-bugs] Re: [erlang-questions] R13B stop_select error In-Reply-To: <4A251671.7040003@erix.ericsson.se> References: <4A0011BA.6040006@erix.ericsson.se> <4A251671.7040003@erix.ericsson.se> Message-ID: <4183f4b90906021927k2d543e95u3fc16ec87423b9fd@mail.gmail.com> Could you elaborate on the effects of this bug? I also have encountered this problem and was wondering if it can cause a problem I have encountered in my application (where the app seems to run fine, but seems not to be processing TCP requests anymore). Is there a public timetable for the release of R13B01? Thijs Terlouw, Tencent On Tue, Jun 2, 2009 at 8:09 PM, Sverker Eriksson wrote: > Eugene Letuchy wrote on erlang-questions: > > I just discovered the following error in the logs of a production >> system (running -smp +K true): >> >> [May 4 12:42:30 2009] [error] driver_select(0x0000000000099dd0, 158, >> ERL_DRV_READ ERL_DRV_WRITE ERL_DRV_USE, 0) by tcp_inet driver >> #Port<0.119119312> failed: fd=158 (re)selected before stop_select was >> called for driver udp_inet >> > > > Marc Sugiyama wrote on erlang-questions: > >> =ERROR REPORT==== 8-May-2009::12:58:56 === >> driver_select(0x000000000000ca43, 1289, ERL_DRV_READ ERL_DRV_USE, 1) >> by tcp_inet driver #Port<0.313923> failed: fd=1289 (re)selected before >> stop_select was called for driver tcp_inet >> >> > > Bug found. Fix will be included in R13B01. > > /Sverker, Erlang/OTP, Ericsson > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From sverker@REDACTED Wed Jun 3 11:23:13 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 03 Jun 2009 11:23:13 +0200 Subject: [erlang-bugs] Re: [erlang-questions] R13B stop_select error In-Reply-To: <4183f4b90906021927k2d543e95u3fc16ec87423b9fd@mail.gmail.com> References: <4A0011BA.6040006@erix.ericsson.se> <4A251671.7040003@erix.ericsson.se> <4183f4b90906021927k2d543e95u3fc16ec87423b9fd@mail.gmail.com> Message-ID: <4A264101.5080107@erix.ericsson.se> Thijs Terlouw wrote: > Could you elaborate on the effects of this bug? I also have encountered this > problem and was wondering if it can cause a problem I have encountered in my > application (where the app seems to run fine, but seems not to be processing > TCP requests anymore). Is there a public timetable for the release of > R13B01? > The bug caused access of freed memory that used to contain general information about file descriptor events for the VM. We have seen different effects of this. I suggest you read the two cases posted in the original thread in erlang-questions: http://www.erlang.org/cgi-bin/ezmlm-cgi?4:sss:43685:200905:pcjfcbbfinlhdllhjhme#b In another case of a paying customer, the bug caused the VM to crash. Your case of "not processing TCP requests anymore", sounds like it very well could be caused by this bug. Especially if you get the error log from driver_select when that happens. The bug does only exist on R13, non-Windows, with SMP-support. R13B01 is scheduled to be released on June 10. /Sverker, Erlang/OTP, Ericsson From thijsterlouw@REDACTED Wed Jun 3 11:53:56 2009 From: thijsterlouw@REDACTED (Thijs Terlouw) Date: Wed, 3 Jun 2009 17:53:56 +0800 Subject: [erlang-bugs] Re: [erlang-questions] R13B stop_select error In-Reply-To: <4A264101.5080107@erix.ericsson.se> References: <4A0011BA.6040006@erix.ericsson.se> <4A251671.7040003@erix.ericsson.se> <4183f4b90906021927k2d543e95u3fc16ec87423b9fd@mail.gmail.com> <4A264101.5080107@erix.ericsson.se> Message-ID: <4183f4b90906030253x1d2600f0i8a22543ed29e3e2d@mail.gmail.com> Thanks for the detailed reply! I have read the original bug reports in the mailing list, but I was not totally sure if the bug you fixed was related to the problems I was seeing. I indeed only started to experience these errors after I switched to R13B (skipped R13A) and we are running Linux with SMP enabled. I've not had problems with crashing VM and the problem has been quite hard to replicate. I'm very happy you resolved this problem. Thanks again and look forward to R13B01 Thijs Terlouw, Tencent On Wed, Jun 3, 2009 at 5:23 PM, Sverker Eriksson wrote: > Thijs Terlouw wrote: > >> Could you elaborate on the effects of this bug? I also have encountered >> this >> problem and was wondering if it can cause a problem I have encountered in >> my >> application (where the app seems to run fine, but seems not to be >> processing >> TCP requests anymore). Is there a public timetable for the release of >> R13B01? >> >> > The bug caused access of freed memory that used to contain general > information about file descriptor events for the VM. We have seen different > effects of this. I suggest you read the two cases posted in the original > thread in erlang-questions: > > > http://www.erlang.org/cgi-bin/ezmlm-cgi?4:sss:43685:200905:pcjfcbbfinlhdllhjhme#b > > In another case of a paying customer, the bug caused the VM to crash. > Your case of "not processing TCP requests anymore", sounds like it very > well could be caused by this bug. Especially if you get the error log from > driver_select when that happens. The bug does only exist on R13, > non-Windows, with SMP-support. > > R13B01 is scheduled to be released on June 10. > > > /Sverker, Erlang/OTP, Ericsson > > > -- Thijs Terlouw, Shenzhen, China http://www.startinchina.com From kruber@REDACTED Wed Jun 3 18:30:59 2009 From: kruber@REDACTED (Nico Kruber) Date: Wed, 3 Jun 2009 18:30:59 +0200 Subject: erlang with newer wxWidgets (>= 2.8.9.1, maybe earlier versions) Message-ID: <200906031831.04769.kruber@zib.de> Erlang's wx integration doesn't compile with newer wxWidgets libraries -> the attached patch solves this similar to the patch applied here: http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/src/html/helpfrm.cpp?r1=36802&r2=37359&pathrev=60639 (as you can see this is fairly old so old versions should still work - tested with wx libs the following distributions supply: Fedora 9,10, Mandriva 2008,2009, SLE 11, openSUSE 11.0,11.1,Factory) Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: otp-R13B-wxe.patch Type: text/x-patch Size: 1604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From anders.nygren@REDACTED Wed Jun 3 19:10:51 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 3 Jun 2009 12:10:51 -0500 Subject: gen_sctp documentation Message-ID: I have started playing with SCTP and found some errors in the documentation When receiving a sctp_paddr_change event - addr is supposed to be an ip_address(), but it is {ip_address(),port()} - state value addr_confirmed is not documented A number of errors in the example code server/0 should be server -> server(any,2006). server/1, ends with a ";" instead of "." server/2 orlese should be orelse sctp_recbuf should be recbuf server_loop/1 io:format("Error: ~p~n", [Data]) should be better as io:format("Received: ~p~n", [Data]) sctp_client.erl missing -include_lib("kernel/include/inet_sctp.hrl"). client/1 should be client([Host]) -> client(Host, 2006). client/1 last clause ends with ";" instead of "." /Anders From anders.nygren@REDACTED Wed Jun 3 19:32:04 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 3 Jun 2009 12:32:04 -0500 Subject: gen_sctp documentation In-Reply-To: References: Message-ID: I forgot this thing also in the sctp_server.erl example {ok,S} = gen_sctp:open([{ip,IP},{port,Port}],[{sctp_recbuf,65536}]), should be {ok,S} = gen_sctp:open([{ip,IP},{port,Port},{recbuf,65536}]), /Anders On Wed, Jun 3, 2009 at 12:10 PM, Anders Nygren wrote: > I have started playing with SCTP and found some errors in the documentation > > When receiving a sctp_paddr_change event > - addr is supposed to be an ip_address(), but it is {ip_address(),port()} > - state value addr_confirmed is not documented > > > A number of errors in the example code > server/0 > should be > server -> > ? ?server(any,2006). > > server/1, ends with a ";" instead of "." > > server/2 > orlese should be orelse > sctp_recbuf should be recbuf > > server_loop/1 > io:format("Error: ~p~n", [Data]) > should be better as > io:format("Received: ~p~n", [Data]) > > > sctp_client.erl > missing > -include_lib("kernel/include/inet_sctp.hrl"). > > client/1 should be > client([Host]) -> > ? ?client(Host, 2006). > > client/1 last clause ends with ";" instead of "." > > > /Anders > From dgud@REDACTED Thu Jun 4 08:49:40 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 04 Jun 2009 08:49:40 +0200 Subject: [erlang-bugs] erlang with newer wxWidgets (>= 2.8.9.1, maybe earlier versions) In-Reply-To: <200906031831.04769.kruber@zib.de> References: <200906031831.04769.kruber@zib.de> Message-ID: <4A276E84.5090907@erix.ericsson.se> Hmm, I have used wxMac-2.8.10 which builds nicely. It might be that some linux distribution compiles without some backward compability flag, I will fix it hopefully before the next release. /Dan Nico Kruber wrote: > * PGP Signed: 06/03/2009 at 06:31:04 PM > > Erlang's wx integration doesn't compile with newer wxWidgets libraries > -> the attached patch solves this similar to the patch applied here: > http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/src/html/helpfrm.cpp?r1=36802&r2=37359&pathrev=60639 > (as you can see this is fairly old so old versions should still work - tested > with wx libs the following distributions supply: Fedora 9,10, Mandriva > 2008,2009, SLE 11, openSUSE 11.0,11.1,Factory) > > Nico > > * Nico Kruber > * 0xDAEA9E59 > From kruber@REDACTED Thu Jun 4 10:11:38 2009 From: kruber@REDACTED (Nico Kruber) Date: Thu, 4 Jun 2009 10:11:38 +0200 Subject: [erlang-bugs] erlang with newer wxWidgets (>= 2.8.9.1, maybe earlier versions) In-Reply-To: <4A276E84.5090907@erix.ericsson.se> References: <200906031831.04769.kruber@zib.de> <4A276E84.5090907@erix.ericsson.se> Message-ID: <200906041011.43480.kruber@zib.de> I tried building it on openSUSE Factory and it failed because of that -> could be because of such flag - as far as I can see, those are the options used to build that rpm: # common_configure_opts="--prefix=%{_prefix} \ # --datadir=%{_datadir} \ # --libdir=%{_libdir} \ # --enable-rpath=%{_libdir} \ # --with-opengl \ # --with-libmspack \ # --with-sdl \ # --enable-sound \ # --with-gnomeprint \ # --with-gnomevfs \ # --enable-iff \ # --enable-geometry \ # --enable-optimise \ # --with-gtk=2 \ # --enable-controls \ # --enable-calendar \ # --enable-tabdialog \ # --enable-std_iostreams\ # --enable-plugins \ # --disable-precomp-headers \ # --enable-stl" each with and without unicode: # # build ANSI version # pushd wxWidgets-ansi # ../configure --disable-unicode ${common_configure_opts} # # build Unicode version # pushd wxWidgets-unicode # ../configure --enable-unicode ${common_configure_opts} -> the patch I supplied solves the (only) 3 lines that didn't compile and afaik it should result in the same behaviour (actually I never used wx, so I tried to stick to the changes that were made to the mentioned helpfrm.cpp file) Nico PS: If you use the openSUSE Build Service, you could have a look at the compile logs for the mentioned distributions with that patch applied (among others the "official" openSUSE packages use as well): https://build.opensuse.org/package/show?package=erlang&project=home%3Atschuett On Thursday 04 June 2009 08:49:40 Dan Gudmundsson wrote: > Hmm, I have used wxMac-2.8.10 which builds nicely. > It might be that some linux distribution compiles without some backward > compability flag, I will fix it hopefully before the next release. > > /Dan > > Nico Kruber wrote: > > * PGP Signed: 06/03/2009 at 06:31:04 PM > > > > Erlang's wx integration doesn't compile with newer wxWidgets libraries > > -> the attached patch solves this similar to the patch applied here: > > http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/src/html/helpfrm.cpp?r > >1=36802&r2=37359&pathrev=60639 (as you can see this is fairly old so old > > versions should still work - tested with wx libs the following > > distributions supply: Fedora 9,10, Mandriva 2008,2009, SLE 11, openSUSE > > 11.0,11.1,Factory) > > > > Nico > > > > * Nico Kruber > > * 0xDAEA9E59 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From anders.nygren@REDACTED Fri Jun 5 05:44:58 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Thu, 4 Jun 2009 22:44:58 -0500 Subject: sctp tsn Message-ID: Hi In the sctp_sndrcvinfo record when receiving data with SCTP the tsn is signed. But RFC 2960 ch. 1.5 says that TSN is unsigned. /Anders From chris.newcombe@REDACTED Fri Jun 5 16:43:54 2009 From: chris.newcombe@REDACTED (Chris Newcombe) Date: Fri, 5 Jun 2009 07:43:54 -0700 Subject: Frequent crashes in inets http client (R12B-5) Message-ID: <781dd98c0906050743p5250a4e7j6c89c710cb5c0f7@mail.gmail.com> Is there a patch for the following issue? It was reported a while ago: http://groups.google.com/group/erlang-programming/browse_thread/thread/4c497978c75ed6a9/18d9a242df81ba3a?lnk=gst&q=badrecord#18d9a242df81ba3a(but I didn't see any replies) Here's a bit more detail: httpc_handler is crashing with {badrecord,request} (BTW it would be great if badrecord errors also contained the incorrect term, not just the name of the expected record type) It?s crashing in httpc_handler,handle_info,2 The last message received by the gen_server is {timeout,#Ref<0.0.0.9038>} The gen_server #state is {state,undefined,{tcp_session,{{"my-test-url",8080},<0.709.0>},false,http,#Port<0.1351>,1},undefined,undefined,undefined,undefined,{[],[]},pipeline,[#Ref<0.0.0.5834>],nolimit,nolimit,{options,{undefined,[]},20000,1,100,disabled,enabled,false},{timers,[],#Ref<0.0.0.19293>} I think the relevant element is the first one (request). i.e. request == undefined Given the message, it seems almost certain that the crash is in the second timeout clause of handle_info, (marked below with ***). This clause will fire even if request == undefined, but will try to use Request#request.from, which crashes with {badrecord,request} %%% Timeouts %% Internaly, to a request handling process, a request time out is %% seen as a canceld request. handle_info({timeout, RequestId}, State = #state{request = Request = #request{id = RequestId}}) -> httpc_response:send(Request#request.from, httpc_response:error(Request,timeout)), {stop, normal, State#state{canceled = [RequestId | State#state.canceled], request = Request#request{from = answer_sent}}}; *** handle_info({timeout, RequestId}, State = #state{request = Request}) -> httpc_response:send(Request#request.from, httpc_response:error(Request,timeout)), {noreply, State#state{canceled = [RequestId | State#state.canceled]}}; handle_info(timeout_pipeline, State = #state{request = undefined}) -> {stop, normal, State}; It looks like State#state.request is being set to undefined without cancelling an in-progress request timer. I've only glanced at the code, but both of the following clauses appear to do that. (But it could easily be something else.) %% On a redirect or retry the current request becomes %% obsolete and the manager will create a new request %% with the same id as the current. {redirect, NewRequest, Data}-> ok = httpc_manager:redirect_request(NewRequest, ProfileName), handle_pipeline(State#state{request = undefined}, Data); {retry, TimeNewRequest, Data}-> ok = httpc_manager:retry_request(TimeNewRequest, ProfileName), handle_pipeline(State#state{request = undefined}, Data); thanks, Chris From oscar@REDACTED Fri Jun 5 16:42:34 2009 From: oscar@REDACTED (=?windows-1252?Q?Oscar_Hellstr=F6m?=) Date: Fri, 05 Jun 2009 15:42:34 +0100 Subject: [erlang-questions] Frequent crashes in inets http client (R12B-5) In-Reply-To: <781dd98c0906050743p5250a4e7j6c89c710cb5c0f7@mail.gmail.com> References: <781dd98c0906050743p5250a4e7j6c89c710cb5c0f7@mail.gmail.com> Message-ID: <4A292EDA.2010108@erlang-consulting.com> Not to start a flame war, but I would stay away from the inets http client if I were trying to build something serious. You can find my reasons here: http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:43806:200905:gocblgddeplfolmoleep Best regards Chris Newcombe wrote: > Is there a patch for the following issue? > > > > It was reported a while ago: > http://groups.google.com/group/erlang-programming/browse_thread/thread/4c497978c75ed6a9/18d9a242df81ba3a?lnk=gst&q=badrecord#18d9a242df81ba3a(but > I didn't see any replies) > > > > Here's a bit more detail: > > > > httpc_handler is crashing with > > > > {badrecord,request} > > > > (BTW it would be great if badrecord errors also contained the incorrect > term, not just the name of the expected record type) > > > > It?s crashing in > > > > httpc_handler,handle_info,2 > > > > The last message received by the gen_server is > > > > {timeout,#Ref<0.0.0.9038>} > > > > The gen_server #state is > > > > > {state,undefined,{tcp_session,{{"my-test-url",8080},<0.709.0>},false,http,#Port<0.1351>,1},undefined,undefined,undefined,undefined,{[],[]},pipeline,[#Ref<0.0.0.5834>],nolimit,nolimit,{options,{undefined,[]},20000,1,100,disabled,enabled,false},{timers,[],#Ref<0.0.0.19293>} > > > > I think the relevant element is the first one (request). > > i.e. request == undefined > > > > Given the message, it seems almost certain that the crash is in the second > timeout clause of handle_info, > > (marked below with ***). > > This clause will fire even if request == undefined, but will try to use > Request#request.from, which crashes with {badrecord,request} > > > > %%% Timeouts > > %% Internaly, to a request handling process, a request time out is > > %% seen as a canceld request. > > handle_info({timeout, RequestId}, State = > > #state{request = Request = #request{id = RequestId}}) -> > > httpc_response:send(Request#request.from, > > httpc_response:error(Request,timeout)), > > {stop, normal, > > State#state{canceled = [RequestId | State#state.canceled], > > request = Request#request{from = answer_sent}}}; > > > > *** handle_info({timeout, RequestId}, State = #state{request = Request}) > -> > > httpc_response:send(Request#request.from, > > httpc_response:error(Request,timeout)), > > {noreply, State#state{canceled = [RequestId | > State#state.canceled]}}; > > > > handle_info(timeout_pipeline, State = #state{request = undefined}) -> > > {stop, normal, State}; > > > > It looks like State#state.request is being set to undefined without > cancelling an in-progress request timer. > > > I've only glanced at the code, but both of the following clauses appear to > do that. > > (But it could easily be something else.) > > > > %% On a redirect or retry the current request becomes > > %% obsolete and the manager will create a new request > > %% with the same id as the current. > > {redirect, NewRequest, Data}-> > > ok = httpc_manager:redirect_request(NewRequest, ProfileName), > > handle_pipeline(State#state{request = undefined}, Data); > > {retry, TimeNewRequest, Data}-> > > ok = httpc_manager:retry_request(TimeNewRequest, ProfileName), > > handle_pipeline(State#state{request = undefined}, Data); > > > > thanks, > > > > Chris > > -- Oscar Hellstr?m, oscar@REDACTED Office: +44 20 7655 0337 Mobile: +44 798 45 44 773 Erlang Training and Consulting Ltd http://www.erlang-consulting.com/ From chris.newcombe@REDACTED Fri Jun 5 20:34:50 2009 From: chris.newcombe@REDACTED (Chris Newcombe) Date: Fri, 5 Jun 2009 11:34:50 -0700 Subject: Frequent crashes in inets http client (R12B-5) In-Reply-To: <781dd98c0906050743p5250a4e7j6c89c710cb5c0f7@mail.gmail.com> References: <781dd98c0906050743p5250a4e7j6c89c710cb5c0f7@mail.gmail.com> Message-ID: <781dd98c0906051134r21e1c2ebr5a186ea231888e4d@mail.gmail.com> My first (weak) hypothesis was wrong -- cancelling the request timer in the redirect and retry clauses did not fix the issue. I tried the obvious mindless suppression of the symptom, and that appears to work. See hack below. (This is not a production-worthy patch.) Of course this does nothing to address the root cause, or other symptoms of the bug. In a short test with 100 sessions (pipeline depth of 1), I didn't see any obvious resource leaks, but absence of evidence is not evidence of absence and all that. It would be great to get an official fix for this bug, and the other issues identified by Oscar. Finally, this hack also applies Mats Cronqvist's suggested patch to avoid SASL error reports every time that an HTTP server closes a connection. (As I mention in a comment below, I don't think a SASL report should be generated if a TCP connection happens to be broken and cause a tcp_error, but I didn't make that change as I have no easy way to test it.) Chris This is against R12B-5 ==== erlang/lib/inets/src/http_client/httpc_handler.erl ==== @@ -361,9 +361,15 @@ %%% Error cases handle_info({tcp_closed, _}, State) -> - {stop, session_remotly_closed, State}; + %% cnewcom: was: {stop, session_remotly_closed, State}; + {stop, shutdown, State}; % cnewcom: per http://groups.google.com/group/erlang-programming/browse_thread/thread/4c497978c75ed6a9/18d9a242df81ba3a?lnk=gst&q=badrecord#18d9a242df81ba3a + handle_info({ssl_closed, _}, State) -> - {stop, session_remotly_closed, State}; + %% cnewcom: was: {stop, session_remotly_closed, State}; + {stop, shutdown, State}; + +%% cnewcom: TODO: do we really want a SASL error report if a connection is broken? +%% handle_info({tcp_error, _, _} = Reason, State) -> {stop, Reason, State}; handle_info({ssl_error, _, _} = Reason, State) -> @@ -379,6 +385,14 @@ {stop, normal, State#state{canceled = [RequestId | State#state.canceled], request = Request#request{from = answer_sent}}}; + +%% cnewcom : try to work around request timeout arriving when State#state.request == undefined +%% cnewcom : this appears to successfully suppress the symptom (and a stress test doesn't show any obvious resource leak) +%% cnewcom : but there may be other symptoms +%% +handle_info({timeout, RequestId}, State = #state{request = undefined}) -> + {noreply, State#state{canceled = [RequestId | State#state.canceled]}}; + handle_info({timeout, RequestId}, State = #state{request = Request}) -> httpc_response:send(Request#request.from, On Fri, Jun 5, 2009 at 7:43 AM, Chris Newcombe wrote: > Is there a patch for the following issue? > > > > It was reported a while ago: > http://groups.google.com/group/erlang-programming/browse_thread/thread/4c497978c75ed6a9/18d9a242df81ba3a?lnk=gst&q=badrecord#18d9a242df81ba3a(but I didn't see any replies) > > > > Here's a bit more detail: > > > > httpc_handler is crashing with > > > > {badrecord,request} > > > > (BTW it would be great if badrecord errors also contained the incorrect > term, not just the name of the expected record type) > > > > It?s crashing in > > > > httpc_handler,handle_info,2 > > > > The last message received by the gen_server is > > > > {timeout,#Ref<0.0.0.9038>} > > > > The gen_server #state is > > > > > {state,undefined,{tcp_session,{{"my-test-url",8080},<0.709.0>},false,http,#Port<0.1351>,1},undefined,undefined,undefined,undefined,{[],[]},pipeline,[#Ref<0.0.0.5834>],nolimit,nolimit,{options,{undefined,[]},20000,1,100,disabled,enabled,false},{timers,[],#Ref<0.0.0.19293>} > > > > I think the relevant element is the first one (request). > > i.e. request == undefined > > > > Given the message, it seems almost certain that the crash is in the second > timeout clause of handle_info, > > (marked below with ***). > > This clause will fire even if request == undefined, but will try to use > Request#request.from, which crashes with {badrecord,request} > > > > %%% Timeouts > > %% Internaly, to a request handling process, a request time out is > > %% seen as a canceld request. > > handle_info({timeout, RequestId}, State = > > #state{request = Request = #request{id = RequestId}}) > -> > > httpc_response:send(Request#request.from, > > httpc_response:error(Request,timeout)), > > {stop, normal, > > State#state{canceled = [RequestId | State#state.canceled], > > request = Request#request{from = answer_sent}}}; > > > > *** handle_info({timeout, RequestId}, State = #state{request = > Request}) -> > > httpc_response:send(Request#request.from, > > httpc_response:error(Request,timeout)), > > {noreply, State#state{canceled = [RequestId | > State#state.canceled]}}; > > > > handle_info(timeout_pipeline, State = #state{request = undefined}) > -> > > {stop, normal, State}; > > > > It looks like State#state.request is being set to undefined without > cancelling an in-progress request timer. > > > I've only glanced at the code, but both of the following clauses appear to > do that. > > (But it could easily be something else.) > > > > %% On a redirect or retry the current request becomes > > %% obsolete and the manager will create a new request > > %% with the same id as the current. > > {redirect, NewRequest, Data}-> > > ok = httpc_manager:redirect_request(NewRequest, ProfileName), > > handle_pipeline(State#state{request = undefined}, Data); > > {retry, TimeNewRequest, Data}-> > > ok = httpc_manager:retry_request(TimeNewRequest, ProfileName), > > handle_pipeline(State#state{request = undefined}, Data); > > > > thanks, > > > > Chris > > > From mickael.remond@REDACTED Sat Jun 6 11:38:38 2009 From: mickael.remond@REDACTED (Mickael Remond) Date: Sat, 06 Jun 2009 11:38:38 +0200 Subject: Compilation problem on MacOSX Message-ID: Hello, I have the following compilation problem on MacOSX. Compiler reports: Recompile: src/ll_packetizer ll_packetizer: function process_rtmp/2+168: Internal consistency check failed - please report this bug. Instruction: {test,bs_start_match2,{f,99},[{y,11},3,0,{x,0}]} Error: {match_context,{y,11}}: The same file compiles fine on Linux. Version used R12B-5. I will do the same test with Erlang R13B -- Micka?l R?mond http://www.process-one.net/ From toby@REDACTED Sun Jun 7 18:59:59 2009 From: toby@REDACTED (Toby Thain) Date: Sun, 7 Jun 2009 12:59:59 -0400 Subject: [erlang-bugs] Compilation problem on MacOSX In-Reply-To: References: Message-ID: On 6-Jun-09, at 5:38 AM, Mickael Remond wrote: > Hello, > > I have the following compilation problem on MacOSX. Which OS X? --Toby > Compiler reports: > > Recompile: src/ll_packetizer > ll_packetizer: function process_rtmp/2+168: > Internal consistency check failed - please report this bug. > Instruction: {test,bs_start_match2,{f,99},[{y,11},3,0,{x,0}]} > Error: {match_context,{y,11}}: > > The same file compiles fine on Linux. > Version used R12B-5. > I will do the same test with Erlang R13B > > -- > Micka?l R?mond > http://www.process-one.net/ > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From kenneth.lundin@REDACTED Mon Jun 8 09:06:17 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 8 Jun 2009 09:06:17 +0200 Subject: [erlang-bugs] Compilation problem on MacOSX In-Reply-To: References: Message-ID: Hi, I don't think this is a Mac OS X specific problem. The error comes from the Erlang compiler when trying to compile an Erlang module and this is not platform dependent at all. Please check if the error is still there in R13B and in that case provide the source for the module that triggers the error (or try to minimise the module first). /Kenneth Erlang/OTP Ericsson On Sat, Jun 6, 2009 at 11:38 AM, Mickael Remond wrote: > Hello, > > I have the following compilation problem on MacOSX. Compiler reports: > > Recompile: src/ll_packetizer > ll_packetizer: function process_rtmp/2+168: > ?Internal consistency check failed - please report this bug. > ?Instruction: {test,bs_start_match2,{f,99},[{y,11},3,0,{x,0}]} > ?Error: ? ? ? {match_context,{y,11}}: > > The same file compiles fine on Linux. > Version used R12B-5. > I will do the same test with Erlang R13B > > -- > Micka?l R?mond > ?http://www.process-one.net/ > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From mickael.remond@REDACTED Mon Jun 8 11:29:31 2009 From: mickael.remond@REDACTED (Mickael Remond) Date: Mon, 08 Jun 2009 11:29:31 +0200 Subject: [erlang-bugs] Compilation problem on MacOSX In-Reply-To: (Kenneth Lundin's message of "Mon\, 8 Jun 2009 09\:06\:17 +0200") References: Message-ID: Hello, It still have this inconsistency problem, so I will send you the code. The problem has to do with code which seems quite undetermined due to the same variable being exported several time from a case. It seems it confuses the compiler (which I can understand as reading this code is really confusing for a human as well). Kenneth Lundin wrote: > Hi, > > I don't think this is a Mac OS X specific problem. > The error comes from the Erlang compiler when trying to compile an > Erlang module and > this is not platform dependent at all. > > Please check if the error is still there in R13B and in that case > provide the source for the module that triggers the error (or try to > minimise the module > first). > > /Kenneth Erlang/OTP Ericsson > > On Sat, Jun 6, 2009 at 11:38 AM, Mickael > Remond wrote: >> Hello, >> >> I have the following compilation problem on MacOSX. Compiler reports: >> >> Recompile: src/ll_packetizer >> ll_packetizer: function process_rtmp/2+168: >> ?Internal consistency check failed - please report this bug. >> ?Instruction: {test,bs_start_match2,{f,99},[{y,11},3,0,{x,0}]} >> ?Error: ? ? ? {match_context,{y,11}}: >> >> The same file compiles fine on Linux. >> Version used R12B-5. >> I will do the same test with Erlang R13B >> >> -- >> Micka?l R?mond >> ?http://www.process-one.net/ >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> -- Micka?l R?mond http://www.process-one.net/ From mevans@REDACTED Wed Jun 10 21:31:19 2009 From: mevans@REDACTED (Evans, Matthew) Date: Wed, 10 Jun 2009 15:31:19 -0400 Subject: Mnesia Fragmented Tables Message-ID: Hello, I have a somewhat unusual issue with fragmented Mnesia tables. I have a mesh of 6 nodes, and have created 24 fragments over those nodes using the command: mnesia:create_table(index_data, [{frag_properties,[{node_pool, NodeList},{n_fragments,24},{n_disc_copies,0}, {n_disc_only_copies,0}]},{index,[type]},{attributes, record_info(fields, index_data)},{type, bag}]). As part of a test protocol I wanted to test what happens if I kill a node. To do this I physically unplug the node. What I see is that when I do a mnesia:info() is the fragments that were on that node are in this state: [] = [index_data_frag21,index_data_frag15,index_data_frag9,index_data_frag3] Of course, I can not read data from those fragments. However I can not seem to delete those fragments either. Worse still, when I try to insert a record the hashing function attempts to pick up one of those "lost" fragments and the insert aborts with error: {aborted,{no_exists,index_data_frag11}} This insert is dirty, using the code: AddFun = fun() -> mnesia:write(index_data, #index_data{asset = Asset, npt = Npt, type = Type, inpoint = Inpoint, data = Data}, write) end, mnesia:activity(async_dirty, AddFun, [], mnesia_frag). Am I missing something? Thanks Matt From jwebb@REDACTED Thu Jun 11 09:25:08 2009 From: jwebb@REDACTED (John Webb) Date: Thu, 11 Jun 2009 16:25:08 +0900 Subject: wxErlang demo -- strange behavoiur? Message-ID: <426BFEDD-1255-4067-9279-312D7678BD99@gol.com> Hi, I just noticed the (very nice) new demo uses the "-behavoiur" compiler directive in its source files rather than the more effective "- behaviour". (possibly inherited from the hello2.erl example?) Regards, John Webb From vincent.dephily@REDACTED Thu Jun 11 11:52:28 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Thu, 11 Jun 2009 11:52:28 +0200 Subject: http:request/5 returning wrong request and crashing Message-ID: <200906111152.31018.vincent.dephily@mobile-devices.fr> Hi list, I am making asynchronous http requests, sometimes close to one another a to a server that may take a longer or shorter time to answer. But httpc eventually returns the wrong answer (I start each request from a new process, and check that the RequestId is correct), and ultimately crashes. Attached files are the server code (running on apache mod_php), the client code (running via escript), and the output with the error. I'm now digging into the erlang http code, but if some smart erlanger on this list can (check any that apply :p) * confirm that I'm using the http module correctly * reproduce the error * find/fix the error in the http module I'd be very gratefull. Thank you. -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. -------------- next part -------------- ERROR got sleep:475773,req:22 instead of sleep:253855,req:36 ERROR got sleep:400962,req:23 instead of sleep:892698,req:48 ERROR got sleep:609265,req:44 instead of sleep:666946,req:46 ERROR got sleep:809604,req:37 instead of sleep:561590,req:43 ERROR got sleep:48275,req:40 instead of sleep:583062,req:79 ERROR got sleep:309693,req:24 instead of sleep:19887,req:69 ERROR got sleep:58650,req:25 instead of sleep:165858,req:83 ERROR got sleep:876102,req:47 instead of sleep:236006,req:84 ERROR got sleep:294143,req:51 instead of sleep:116891,req:100 ERROR got sleep:666946,req:46 instead of sleep:265132,req:76 ERROR got sleep:561590,req:43 instead of sleep:134661,req:82 ERROR got sleep:578814,req:26 instead of sleep:333639,req:87 ERROR got sleep:265132,req:76 instead of sleep:334454,req:102 ERROR got sleep:334454,req:102 instead of sleep:535188,req:116 ERROR got sleep:583062,req:79 instead of sleep:24666,req:103 ERROR got sleep:719828,req:52 instead of sleep:911082,req:134 ERROR got sleep:134661,req:82 instead of sleep:773815,req:133 ERROR got sleep:24666,req:103 instead of sleep:139471,req:136 ERROR got sleep:400772,req:53 instead of sleep:867834,req:149 ERROR got sleep:535188,req:116 instead of sleep:220863,req:132 ERROR got sleep:989294,req:27 instead of sleep:753863,req:110 ERROR got sleep:183676,req:29 instead of sleep:140469,req:155 ERROR got sleep:220863,req:132 instead of sleep:78155,req:152 ERROR got sleep:78155,req:152 instead of sleep:548799,req:161 ERROR got sleep:202757,req:30 instead of sleep:181404,req:163 ERROR got sleep:773815,req:133 instead of sleep:327887,req:137 ERROR got sleep:33599,req:31 instead of sleep:482978,req:172 ERROR got sleep:139471,req:136 instead of sleep:46808,req:171 ERROR got sleep:793855,req:54 instead of sleep:904511,req:186 ERROR got sleep:74423,req:55 instead of sleep:579316,req:191 ERROR got sleep:548799,req:161 instead of sleep:686473,req:166 ERROR got sleep:327887,req:137 instead of sleep:314327,req:179 ERROR got sleep:46808,req:171 instead of sleep:755194,req:197 ERROR got sleep:26543,req:213 instead of sleep:120616,req:214 ERROR got sleep:393300,req:56 instead of sleep:461674,req:212 ERROR got sleep:314327,req:179 instead of sleep:600785,req:199 ERROR got sleep:120616,req:214 instead of sleep:955584,req:216 ERROR got sleep:889027,req:32 instead of sleep:811871,req:173 ERROR got sleep:686473,req:166 instead of sleep:99423,req:195 ERROR got sleep:99423,req:195 instead of sleep:777027,req:229 ERROR got sleep:597835,req:57 instead of sleep:158049,req:217 ERROR got sleep:755194,req:197 instead of sleep:440344,req:218 ERROR got sleep:836914,req:33 instead of sleep:781901,req:225 ERROR got sleep:955584,req:216 instead of sleep:520411,req:231 ERROR got sleep:777027,req:229 instead of sleep:847124,req:234 ERROR got sleep:644213,req:59 instead of sleep:773020,req:238 ERROR got sleep:600785,req:199 instead of sleep:685726,req:243 ERROR got sleep:828876,req:34 instead of sleep:27102,req:249 ERROR got sleep:440344,req:218 instead of sleep:579362,req:265 ERROR got sleep:601217,req:62 instead of sleep:534866,req:259 =ERROR REPORT==== 11-Jun-2009::11:20:30 === ** Generic server <0.63.0> terminating ** Last message in was {tcp,#Port<0.963>, <<"HTTP/1.1 200 OK\r\nDate: Thu, 11 Jun 2009 09:20:30 GMT\r\nServer: Apache\r\nX-Powered-By: PHP/5.2.9-pl2-gentoo\r\nContent-Length: 1090\r\nKeep-Alive: timeout=15, max=89\r\nConnection: Keep-Alive\r\nContent-Type: text/plain\r\n\r\nsleep:1744,req:63\nslept for 1744 usec\nArray\n(\n [sleep] => 1744\n [data] => sleep:1744,req:63\n)\nArray\n(\n [UNIQUE_ID] => SjDMXn8AAAEAAGFnP9YAAAB9\n [HTTP_TE] => \n [HTTP_HOST] => 127.0.0.1\n [HTTP_CONNECTION] => keep-alive\n [PATH] => /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/sbin:/usr/sbin\n [SERVER_SIGNATURE] =>
Apache Server at 127.0.0.1 Port 80
\n\n [SERVER_SOFTWARE] => Apache\n [SERVER_NAME] => 127.0.0.1\n [SERVER_ADDR] => 127.0.0.1\n [SERVER_PORT] => 80\n [REMOTE_ADDR] => 127.0.0.1\n [DOCUMENT_ROOT] => /var/www/localhost/htdocs\n [SERVER_ADMIN] => root@REDACTED\n [SCRIPT_FILENAME] => /var/www/localhost/htdocs/sleep.php\n [REMOTE_PORT] => 39719\n [GATEWAY_INTERFACE] => CGI/1.1\n [SERVER_PROTOCOL] => HTTP/1.1\n [REQUEST_METHOD] => GET\n [QUERY_STRING] => sleep=1744&data=sleep:1744,req:63\n [REQUEST_URI] => /sleep.php?sleep=1744&data=sleep:1744,req:63\n [SCRIPT_NAME] => /sleep.php\n [PHP_SELF] => /sleep.php\n [REQUEST_TIME] => 1244712030\n)\n">>} ** When Server state == {state,undefined, {tcp_session, {{"127.0.0.1",80},<0.63.0>}, false,http,#Port<0.963>,1,keep_alive}, undefined,undefined,undefined,undefined, {[],[]}, {[],[]}, keep_alive,[],nolimit,nolimit, {options, {undefined,[]}, 0,2,5,120000,2,disabled,enabled,false}, {timers,[],#Ref<0.0.0.1227>}, httpc_manager_myprofile,undefined} ** Reason for termination == ** {function_clause, [{httpc_handler,handle_info, [{tcp,#Port<0.963>, <<"HTTP/1.1 200 OK\r\nDate: Thu, 11 Jun 2009 09:20:30 GMT\r\nServer: Apache\r\nX-Powered-By: PHP/5.2.9-pl2-gentoo\r\nContent-Length: 1090\r\nKeep-Alive: timeout=15, max=89\r\nConnection: Keep-Alive\r\nContent-Type: text/plain\r\n\r\nsleep:1744,req:63\nslept for 1744 usec\nArray\n(\n [sleep] => 1744\n [data] => sleep:1744,req:63\n)\nArray\n(\n [UNIQUE_ID] => SjDMXn8AAAEAAGFnP9YAAAB9\n [HTTP_TE] => \n [HTTP_HOST] => 127.0.0.1\n [HTTP_CONNECTION] => keep-alive\n [PATH] => /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/sbin:/usr/sbin\n [SERVER_SIGNATURE] =>
Apache Server at 127.0.0.1 Port 80
\n\n [SERVER_SOFTWARE] => Apache\n [SERVER_NAME] => 127.0.0.1\n [SERVER_ADDR] => 127.0.0.1\n [SERVER_PORT] => 80\n [REMOTE_ADDR] => 127.0.0.1\n [DOCUMENT_ROOT] => /var/www/localhost/htdocs\n [SERVER_ADMIN] => root@REDACTED\n [SCRIPT_FILENAME] => /var/www/localhost/htdocs/sleep.php\n [REMOTE_PORT] => 39719\n [GATEWAY_INTERFACE] => CGI/1.1\n [SERVER_PROTOCOL] => HTTP/1.1\n [REQUEST_METHOD] => GET\n [QUERY_STRING] => sleep=1744&data=sleep:1744,req:63\n [REQUEST_URI] => /sleep.php?sleep=1744&data=sleep:1744,req:63\n [SCRIPT_NAME] => /sleep.php\n [PHP_SELF] => /sleep.php\n [REQUEST_TIME] => 1244712030\n)\n">>}, {state,undefined, {tcp_session, {{"127.0.0.1",80},<0.63.0>}, false,http,#Port<0.963>,1,keep_alive}, undefined,undefined,undefined,undefined, {[],[]}, {[],[]}, keep_alive,[],nolimit,nolimit, {options, {undefined,[]}, 0,2,5,120000,2,disabled,enabled,false}, {timers,[],#Ref<0.0.0.1227>}, httpc_manager_myprofile,undefined}]}, {gen_server,handle_msg,5}, {proc_lib,init_p_do_apply,3}]} ERROR got sleep:966340,req:222 instead of sleep:41561,req:283 ERROR got sleep:847124,req:234 instead of sleep:452924,req:260 ERROR got sleep:328018,req:35 instead of sleep:38465,req:287 ERROR got sleep:253855,req:36 instead of sleep:752560,req:298 ERROR got sleep:449731,req:228 instead of sleep:482324,req:314 ERROR got sleep:452924,req:260 instead of sleep:836953,req:297 ERROR got sleep:685726,req:243 instead of sleep:704916,req:289 ERROR got sleep:520411,req:231 instead of sleep:779911,req:336 ERROR got sleep:579362,req:265 instead of sleep:573722,req:321 ERROR got sleep:892698,req:48 instead of sleep:623977,req:310 ERROR got sleep:19887,req:69 instead of sleep:884027,req:355 ERROR got sleep:836953,req:297 instead of sleep:206028,req:317 ERROR got sleep:165858,req:83 instead of sleep:700816,req:357 ERROR got sleep:538706,req:253 instead of sleep:607225,req:370 ERROR got sleep:206028,req:317 instead of sleep:267166,req:359 ERROR got sleep:333639,req:87 instead of sleep:27437,req:363 ^C^C -------------- next part -------------- #!/usr/bin/env escript %-mode(compile). main(_Args) -> Profile = myprofile, ok = inets:start(), {ok, _ProfilePid} = inets:start(httpc, [{profile, Profile}]), loop(Profile). loop(Profile) -> loop(Profile, 1). loop(Profile, Req) -> Sleep = random:uniform(1000000), Data = "sleep:" ++ integer_to_list(Sleep) ++ ",req:" ++ integer_to_list(Req), runreq(Profile, Sleep, Data), receive after Sleep div 100000 -> ok end, loop(Profile, Req + 1). runreq(Profile, Sleep, Data) -> spawn(fun() -> case http:request(get, {"http://127.0.0.1/sleep.php?sleep=" ++ integer_to_list(Sleep) ++ "&data=" ++ Data, []}, [], [{sync, false}], Profile) of {ok, HttpRef} -> receive {http, {HttpRef, {{_, _HttpCode, _}, _, HttpData}}} -> case re:run(HttpData, "^.*$", [multiline, {capture, first, list}]) of {match, [FirstLine]} -> case FirstLine of Data -> ok; %io:format("OK ~s\n", [Data]); _ -> io:format("ERROR got ~s instead of ~s~n", [FirstLine, Data]) end; Err2 -> io:format("ERROR cant match firstline ~p~n", [Err2]) end; {error, Err3} -> io:format("ERROR http receive failure ~p~n", [Err3]) after 10000 -> ok = http:cancel_request(HttpRef, Profile), io:format("ERROR http timeout failure~n", []) end; {error, Err4} -> io:format("ERROR http request failure ~p~n", [Err4]) end end). -------------- next part -------------- A non-text attachment was scrubbed... Name: sleep.php Type: application/x-php Size: 166 bytes Desc: not available URL: From mikage@REDACTED Fri Jun 12 06:28:34 2009 From: mikage@REDACTED (Mikage Sawatari) Date: Fri, 12 Jun 2009 13:28:34 +0900 Subject: Internal consistency check failed Message-ID: <20090612132338.BE06.B079C77B@mikage.to> I have the following compilation problem on Erlang R13B01. Compiler reports "Internal consistency check failed". # /usr/local/erlang/bin/erl -version Erlang (SMP,ASYNC_THREADS,HIPE) (BEAM) emulator version 5.7.2 # /usr/local/erlang/bin/erlc erlang_error.erl erlang_error: function test/2+9: Internal consistency check failed - please report this bug. Instruction: {bs_append,{f,0}, {integer,0}, 0,4,8, {x,1}, {field_flags,[]}, {x,0}} Error: {{x,3},not_live}: # cat erlang_error.erl -module(erlang_error). -compile(export_all). test([H|T], Bin) -> _ = case H of null -> <>; _ -> ok end, test(T, Bin). # cat /etc/issue Welcome to SUSE Linux Enterprise Server 10 SP1 (x86_64) - Kernel \r (\l). ---- Mikage Sawatari From bgustavsson@REDACTED Fri Jun 12 12:18:58 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 12 Jun 2009 12:18:58 +0200 Subject: [erlang-bugs] Internal consistency check failed In-Reply-To: <20090612132338.BE06.B079C77B@mikage.to> References: <20090612132338.BE06.B079C77B@mikage.to> Message-ID: <6672d0160906120318p35d36451o822da20ca4d1bfb6@mail.gmail.com> On Fri, Jun 12, 2009 at 6:28 AM, Mikage Sawatari wrote: > > I have the following compilation problem on Erlang R13B01. > Compiler reports "Internal consistency check failed". Thanks! I have attached a correction. The correction will be included in R13B02. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler.patch Type: text/x-patch Size: 810 bytes Desc: not available URL: From vincent.dephily@REDACTED Fri Jun 12 15:22:26 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 12 Jun 2009 15:22:26 +0200 Subject: [erlang-bugs] http:request/5 returning wrong request and crashing In-Reply-To: <4A3253AB.5020206@erix.ericsson.se> References: <200906111152.31018.vincent.dephily@mobile-devices.fr> <4A3253AB.5020206@erix.ericsson.se> Message-ID: <200906121522.27381.vincent.dephily@mobile-devices.fr> On Friday 12 June 2009 15:10:03 Micael Karlberg wrote: > The crash is easy to fix, but the root cause (for the > crash) is unknown. As to the very strange order of the > replies, I have no idea yet (try running with a longer > timeout). > > I have put up an improved version here: > > http://www.erlang.org/~bmk/download//otp8052/inets-5.1.1-OTP8052-P01.tgz > > I have added some trace features. Add the following > call before starting inets: > > inets:enable_trace(max, io). > > For example in the escript code: > > main(_Args) -> > Profile = myprofile, > inets:enable_trace(max, io), > ok = inets:start(), > {ok, _ProfilePid} = inets:start(httpc, [{profile, Profile}]), > loop(Profile). > > This should give us some more info. Thanks, I will try that. For what it's worth, I'm currently working around the bug with http:set_options([{cookies, enabled}, {max_keep_alive_length, 0}], ProfilePid) Also, this workaround only seem to work with 13B01, it doesn't help with 13B. -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. From vincent.dephily@REDACTED Fri Jun 12 15:35:31 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 12 Jun 2009 15:35:31 +0200 Subject: [erlang-bugs] http:request/5 returning wrong request and crashing In-Reply-To: <200906121522.27381.vincent.dephily@mobile-devices.fr> References: <200906111152.31018.vincent.dephily@mobile-devices.fr> <4A3253AB.5020206@erix.ericsson.se> <200906121522.27381.vincent.dephily@mobile-devices.fr> Message-ID: <200906121535.31529.vincent.dephily@mobile-devices.fr> On Friday 12 June 2009 15:22:26 Vincent de Phily wrote: > For what it's worth, I'm currently working around the bug with > http:set_options([{cookies, enabled}, {max_keep_alive_length, 0}], > ProfilePid) > Also, this workaround only seem to work with 13B01, it doesn't help with > 13B. I meant http:set_options([{max_keep_alive_length, 0}], ProfilePid) (the cookie handling is irrelevant) -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. From paul-trapexit@REDACTED Sat Jun 13 08:36:27 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Fri, 12 Jun 2009 23:36:27 -0700 (PDT) Subject: issue with erlang decoding of big numbers Message-ID: hi. i'm tracking down an issue with tcerl http://code.google.com/p/tcerl/issues/detail?id=4 and it appears related to the erl_interface code to handle big nums. i'll focus on SMALL_BIG_EXT but LARGE_BIG_EXT has analogous issues. when decoding via ei_decode_big () from /usr/lib/erlang/lib/erl_interface-3.5.9/src/decode/decode_big.c the digit bytes are read from the stream and the arity is forced to be ((digit_bytes + 1 / 2) and then an arity number of 16 bit values is read, i.e., the number of bytes read is always even. however there is no justification for this from the spec http://erlang.org/doc/apps/erts/erl_ext_dist.html which indicates a base of 256 (i.e., one digit = one character) and i can see in the shell for instance that 1> erlang:term_to_binary (9999999999). <<131,110,5,0,255,227,11,84,2>> i.e. after the sign bit there are 5 bytes ... but 6 will be read by ei_decode_big () and in practice this means random garbage will be added to the big num. in diving in to fix this i noticed that other parts of the code are assuming 16 bit digits, e.g., still in decode_big.c the function I_comp() called from ei_big_comp() is comparing the values 16 bits at a time, again apparently unmotivated from the spec. the problem is so pervasive that i'm pausing to fix the issue to get some guidance from the OTP team about what is intended here. am i missing something? thanks, -- p From pguyot@REDACTED Sat Jun 13 09:20:20 2009 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 13 Jun 2009 09:20:20 +0200 Subject: issue with erlang decoding of big numbers In-Reply-To: <1244874991.3770.ezmlm@erlang.org> References: <1244874991.3770.ezmlm@erlang.org> Message-ID: <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> Le 13 juin 09 ? 08:36, erlang-bugs-digest-help@REDACTED a ?crit : > De : Paul Mineiro > Date : 13 juin 2009 08:36:27 HAEC > ? : erlang-bugs@REDACTED > Objet : issue with erlang decoding of big numbers [...] > the problem is so pervasive that i'm pausing to fix the issue to get > some guidance from the OTP team about what is intended here. am i > missing > something? This bug was reported in October 2008 with a patch : http://erlang.org/pipermail/erlang-bugs/2008-October/001023.html AFAIK, it is still not fixed in R13B01. Regards, Paul From crystaldin49@REDACTED Sat Jun 13 15:18:38 2009 From: crystaldin49@REDACTED (Crystal Din) Date: Sat, 13 Jun 2009 15:18:38 +0200 Subject: Bug in digraph:add_edge/5 Message-ID: Hi, Version: Erlang/OTP R13B. Bug in digraph:add_edge/5 >From the documentation of digraph module, it says add_edge/5 creates (or modifies) the edge E of the digraph G. However, the existing edges are not correctly modified. --------------------Set up digraph----------------- 1>G=digraph:new(). 2>digraph:add_vertex(G). ['$v'|0] 3>digraph:add_vertex(G). ['$v'|1] 4>digraph:add_vertex(G). ['$v'|2] 5>digraph:add_vertex(G). ['$v'|3] 6>digraph:add_edge(G,['$e'|0],['$v'|0],['$v'|1],{}). ['$e'|0] 7>digraph:add_edge(G,['$e'|0],['$v'|2],['$v'|3],{}). ['$e'|0] According to the documentation, there should be only one edge, ['$e'|0], in the digraph and it is from ['$v'|2] to ['$v'|3]. But that actually ['$v'|0] and ['$v'|1] still seem to be connected to the edge,['$e'|0]. We can see the bugs from the following. -----------------------Bug-------------------------- 8>digraph:out_degree(G,['$v'|0]). 1 9>digraph:out_edges(G,['$v'|0]). [[?$e?|0]] 10>digraph:out_neighbours(G,[?$v?|0]). [[?$v?|3]] 11>digraph:in_degree(G,['$v'|1]). 1 12>digraph:in_edges(G,['$v'|1]). [[?$e?|0]] 13>digraph:in_neighbours(G,[?$v?|1]). [[?$v?|2]] -----------------expected results-------------------- 8>digraph:out_degree(G,['$v'|0]). 0 9>digraph:out_edges(G,['$v'|0]). [] 10>digraph:out_neighbours(G,[?$v?|0]). [] 11>digraph:in_degree(G,['$v'|1]). 0 12>digraph:in_edges(G,['$v'|1]). [] 13>digraph:in_neighbours(G,[?$v?|1]). [] /Crystal Din From crystaldin49@REDACTED Sat Jun 13 15:37:34 2009 From: crystaldin49@REDACTED (Crystal Din) Date: Sat, 13 Jun 2009 15:37:34 +0200 Subject: Bug in digraph:del_path/3 Message-ID: Hi, Version: Erlang/OTP R13B. Bug in digraph:del_path/3 This function does not seem to work at all. -------------------set up digraph--------------------- 1>D=digraph:new(). {digraph,40973,45070,49167,true} 2>digraph:add_vertex(D). [?$v?|0] 3>digraph:add_vertex(D). [?$v?|1] 4>digraph:add_edge(D,[?$v?|0],[?$v?|1]). [?$e?|0] 5>digraph:get_path(D,[?$v?|0],[?$v?|1]). [[?$v?|0],[?$v?|1]] -----------------------bug---------------------------- 6>digraph:del_path(D,[?$v?|0],[?$v?|1]). ** exception error: bad argument in function ets:lookup_element/3 called as ets:lookup_element (45070,['$e'0|],3) in call from digraph:collect_elems/4 in call from digraph:get_path/3 in call from digraph:del_path/3 /Crystal Din From crystaldin49@REDACTED Sat Jun 13 16:11:31 2009 From: crystaldin49@REDACTED (Crystal Din) Date: Sat, 13 Jun 2009 16:11:31 +0200 Subject: Bug in dets module Message-ID: Hi, Version: Erlang/OTP R13B. Bug in dets module. If we put a delay between calling function dets:insert/2 and dets:insert_new/2, we get different answers depending on the delay. -----------------dets_test.erl----------------------- weird(Delay) -> dets:open_file(tabName, [{type, duplicate_bag}]), dets:delete_all_objects(tabName), dets:insert(tabName, {3,0}), receive after Delay -> ok end, dets:insert_new(tabName, [{3,0},{3,0}]), X = dets:lookup(tabName, 3), dets:close(tabName), X. ----------------------testing----------------------- 1> dets_test:weird(2500). [{3,0},{3,0}] 2> dets_test:weird(2750). [{3,0},{3,0}] 3> dets_test:weird(2900). [{3,0},{3,0}] 4> dets_test:weird(2950). [{3,0},{3,0}] 5> dets_test:weird(2999). [{3,0},{3,0}] 6> dets_test:weird(3000). [{3,0}] This error is caused not only according to the delay between executing dets:insert/2 and dets:insert_new/2. The same thing happens if we use dets:insert_new/2 instead of dets:insert/2. /Crystal Din From paul-trapexit@REDACTED Sat Jun 13 17:35:34 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 13 Jun 2009 08:35:34 -0700 (PDT) Subject: issue with erlang decoding of big numbers In-Reply-To: <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> References: <1244874991.3770.ezmlm@erlang.org> <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> Message-ID: Good to know I'm not crazy, however that patch only changes ei_decode_big (), and the problem is bigger than that. Other functions are treating the number as a LSB-first sequence of 16 bit values, but since the *actual* format is an LSB-first sequence of 8 bit values, this will only work on a little endian system. For an example, see ei_big_comp(). This is enough for me to decide this is a real bug and not me tripping so I'll dive in and fix all the uses. Thanks! -- p On Sat, 13 Jun 2009, Paul Guyot wrote: > > Le 13 juin 09 ? 08:36, erlang-bugs-digest-help@REDACTED a ?crit : > > > De : Paul Mineiro > > Date : 13 juin 2009 08:36:27 HAEC > > ? : erlang-bugs@REDACTED > > Objet : issue with erlang decoding of big numbers > > [...] > > > the problem is so pervasive that i'm pausing to fix the issue to get > > some guidance from the OTP team about what is intended here. am i > > missing > > something? > > This bug was reported in October 2008 with a patch : > http://erlang.org/pipermail/erlang-bugs/2008-October/001023.html > > AFAIK, it is still not fixed in R13B01. > > Regards, > > Paul > > From paul-trapexit@REDACTED Sat Jun 13 17:44:09 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 13 Jun 2009 08:44:09 -0700 (PDT) Subject: issue with erlang decoding of big numbers In-Reply-To: References: <1244874991.3770.ezmlm@erlang.org> <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> Message-ID: Actually (sorry for the noise), upon further inspection I agree that the linked-to patch is sufficient. The code could stand a rewrite because it is very confusing relative to spec, but everything's cool. Cheers! -- p On Sat, 13 Jun 2009, Paul Mineiro wrote: > Good to know I'm not crazy, however that patch only changes ei_decode_big > (), and the problem is bigger than that. Other functions are treating the > number as a LSB-first sequence of 16 bit values, but since the *actual* > format is an LSB-first sequence of 8 bit values, this will only work on a > little endian system. For an example, see ei_big_comp(). > > This is enough for me to decide this is a real bug and not me tripping so > I'll dive in and fix all the uses. > > Thanks! > > -- p > > On Sat, 13 Jun 2009, Paul Guyot wrote: > > > > > Le 13 juin 09 ? 08:36, erlang-bugs-digest-help@REDACTED a ?crit : > > > > > De : Paul Mineiro > > > Date : 13 juin 2009 08:36:27 HAEC > > > ? : erlang-bugs@REDACTED > > > Objet : issue with erlang decoding of big numbers > > > > [...] > > > > > the problem is so pervasive that i'm pausing to fix the issue to get > > > some guidance from the OTP team about what is intended here. am i > > > missing > > > something? > > > > This bug was reported in October 2008 with a patch : > > http://erlang.org/pipermail/erlang-bugs/2008-October/001023.html > > > > AFAIK, it is still not fixed in R13B01. > > > > Regards, > > > > Paul > > > > > > From the.ajarn@REDACTED Sat Jun 13 22:54:13 2009 From: the.ajarn@REDACTED (Brentley Jones) Date: Sat, 13 Jun 2009 15:54:13 -0500 Subject: Dialyzer and inheritance Message-ID: Hello, When using Dialyzer and module inheritance (-extends(base_module)), Dialyzer complains about calls to functions that are inherited. For example, I have a module called actor_server that calls actor:attributes/1. actor extends another module that contains attributes/1, but this is what Dialyzer outputs: $ dialyzer -c ebin --plt ebin/plt Checking whether the PLT ebin/plt is up-to-date... yes Proceeding with analysis... actor_server.erl:71: Call to missing or unexported function actor:attributes/1 done in 0m1.18s done (warnings were emitted) I know that inheritance is experimental, but if it's going to be supported this should be fixed up. I can just ignore it for now though. From richardc@REDACTED Sun Jun 14 11:42:16 2009 From: richardc@REDACTED (Richard Carlsson) Date: Sun, 14 Jun 2009 11:42:16 +0200 Subject: [erlang-bugs] Dialyzer and inheritance In-Reply-To: References: Message-ID: <4A34C5F8.2030409@it.uu.se> Brentley Jones wrote: > Hello, > > When using Dialyzer and module inheritance (-extends(base_module)), > Dialyzer complains about calls to functions that are inherited. Thanks for the report. /Richard From the.ajarn@REDACTED Sun Jun 14 17:26:51 2009 From: the.ajarn@REDACTED (Brentley Jones) Date: Sun, 14 Jun 2009 10:26:51 -0500 Subject: Dialyzer and parameterized modules Message-ID: Hello, When using Dialyzer with parameterized module, it complains that it's not an atom() to the left of the ':'. It simply doesn't have it's definition of module() updated to include the current instanced modules. param_user.erl:5: Function test/0 has no local return param_user.erl:7: The call P:'test'([32 | 33 | 72 | 100 | 101 | 108 | 111 | 114 | 119,...]) requires that P is of type atom() not {'parameter',_} With the following code: %% parameter.erl -module(parameter, [X]). -export([test/1]). test(Message) -> io:format("~p: ~p~n", [X, Message]). %% param_user.erl -module(param_user). -export([test/0]). test() -> P = parameter:new(bob), P:test("Hello world!"). From mjtruog@REDACTED Mon Jun 15 04:52:20 2009 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 14 Jun 2009 19:52:20 -0700 Subject: erl_interface switch to ei for c node functions Message-ID: <4A35B764.1000108@gmail.com> I found a problem in the implementation that differs from the documentation (problem in R12B-5 to R13B01, at least) in: erl_interface-3.6.2/include/ei.h: line 332-333 int ei_unpublish(ei_cnode* ec); int ei_unpublish_tmo(const char *alive, unsigned ms); the implementation should be: int ei_unpublish(ei_cnode *) int ei_unpublish_tmo(ei_cnode *, unsigned int) as described in the documentation: http://erlang.org/doc/man/ei_connect.html despite the fact the tmo function is closer to the interface for: int erl_unpublish(const char *alive); Not sure if there are more problems like this, that is the only one I bumped into. Thanks, Michael From raimo+erlang-bugs@REDACTED Mon Jun 15 14:57:51 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 15 Jun 2009 14:57:51 +0200 Subject: [erlang-bugs] Re: gen_sctp documentation In-Reply-To: References: Message-ID: <20090615125751.GB8801@erix.ericsson.se> On Wed, Jun 03, 2009 at 12:32:04PM -0500, Anders Nygren wrote: > I forgot this thing also in the sctp_server.erl example > > {ok,S} = gen_sctp:open([{ip,IP},{port,Port}],[{sctp_recbuf,65536}]), > should be > {ok,S} = gen_sctp:open([{ip,IP},{port,Port},{recbuf,65536}]), > > /Anders > > On Wed, Jun 3, 2009 at 12:10 PM, Anders Nygren wrote: > > I have started playing with SCTP and found some errors in the documentation > > > > When receiving a sctp_paddr_change event > > - addr is supposed to be an ip_address(), but it is {ip_address(),port()} > > - state value addr_confirmed is not documented > > > > > > A number of errors in the example code > > server/0 > > should be > > server -> > > ? ?server(any,2006). > > > > server/1, ends with a ";" instead of "." > > > > server/2 > > orlese should be orelse > > sctp_recbuf should be recbuf > > > > server_loop/1 > > io:format("Error: ~p~n", [Data]) > > should be better as > > io:format("Received: ~p~n", [Data]) > > > > > > sctp_client.erl > > missing > > -include_lib("kernel/include/inet_sctp.hrl"). > > > > client/1 should be > > client([Host]) -> > > ? ?client(Host, 2006). > > > > client/1 last clause ends with ";" instead of "." > > Thank you for pointing this out. I have fixed it in R13B01. Sorry about the delay, I have already answered but into the void due to self-inflicted mailing list problems. > > > > /Anders > > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From the.ajarn@REDACTED Mon Jun 15 20:27:44 2009 From: the.ajarn@REDACTED (Brentley Jones) Date: Mon, 15 Jun 2009 13:27:44 -0500 Subject: Dialyzer and parametrized modules (semi-crash) Message-ID: First of all, I couldn't reply to my other post, so I'm sending this one separate. (If someone can help me figure out how to add on to another message I sent, it would be great). Another bug with parametrized modules, this time dealing with the - spec declaration. When using a spec declaration in a parametrized module dialyzer will semi-crash. (And before it's asked, I tried with many different specs, the one below is just the simplest I could get it to show off the error.) This only happens when using a built PLT, as calling this with -- build_plt bring up no error: $ dialyzer -c ebin --build_plt Creating PLT /Users/Ajarn/.dialyzer_plt ... done in 0m0.24s done (passed successfully) $ dialyzer -c ebin Checking whether the PLT /Users/Ajarn/.dialyzer_plt is up-to- date... yes Proceeding with analysis... =ERROR REPORT==== 14-Jun-2009::10:54:31 === Error in process <0.30.0> with exit value: {function_clause, [{dialyzer_plt,lookup,[{dialyzer_plt,{dict,13,16,16,8,80,48,{[],[],[], [],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[[{parameter,module_info, 1}|{{c,union,[{c,atom,any,unknown},none,none,none,{c,list, [{c,tuple_set,[{2,[{c,tuple,[{c,atom... dialyzer: Analysis failed with error: {function_clause, [{dialyzer_plt,lookup, [{dialyzer_plt,{dict,13,...}, {dict,...}}, {{param_w_spec,[...]},init,0}]}, {dialyzer_contracts,get_invalid_contract_warnings_funs,4}, {dialyzer_contracts,get_invalid_contract_warnings_modules,4}, {dialyzer_succ_typings,get_warnings,6}, {dialyzer_analysis_callgraph,analyze_callgraph,2}, {dialyzer_analysis_callgraph,analysis_start,2}]} Last messages in the log cache: Typesig analysis for SCC: [{parameter,instance,1}] Typesig analysis for SCC: [{parameter,test,2}] Typesig analysis for SCC: [{parameter,module_info,0}] Typesig analysis for SCC: [{parameter,new,1}] Typesig analysis for SCC: [{param_user,module_info,0}] Typesig analysis for SCC: [{param_user,module_info,1}] Typesig analysis for SCC: [{param_user,test,1}] Dataflow of one SCC: [param_w_spec] Dataflow of one SCC: [parameter] Dataflow of one SCC: [param_user] With the code below: %% param_user.erl -module(param_user). -export([test/1]). test(Module) -> M = param_w_spec:new(Module), M:init(). %% param_w_spec.erl -module(param_w_spec, [X]). -export([init/0]). -spec(init/0 :: () -> any()). init() -> ok. From egil@REDACTED Tue Jun 16 12:12:54 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 16 Jun 2009 12:12:54 +0200 Subject: [erlang-bugs] Re: issue with erlang decoding of big numbers In-Reply-To: <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> References: <1244874991.3770.ezmlm@erlang.org> <84580645-6A2C-4D06-99AB-FBB490EFA6CD@kallisys.net> Message-ID: <4A377026.1050509@erix.ericsson.se> Hi, For various reasons the fixes has not been included yet. They will be included in r13b02 along with other improvements and fixes. Regards, Bj?rn-Egil Erlang/OTP Paul Guyot wrote: > > Le 13 juin 09 ? 08:36, erlang-bugs-digest-help@REDACTED a ?crit : > >> De : Paul Mineiro >> Date : 13 juin 2009 08:36:27 HAEC >> ? : erlang-bugs@REDACTED >> Objet : issue with erlang decoding of big numbers > > [...] > >> the problem is so pervasive that i'm pausing to fix the issue to get >> some guidance from the OTP team about what is intended here. am i >> missing >> something? > > This bug was reported in October 2008 with a patch : > http://erlang.org/pipermail/erlang-bugs/2008-October/001023.html > > AFAIK, it is still not fixed in R13B01. > > Regards, > > Paul > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From zerthurd@REDACTED Wed Jun 17 05:06:43 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Wed, 17 Jun 2009 10:06:43 +0700 Subject: [erlang-bugs] Generap purpose macros DBG/2 in xmerl.hrl Message-ID: Hello After including xmerl header file with -include_lib("xmerl/include/xmerl.hrl") I have compilation error because DBG/2 already defined in my code. It seems strange to define general purpose macros like DBG in that place. BTW, xmerl does not use this macros anywhere. Thank you. -- Maxim Treskin From ulf.wiger@REDACTED Wed Jun 17 11:02:40 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 17 Jun 2009 11:02:40 +0200 Subject: [erlang-bugs] Generap purpose macros DBG/2 in xmerl.hrl In-Reply-To: References: Message-ID: <4A38B130.10301@erlang-consulting.com> Maxim Treskin wrote: > Hello > > After including xmerl header file with > -include_lib("xmerl/include/xmerl.hrl") I have compilation error because > DBG/2 already defined in my code. > It seems strange to define general purpose macros like DBG in that place. > BTW, xmerl does not use this macros anywhere. > > Thank you. > Mea culpa. In my defense, when I added those macros four years ago, xmerl was still only a proof of concept hack. (: http://jungerl.cvs.sourceforge.net/viewvc/jungerl/jungerl/lib/xmerl/inc/xmerl.hrl?revision=1.2&view=markup (The committer was Luke Gorrie, but that was just because it was non-trivial back then to use CVS/SSH from behind Ericsson's firewalls. No blame should fall on poor Luke.) BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From lars@REDACTED Wed Jun 17 12:25:57 2009 From: lars@REDACTED (Lars Thorsen) Date: Wed, 17 Jun 2009 12:25:57 +0200 Subject: [erlang-bugs] Generap purpose macros DBG/2 in xmerl.hrl In-Reply-To: References: Message-ID: <4A38C4B5.4020400@erix.ericsson.se> Hi, the DBG/0 macro is not used but the dbg/2 is used in xmerl_scan and 3 other modules. We'll fix it to the next release. ///Lars Maxim Treskin wrote: > Hello > > After including xmerl header file with > -include_lib("xmerl/include/xmerl.hrl") I have compilation error because > DBG/2 already defined in my code. > It seems strange to define general purpose macros like DBG in that place. > BTW, xmerl does not use this macros anywhere. > > Thank you. > From prikrutil@REDACTED Wed Jun 17 23:13:05 2009 From: prikrutil@REDACTED (Sergey Samokhin) Date: Wed, 17 Jun 2009 14:13:05 -0700 Subject: mnesia:report_event/1 seems to have a bug Message-ID: Hi! I think I may have found a bug in mnesia:report_event/1: events generated by this function aren't sent to another node. Please, let me know if it isn't a bug, but a feature. To reproduce the behaviour first open a new erlang shell which is supposed to catch user events as shown below: $ erl -sname a Eshell V5.7.1 (abort with ^G) (a@REDACTED)1> mnesia:start(). ok (a@REDACTED)2> mnesia:subscribe(system). {ok,a@REDACTED} (a@REDACTED)3> Recv = fun() -> receive Msg -> Msg after 100 -> timeout end end. Recv() function I've just defined will then be used to check if a user event came in. Now start another node and then connect it to the first one: $ erl -sname b Eshell V5.7.1 (abort with ^G) (b@REDACTED)1> mnesia:start(). ok (b@REDACTED)2> mnesia:change_config(extra_db_nodes, [a@REDACTED]). {ok,[a@REDACTED]} To cleanup the mailbox of a@REDACTED from mnesia_up event we must call Recv(): (a@REDACTED)4> Recv(). {mnesia_system_event,{mnesia_up,b@REDACTED}} Now that our environment is ready to show where the problem is, let's generate a user event: (b@REDACTED)3> mnesia:report_event(foobar). % <-- Custom event is generated Mnesia(nonode@REDACTED): User event: foobar ok ...and then try to receive the corresponding message on a@REDACTED: (a@REDACTED)5> Recv(). timeout % <-- there weren't messages to get from mailbox Event "foobar" hasn't been sent to a@REDACTED I don't know why, but it seems to be a bug, because the documentation to report-event/1 doesn't say that a process supposed to handle user events has to be local: "The Event may be any term and generates a {mnesia_user, Event} event for any processes that subscribe to Mnesia system events." Hope it will help developers to fix the problem (if it is a problem, of course). I use Erlang R13B: Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] -- Sergey Samokhin From nesrait@REDACTED Thu Jun 18 06:06:38 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Thu, 18 Jun 2009 05:06:38 +0100 Subject: file module documentation: no references to #file_descriptor{} Message-ID: <523869a70906172106v787fdf0bm6844ddcf75249344@mail.gmail.com> Hello! The documentation for the file module seems to be incomplete in that it doesn't include any references to the support for #file_descriptor{} (as returned by ram_file:open/2) in the functions that normally receive an io_device(). As it stands, someone (coff coff) might wrongfully assume that ram_file:open/2 also returns an io_device() and try to use it in other places where an io_device() is expected (failing of course). :) Cheers, :Davide From nesrait@REDACTED Thu Jun 18 06:46:42 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Thu, 18 Jun 2009 05:46:42 +0100 Subject: file module documentation: no references to #file_descriptor{} In-Reply-To: <523869a70906172106v787fdf0bm6844ddcf75249344@mail.gmail.com> References: <523869a70906172106v787fdf0bm6844ddcf75249344@mail.gmail.com> Message-ID: <523869a70906172146n2d55ba26w5d60aa3c882fea6a@mail.gmail.com> > > The documentation for the file module seems to be > incomplete in that it doesn't include any references > to the support for #file_descriptor{} (as returned by > ram_file:open/2) in the functions that normally receive > an io_device(). Upon closer inspection of file:open/2: - this function also calls ram_file:open/2 if given the *undocumented* ram option and will return an #file_descriptor{} (not an io_device()) - when using the raw option there is just a *small* reference to the fact that the return value is not an io_device() and that functionality will be limited It's just a matter of adding #file_descriptor{} where it's missing and upgrading "The functions in the io module cannot be used, because they can only talk to an Erlang process. Instead, use the read/2 and write/2 functions." to a more visible green box. :) :Davide From raimo+erlang-bugs@REDACTED Thu Jun 18 09:50:01 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 18 Jun 2009 09:50:01 +0200 Subject: [erlang-bugs] Re: file module documentation: no references to #file_descriptor{} In-Reply-To: <523869a70906172146n2d55ba26w5d60aa3c882fea6a@mail.gmail.com> References: <523869a70906172106v787fdf0bm6844ddcf75249344@mail.gmail.com> <523869a70906172146n2d55ba26w5d60aa3c882fea6a@mail.gmail.com> Message-ID: <20090618075001.GB18406@erix.ericsson.se> On Thu, Jun 18, 2009 at 05:46:42AM +0100, Davide Marqu?s wrote: > > > > The documentation for the file module seems to be > > incomplete in that it doesn't include any references > > to the support for #file_descriptor{} (as returned by > > ram_file:open/2) in the functions that normally receive > > an io_device(). > > > Upon closer inspection of file:open/2: > - this function also calls ram_file:open/2 if given the *undocumented* ram > option > and will return an #file_descriptor{} (not an io_device()) > - when using the raw option there is just a *small* reference to the fact > that > the return value is not an io_device() and that functionality will be > limited > > It's just a matter of adding #file_descriptor{} where it's missing and > upgrading > "The functions in the io module cannot be used, because they can only talk > to an Erlang process. Instead, use the read/2 and write/2 functions." > to a more visible green box. :) We will improve the documentation on this. Thank you for pointing it out. The docs have gradually grown oversimplified... > > :Davide -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From hans.bolinder@REDACTED Thu Jun 18 12:34:46 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 18 Jun 2009 12:34:46 +0200 Subject: [erlang-bugs] Bug in digraph:add_edge/5 In-Reply-To: References: Message-ID: <19002.6214.345412.129654@ornendil.du.uab.ericsson.se> [Crystal Din:] > Version: Erlang/OTP R13B. Bug in digraph:add_edge/5 > > >From the documentation of digraph module, it says add_edge/5 creates (or > modifies) the edge E of the digraph G. However, the > existing edges are not correctly modified. > ... Thanks for the bug report. We'll fix the bug in R13B02. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Thu Jun 18 12:36:49 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 18 Jun 2009 12:36:49 +0200 Subject: [erlang-bugs] Bug in digraph:del_path/3 In-Reply-To: References: Message-ID: <19002.6337.463191.462389@ornendil.du.uab.ericsson.se> [Crystal Din:] > Version: Erlang/OTP R13B. Bug in digraph:del_path/3 > > This function does not seem to work at all. Thanks for the bug report. We'll fix the bug in R13B02. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Thu Jun 18 12:39:25 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 18 Jun 2009 12:39:25 +0200 Subject: [erlang-bugs] Bug in dets module In-Reply-To: References: Message-ID: <19002.6493.663293.490530@ornendil.du.uab.ericsson.se> [Crystal Din:] > Version: Erlang/OTP R13B. Bug in dets module. > > If we put a delay between calling function dets:insert/2 and > dets:insert_new/2, we get different answers depending on the delay. > ... Thanks for the bug report. We'll fix the bug in R13B02. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From egil@REDACTED Thu Jun 18 14:34:13 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 18 Jun 2009 14:34:13 +0200 Subject: [erlang-bugs] erl_interface switch to ei for c node functions In-Reply-To: <4A35B764.1000108@gmail.com> References: <4A35B764.1000108@gmail.com> Message-ID: <4A3A3445.6090802@erix.ericsson.se> Thanks for reporting this. I will look into it. Regards, Bj?rn-Egil Erlang/OTP Michael Truog wrote: > I found a problem in the implementation that differs from the > documentation (problem in R12B-5 to R13B01, at least) in: > erl_interface-3.6.2/include/ei.h: line 332-333 > > int ei_unpublish(ei_cnode* ec); > int ei_unpublish_tmo(const char *alive, unsigned ms); > > the implementation should be: > int ei_unpublish(ei_cnode *) > int ei_unpublish_tmo(ei_cnode *, unsigned int) > > as described in the documentation: > http://erlang.org/doc/man/ei_connect.html > > despite the fact the tmo function is closer to the interface for: > int erl_unpublish(const char *alive); > > Not sure if there are more problems like this, that is the only one I > bumped into. > > Thanks, > Michael > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From nesrait@REDACTED Thu Jun 18 21:01:45 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Thu, 18 Jun 2009 20:01:45 +0100 Subject: epp module documentation: missing functions Message-ID: <523869a70906181201g4d83f6adl4c75d084bb9fcadf@mail.gmail.com> Hi there! Someone has done the terrific job of adding support in the epp module to receiving io_device()s in addition to disk files :) (http://erlang.org/pipermail/erlang-questions/2007-May/026803.html) but the documentation makes no reference to this feature. :\ Also... where do I place my vote for having something like Ulf Wiger's ram_file_io_server module in a future distribution + the necessary "io cleanups" for making it easier to create other things that respect the io_device() "interface"? :) Cheers, :Davide From hynek@REDACTED Thu Jun 18 22:07:52 2009 From: hynek@REDACTED (Hynek Vychodil) Date: Thu, 18 Jun 2009 22:07:52 +0200 Subject: Big binary HiPE bad match Message-ID: <4d08db370906181307u51adbb2cg5c36122e50066802@mail.gmail.com> Hello, I unfortunately found bug in HiPE big binary matching. Here is test case: -module(bad_match). -export([test/0]). test() -> P = make_pidle(100000000), <<_:4/bytes, I:32, _/bytes>> = P, I. make_pidle(N) -> make_pidle(<<>>, 0, N). make_pidle(P, N, N) -> P; make_pidle(P, I, N) -> make_pidle(<

>, I+1, N). $ erl Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.1 (abort with ^G) 1> c(bad_match). {ok,bad_match} 2> bad_match:test(). 1 3> c(bad_match,native). {ok,bad_match} 4> bad_match:test(). ** exception error: no match of right hand side value <<0,0,0,0,0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4,0,0,0,5,0,0,0,6, 0,...>> in function bad_match:test/0 in call from io:format/2 Best regards. -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try Good Data now for free: www.gooddata.com From chris.newcombe@REDACTED Sat Jun 20 15:14:52 2009 From: chris.newcombe@REDACTED (Chris Newcombe) Date: Sat, 20 Jun 2009 06:14:52 -0700 Subject: compiler crash on very long module paths Message-ID: <781dd98c0906200614t4c417d54v3931726fdcdbe5a1@mail.gmail.com> Please could the compiler be changed to not call list_to_atom/1 on module paths? We have a centralized automated build system (used by very many teams, so it's not going to change). When compiling, it happens to place modules in a fairly deep directory hierarchy (this is on linux). I don't have any control over most of that depth. Several times I've had builds fail with errors like this: # (no error logger present) error: "Error in process <0.0.0> with exit value: {system_limit,[{erlang,list_to_atom,[\"very long path ... \n" The particular compiler command was very simple erlc -W +debug_info -I ../include -o ../ebin *.erl ... it was just being run in a deep directory. Currently I'm having to work around it by truncating project and module names, which is just silly. If our build system happens to increase the directory depth any more, I might not be able to build at all. It seems unlikely that it would be essential (or a compatibility issue) to generate atoms containing full filesystem paths, so please could this be changed? many thanks, Chris From mikpe@REDACTED Mon Jun 22 11:48:31 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 22 Jun 2009 11:48:31 +0200 Subject: [erlang-bugs] Big binary HiPE bad match In-Reply-To: <4d08db370906181307u51adbb2cg5c36122e50066802@mail.gmail.com> References: <4d08db370906181307u51adbb2cg5c36122e50066802@mail.gmail.com> Message-ID: <19007.21359.689596.866801@pilspetsen.it.uu.se> Hynek Vychodil writes: > Hello, > I unfortunately found bug in HiPE big binary matching. > > Here is test case: > > -module(bad_match). > > -export([test/0]). > > test() -> > P = make_pidle(100000000), > <<_:4/bytes, I:32, _/bytes>> = P, > I. > > make_pidle(N) -> make_pidle(<<>>, 0, N). > > make_pidle(P, N, N) -> P; > make_pidle(P, I, N) -> make_pidle(<

>, I+1, N). > > $ erl > Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] > [kernel-poll:false] > > Eshell V5.7.1 (abort with ^G) > 1> c(bad_match). > {ok,bad_match} > 2> bad_match:test(). > 1 > 3> c(bad_match,native). > {ok,bad_match} > 4> bad_match:test(). > ** exception error: no match of right hand side value > <<0,0,0,0,0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4,0,0,0,5,0,0,0,6, > 0,...>> > in function bad_match:test/0 > in call from io:format/2 > > Best regards. I'll take a look at this. On what kind of machine does this happen? x86-64? Linux? From hynek@REDACTED Mon Jun 22 12:23:18 2009 From: hynek@REDACTED (Hynek Vychodil) Date: Mon, 22 Jun 2009 12:23:18 +0200 Subject: [erlang-bugs] Big binary HiPE bad match In-Reply-To: <19007.21359.689596.866801@pilspetsen.it.uu.se> References: <4d08db370906181307u51adbb2cg5c36122e50066802@mail.gmail.com> <19007.21359.689596.866801@pilspetsen.it.uu.se> Message-ID: <4d08db370906220323s4069465fg4476be6d1518300f@mail.gmail.com> $ uname -a Linux hynek-notebook 2.6.30-1-686 #1 SMP Sun Jun 14 16:11:32 UTC 2009 i686 GNU/Linux vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz Debian testing: ii erlang 1:13.b-dfsg1-1 Concurrent, real-time, distributed functional language ii erlang-base-hipe 1:13.b-dfsg1-1 Erlang/OTP HiPE enabled virtual machine and base applications On Mon, Jun 22, 2009 at 11:48 AM, Mikael Pettersson wrote: > Hynek Vychodil writes: > > Hello, > > I unfortunately found bug in HiPE big binary matching. > > > > Here is test case: > > > > -module(bad_match). > > > > -export([test/0]). > > > > test() -> > > P = make_pidle(100000000), > > <<_:4/bytes, I:32, _/bytes>> = P, > > I. > > > > make_pidle(N) -> make_pidle(<<>>, 0, N). > > > > make_pidle(P, N, N) -> P; > > make_pidle(P, I, N) -> make_pidle(<

>, I+1, N). > > > > $ erl > > Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] > > [kernel-poll:false] > > > > Eshell V5.7.1 (abort with ^G) > > 1> c(bad_match). > > {ok,bad_match} > > 2> bad_match:test(). > > 1 > > 3> c(bad_match,native). > > {ok,bad_match} > > 4> bad_match:test(). > > ** exception error: no match of right hand side value > > <<0,0,0,0,0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4,0,0,0,5,0,0,0,6, > > 0,...>> > > in function bad_match:test/0 > > in call from io:format/2 > > > > Best regards. > > I'll take a look at this. > > On what kind of machine does this happen? x86-64? Linux? > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try Good Data now for free: www.gooddata.com From mikpe@REDACTED Mon Jun 22 14:13:27 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 22 Jun 2009 14:13:27 +0200 Subject: [erlang-bugs] Big binary HiPE bad match In-Reply-To: <19007.21359.689596.866801@pilspetsen.it.uu.se> References: <4d08db370906181307u51adbb2cg5c36122e50066802@mail.gmail.com> <19007.21359.689596.866801@pilspetsen.it.uu.se> Message-ID: <19007.30055.257416.803664@pilspetsen.it.uu.se> Mikael Pettersson writes: > Hynek Vychodil writes: > > Hello, > > I unfortunately found bug in HiPE big binary matching. > > > > Here is test case: > > > > -module(bad_match). > > > > -export([test/0]). > > > > test() -> > > P = make_pidle(100000000), > > <<_:4/bytes, I:32, _/bytes>> = P, > > I. > > > > make_pidle(N) -> make_pidle(<<>>, 0, N). > > > > make_pidle(P, N, N) -> P; > > make_pidle(P, I, N) -> make_pidle(<

>, I+1, N). > > > > $ erl > > Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] > > [kernel-poll:false] > > > > Eshell V5.7.1 (abort with ^G) > > 1> c(bad_match). > > {ok,bad_match} > > 2> bad_match:test(). > > 1 > > 3> c(bad_match,native). > > {ok,bad_match} > > 4> bad_match:test(). > > ** exception error: no match of right hand side value > > <<0,0,0,0,0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4,0,0,0,5,0,0,0,6, > > 0,...>> > > in function bad_match:test/0 > > in call from io:format/2 > > > > Best regards. > > I'll take a look at this. Confirmed. Will investigate further later today. From fritchie@REDACTED Mon Jun 22 22:17:57 2009 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 22 Jun 2009 15:17:57 -0500 Subject: Minor etop patches: dropped, garbage, output width Message-ID: <19147.1245701877@snookles.snookles.com> Hi, all. I have a suggestion for patching etop (patch relative to R13B01 but can be applied to earlier releases, I think). The first patch hunk removes the messages for dropped or garbage messages: this always seems to happen when the etop-traced node is under heavy CPU load, and there's nothing the etop-using human can do about it. Using "egrep -v" to filter away the messages is tedious. The second patch hunk changes the width of the output (though without changing the width of the "----" header at the top of the columns). 20 characters isn't wide enough to display meaningful mod/fun/arity info when some module names can be a dozen or more characters long each. For communication between our support staff and developers, it's nice if "etop" would display enough data to actually be of real use. :-) -Scott --- snip --- snip --- snip --- snip --- snip --- snip --- --- otp_src_R13B01/lib/observer/src/etop_tr.erl.orig 2009-06-19 19:15:08.000000000 -0500 +++ otp_src_R13B01/lib/observer/src/etop_tr.erl 2009-06-19 19:15:18.000000000 -0500 @@ -83,13 +83,13 @@ end, nopid; handle_data(_W, {drop, D}, _) -> %% Error case we are missing data here! - io:format("Erlang top dropped data ~p~n", [D]), + %% SLF: don't care... io:format("Erlang top dropped data ~p~n", [D]), nopid; handle_data(nopid, {_, _, out, _, _}, _Store) -> %% ignore - there was probably just a 'drop' nopid; handle_data(_, G, _) -> - io:format("Erlang top got garbage ~p~n", [G]), + %% SLF: don't care... io:format("Erlang top got garbage ~p~n", [G]), nopid. elapsed({Me1, S1, Mi1}, {Me2, S2, Mi2}) -> --- otp_src_R13B01/lib/observer/src/etop_txt.erl.orig 2009-06-19 19:19:47.000000000 -0500 +++ otp_src_R13B01/lib/observer/src/etop_txt.erl 2009-06-19 19:19:35.000000000 -0500 @@ -29,7 +29,7 @@ -import(etop,[loadinfo/1,meminfo/2]). -import(etop_gui,[formatmfa/1,to_list/1]). --define(PROCFORM,"~-15w~-20s~8w~8w~8w~8w ~-20s~n"). +-define(PROCFORM,"~-15w~-20s~8w~8w~8w~8w ~-50s~n"). stop(Pid) -> Pid ! stop. From the.ajarn@REDACTED Wed Jun 24 06:25:28 2009 From: the.ajarn@REDACTED (Brentley Jones) Date: Tue, 23 Jun 2009 23:25:28 -0500 Subject: Documentation typo Message-ID: Hello, On http://erlang.org/doc/reference_manual/modules.html#4.4.2 it says module_info/0 when it should say module_info/1. From hans.bolinder@REDACTED Wed Jun 24 09:04:47 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 24 Jun 2009 09:04:47 +0200 Subject: [erlang-bugs] Documentation typo In-Reply-To: References: Message-ID: <19009.53263.995228.185792@ornendil.du.uab.ericsson.se> [Brentley Jones:] > On http://erlang.org/doc/reference_manual/modules.html#4.4.2 it says > module_info/0 when it should say module_info/1. Thanks. There will be a correction in R13B02. Best regards, Hans Bolinder, Erlang OTP team, Ericsson From john.hughes@REDACTED Wed Jun 24 18:27:11 2009 From: john.hughes@REDACTED (John Hughes) Date: Wed, 24 Jun 2009 18:27:11 +0200 Subject: Macro expansion is confused by anonymous functions Message-ID: <865926549F0B418AA88FC2E7FAFCC673@JohnsTablet2009> The following module is wrongly rejected by the macro processor: -module(bug). -define(ID(X),X). f() -> ?ID(begin fun() -> ok end, ok end). The error message is "argument mismatch for macro ''ID''". It looks as though the end that terminates the fun is matched against the begin at the start of the macro argument. Enclosing the fun in brackets makes the macro processor accept it. Omitting the ", ok" also makes the macro processor accept it, somewhat to my surprise! John From the.ajarn@REDACTED Wed Jun 24 20:32:01 2009 From: the.ajarn@REDACTED (Brentley Jones) Date: Wed, 24 Jun 2009 13:32:01 -0500 Subject: gen_server:start hangs Message-ID: Hello, I came across a weird hang when using gen_server:start. When inside Module:init/1 and it returns the wrong value, erlang:error's, erlang:exit's, or erlang:throw's, this gets passed onto the caller. But when you spawn_link a process and it dies before Module:init/1 returns, gen_server:start hangs. Here is the output and code to demonstrate it: Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async- threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> gen_server_bug:test(throw). {error,{bad_return_value,throw_fail}} 2> gen_server_bug:test(error). {error,{error_fail,[{gen_server_bug,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]}} 3> gen_server_bug:test(exit). {error,exit_fail} 4> gen_server_bug:test(spawn_bug). % hangs here... %% gen_server_bug.erl -module(gen_server_bug). -export([init/1]). -export([test/1]). test(Type) -> gen_server:start(?MODULE, Type, []). init(throw) -> erlang:throw(throw_fail), {ok, ok}; init(error) -> erlang:error(error_fail), {ok, ok}; init(exit) -> erlang:exit(exit_fail), {ok, ok}; init(spawn_bug) -> spawn_link(fun() -> erlang:exit(spawn_exit) end), %% Wait so this process dies from the linked process dieing receive after 1000 -> ok end, {ok, ok}. Also, no response on the Dialyzer bugs? ( http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1347:200906:lgkhjjcjokhpllgmkinj and http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1350:200906:nmcjgdfnlcnjelpijacl ) From hans.bolinder@REDACTED Thu Jun 25 08:35:29 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 25 Jun 2009 08:35:29 +0200 Subject: [erlang-bugs] Macro expansion is confused by anonymous functions In-Reply-To: <865926549F0B418AA88FC2E7FAFCC673@JohnsTablet2009> References: <865926549F0B418AA88FC2E7FAFCC673@JohnsTablet2009> Message-ID: <19011.6833.666392.938386@ornendil.du.uab.ericsson.se> [John Hughes:] > The following module is wrongly rejected by the macro processor: > > -module(bug). > > -define(ID(X),X). > > f() -> > ?ID(begin fun() -> ok end, ok end). > > The error message is "argument mismatch for macro ''ID''". It looks > as though the end that terminates the fun is matched against the > begin at the start of the macro argument. Enclosing the fun in > brackets makes the macro processor accept it. Omitting the ", ok" > also makes the macro processor accept it, somewhat to my surprise! What a coincidence. I found the very same bug yesterday. :) Adding this clause seems to fix the problem. macro_arg([{'fun',Lc}|[{'(',_}|_]=Toks], E, Arg) -> macro_arg(Toks, ['end'|E], [{'fun',Lc}|Arg]); There is a similar bug for 'query'/'end'. (Mnemosyne is deprecated.) BTW, I've found another bug in epp, and I'm looking for more. Thanks. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From baggett.patrick@REDACTED Fri Jun 26 01:01:04 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Thu, 25 Jun 2009 18:01:04 -0500 Subject: Building R13B01 on IRIX problems Message-ID: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> I'm having a problem building Erlang/OTP R13B01 on IRIX using MIPSpro C compiler v7.4.4. Previously, some of the R12 releases build with a bit of convincing, but now it doesn't seem to want to work. I am having two issues: 1) For some reason, the configure script detects uio.h for use, but it doesn't actually seem to be available. The IRIX manpages refer to it as a kernel/device driver interface, so it likely isn't available in user-space programs such as Erlang/OTP. This causes beam/io.c to not compile because the iovec structure isn't available though configure says it is. The last time I had this problem in R12x, I just simply #undef'd the variable and everything compiled great. Performing the same hack works, but it would be better to fix it at the configure script level. I have no knowledge of configure scripts, but I am very proficient with C, if that is of any use. I'm sure fix for that is pretty simple, though. 2) Problem that is new for R13B+, possibly earlier. I get linker errors to the "functions" __builtin_return_address() and __builtin_expect(). These are GCC-specific extensions to the C language which are not available to MIPSpro. Usually this is solved by #define'ing a macro for them. The modules with linking errors are sys_float.c and ethread.c. The configure script detects whether or not GCC is being used -- shouldn't the system be able to handle when GCC isn't used? Patrick From mikpe@REDACTED Fri Jun 26 01:34:35 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 26 Jun 2009 01:34:35 +0200 Subject: [erlang-bugs] Building R13B01 on IRIX problems In-Reply-To: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> References: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> Message-ID: <19012.2443.814130.841291@pilspetsen.it.uu.se> Patrick Baggett writes: > I'm having a problem building Erlang/OTP R13B01 on IRIX using MIPSpro C > compiler v7.4.4. Previously, some of the R12 releases build with a bit of > convincing, but now it doesn't seem to want to work. I am having two issues: Did you report those issues? I don't recall ever seeing any reports about IRIX. > 2) Problem that is new for R13B+, possibly earlier. I get linker errors to > the "functions" __builtin_return_address() and __builtin_expect(). These are > GCC-specific extensions to the C language which are not available to > MIPSpro. Usually this is solved by #define'ing a macro for them. The modules > with linking errors are sys_float.c and ethread.c. The configure script > detects whether or not GCC is being used -- shouldn't the system be able to > handle when GCC isn't used? Correct, using GCC should be optional. Prior to the linkage error there ought to be some compile-time warnings about calling undeclared functions (those __builtin_*()s). Can you see if these warnings are present and if so where they occur and if the compiler identifies their origin? (typically .h files) As far as handling !GCC, that's normally done by #ifdef tests on __GNUC__ not by heavy-weight autoconf machinery. What options did you pass to ./configure before attempting the build? Out of curiosity, why aren't you using GCC? Does MIPSpro generate better code than gcc-4.x? (gcc-3.x and older are completely obsolete). Also, you should know that not using GCC disables an important optimisation in the core Erlang VM interpreter. /Mikael From matt@REDACTED Fri Jun 26 05:26:10 2009 From: matt@REDACTED (Matt Reynolds) Date: Thu, 25 Jun 2009 20:26:10 -0700 Subject: Documentation bugs Message-ID: I'm not sure if these have already been filed, so these might be repeats. >From : http://erlang.org/doc/design_principles/events.html#4 "This function sends a message to the event manager registered as error_man, telling it to add the event handler terminal_logger. The event manager will call the callback function terminal_logger:init([]), where the argument [] is the third argument to add_handler. init is expected to return {ok, State}, where State is the internal state *fo* the event handler." I think that's either "for" or "of", but fo it is not. "Here, init does not need any *indata* and ignores its argument. Also, for terminal_logger the internal state is not used. For file_logger, the internal state is used to save the open file descriptor. init(*_Args*) -> {ok, Fd} = file:open(File, read), {ok, Fd}. " * "indata" isn't a word, maybe it meant to be "input arguments/data"? * "_Args" is the argument for terminal_logger, not file_logger. "_Args" should be "File" to match the previous code example. Thanks for all the hard work! From baggett.patrick@REDACTED Fri Jun 26 08:55:56 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 26 Jun 2009 01:55:56 -0500 Subject: [erlang-bugs] Building R13B01 on IRIX problems In-Reply-To: <19012.2443.814130.841291@pilspetsen.it.uu.se> References: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> <19012.2443.814130.841291@pilspetsen.it.uu.se> Message-ID: <52f46b6b0906252355w7c77971ch34a93d33cc2ca743@mail.gmail.com> On Thu, Jun 25, 2009 at 6:34 PM, Mikael Pettersson wrote: > Patrick Baggett writes: > > I'm having a problem building Erlang/OTP R13B01 on IRIX using MIPSpro C > > compiler v7.4.4. Previously, some of the R12 releases build with a bit > of > > convincing, but now it doesn't seem to want to work. I am having two > issues: > > Did you report those issues? I don't recall ever seeing any reports about > IRIX. > I never reported isse #1 that I was having then with uio.h. This is me reporting it now. As mentioned in previous email, #2 is a new (and more serious) issue. > > > 2) Problem that is new for R13B+, possibly earlier. I get linker errors > to > > the "functions" __builtin_return_address() and __builtin_expect(). These > are > > GCC-specific extensions to the C language which are not available to > > MIPSpro. Usually this is solved by #define'ing a macro for them. The > modules > > with linking errors are sys_float.c and ethread.c. The configure script > > detects whether or not GCC is being used -- shouldn't the system be able > to > > handle when GCC isn't used? > > Correct, using GCC should be optional. > > Prior to the linkage error there ought to be some compile-time warnings > about calling undeclared functions (those __builtin_*()s). > Can you see if these warnings are present and if so where they occur and > if the compiler identifies their origin? (typically .h files) > I did not see any warning about it, surprisingly. The only thing that I found was in erts/emulator/sys/erl_sys_unix.h about __builtin_expect, but nothing about __builtin_return_address. Anyone help here? > As far as handling !GCC, that's normally done by #ifdef tests on __GNUC__ > not by heavy-weight autoconf machinery. > > What options did you pass to ./configure before attempting the build? > I gave it "--enable-threads --disable-hipe" > > Out of curiosity, why aren't you using GCC? Does MIPSpro generate better > code than gcc-4.x? (gcc-3.x and older are completely obsolete). Also, > you should know that not using GCC disables an important optimisation > in the core Erlang VM interpreter. > MIPSpro gives vastly more efficient code than GCC 4 usually on the order of 15-25% for integer stuff on R4x00 processors, even larger gap on R10000 and later due to the multiple functional units on the processor and GCC's lack of knowledge of them (no flags to specify R10000+). For floating point, one can expect yet higher speed-ups. The issue doesn't seem to be the ability to correctly optimize code at a higher level, but that the instruction stream is god awful, and on a computer running with 5 insn/cycle but a much lower clock speeds than x86, that's a big deal. Maybe one day I can compare performances again. YMMV. I didn't know that not using GCC caused a lack of optimization at source level in the emulator. From hans.bolinder@REDACTED Fri Jun 26 09:28:03 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 26 Jun 2009 09:28:03 +0200 Subject: [erlang-bugs] Documentation bugs In-Reply-To: References: Message-ID: <19012.30851.475367.885883@ornendil.du.uab.ericsson.se> [Matt Reynolds:] > I'm not sure if these have already been filed, so these might be repeats. > > > From : http://erlang.org/doc/design_principles/events.html#4 > ... Thanks. I'll update the docs. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From mikpe@REDACTED Fri Jun 26 11:33:54 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 26 Jun 2009 11:33:54 +0200 Subject: [erlang-bugs] Building R13B01 on IRIX problems In-Reply-To: <52f46b6b0906252355w7c77971ch34a93d33cc2ca743@mail.gmail.com> References: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> <19012.2443.814130.841291@pilspetsen.it.uu.se> <52f46b6b0906252355w7c77971ch34a93d33cc2ca743@mail.gmail.com> Message-ID: <19012.38402.260725.124119@pilspetsen.it.uu.se> Patrick Baggett writes: > > Correct, using GCC should be optional. > > > > Prior to the linkage error there ought to be some compile-time warnings > > about calling undeclared functions (those __builtin_*()s). > > Can you see if these warnings are present and if so where they occur and > > if the compiler identifies their origin? (typically .h files) > > > > I did not see any warning about it, surprisingly. The only thing that I > found was in erts/emulator/sys/erl_sys_unix.h about __builtin_expect, but > nothing about __builtin_return_address. Anyone help here? I found two cases where these builtins could be called without prior checks that GCC was being used. Try the patch below. /Mikael --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ 2009-02-26 11:45:48.000000000 +0100 +++ otp-0622/erts/emulator/sys/unix/sys_float.c 2009-06-26 11:14:15.000000000 +0200 @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f int matherr(struct exception *exc) { +#if !defined(NO_FPE_SIGNALS) set_current_fp_exception((unsigned long)__builtin_return_address(0)); +#endif return 1; } --- otp-0622/erts/include/internal/ethread.h.~1~ 2009-02-26 11:45:54.000000000 +0100 +++ otp-0622/erts/include/internal/ethread.h 2009-06-26 11:24:24.000000000 +0200 @@ -681,11 +681,13 @@ ETHR_INLINE_FUNC_NAME_(ethr_write_lock)( #endif +/* __builtin_expect() is needed by both native atomics code and the fallback code */ +#if !defined(__GNUC__) || (__GNUC__ < 2) || (__GNUC__ == 2 && __GNUC_MINOR__ < 96) +#define __builtin_expect(X, Y) (X) +#endif + /* For CPU-optimised atomics, spinlocks, and rwlocks. */ #if !defined(ETHR_DISABLE_NATIVE_IMPLS) && defined(__GNUC__) -# if __GNUC__ < 3 && (__GNUC__ != 2 || __GNUC_MINOR__ < 96) -# define __builtin_expect(X, Y) (X) -# endif # if ETHR_SIZEOF_PTR == 4 # if defined(__i386__) # include "i386/ethread.h" From vlm@REDACTED Fri Jun 26 13:18:24 2009 From: vlm@REDACTED (Lev Walkin) Date: Fri, 26 Jun 2009 04:18:24 -0700 Subject: lists:usort bug 1 Message-ID: <4A44AE80.4060403@lionet.info> Version: R13B01 Documentation: === usort(Fun, List1) -> List2 Types Fun = fun(Elem1, Elem2) -> bool() Elem1 = Elem2 = term() List1 = List2 = [term()] Returns a list which contains the sorted elements of List1 where all but the first element of the elements comparing equal according to the ordering function Fun have been deleted. Fun(A, B) should return true if A comes before B in the ordering, false otherwise. === Actual behavior: 18> lists:usort(fun(A, B) -> A < B end, [a, a]). [a,a] 19> lists:usort(fun(A, B) -> A =< B end, [a, a]). [a] 20> lists:usort(fun(A, B) -> A >= B end, [a, a]). [a] 21> lists:usort(fun(A, B) -> A > B end, [a, a]). [a,a] 22> Contradicts description "should return true if A comes before B in the ordering, false otherwise". -- Lev Walkin vlm@REDACTED From hans.bolinder@REDACTED Fri Jun 26 14:19:09 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 26 Jun 2009 14:19:09 +0200 Subject: [erlang-bugs] lists:usort bug 1 In-Reply-To: <4A44AE80.4060403@lionet.info> References: <4A44AE80.4060403@lionet.info> Message-ID: <19012.48317.479968.340191@ornendil.du.uab.ericsson.se> [Lev Walkin:] > usort(Fun, List1) -> List2 > > Types Fun = fun(Elem1, Elem2) -> bool() > Elem1 = Elem2 = term() > List1 = List2 = [term()] > > Returns a list which contains the sorted elements of List1 where > all but the first element of the elements comparing equal > according to the ordering function Fun have been deleted. Fun(A, > B) should return true if A comes before B in the ordering, false > otherwise. > > Actual behavior: > > 18> lists:usort(fun(A, B) -> A < B end, [a, a]). > [a,a] > 19> lists:usort(fun(A, B) -> A =< B end, [a, a]). > [a] > 20> lists:usort(fun(A, B) -> A >= B end, [a, a]). > [a] > 21> lists:usort(fun(A, B) -> A > B end, [a, a]). > [a,a] > 22> > > Contradicts description "should return true if A comes before B in the > ordering, false otherwise". Note that it is assumed by sort/2, usort/2, merge/3, and umerge/3 that the fun is an "ordering function". Neither /2 is an ordering function. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From erlang@REDACTED Fri Jun 26 16:06:38 2009 From: erlang@REDACTED (Peter Lund) Date: Fri, 26 Jun 2009 16:06:38 +0200 Subject: [erlang-bugs] lists:usort bug 1 In-Reply-To: <19012.48317.479968.340191@ornendil.du.uab.ericsson.se> References: <4A44AE80.4060403@lionet.info> <19012.48317.479968.340191@ornendil.du.uab.ericsson.se> Message-ID: <4A44D5EE.2040904@lundata.se> Looks like an interface change that has taken place somewhere between R9C-0 and R12B-3. Hopefully it is well documented in some release doc... :) /Peter Hans Bolinder skrev: >> Actual behavior: >> >> 18> lists:usort(fun(A, B) -> A < B end, [a, a]). >> [a,a] >> 19> lists:usort(fun(A, B) -> A =< B end, [a, a]). >> [a] >> 20> lists:usort(fun(A, B) -> A >= B end, [a, a]). >> [a] >> 21> lists:usort(fun(A, B) -> A > B end, [a, a]). >> [a,a] >> 22> >> >> Contradicts description "should return true if A comes before B in the >> ordering, false otherwise". >> > > Note that it is assumed by sort/2, usort/2, merge/3, and umerge/3 that > the fun is an "ordering function". Neither /2 is an ordering > function. > > Best regards, > > Hans Bolinder, Erlang/OTP team, Ericsson > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From hans.bolinder@REDACTED Fri Jun 26 16:30:59 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 26 Jun 2009 16:30:59 +0200 Subject: [erlang-bugs] lists:usort bug 1 In-Reply-To: <4A44D5EE.2040904@lundata.se> References: <4A44AE80.4060403@lionet.info> <19012.48317.479968.340191@ornendil.du.uab.ericsson.se> <4A44D5EE.2040904@lundata.se> Message-ID: <19012.56227.720679.812518@ornendil.du.uab.ericsson.se> [Peter Lund:] > Looks like an interface change that has taken place somewhere between > R9C-0 and R12B-3. > Hopefully it is well documented in some release doc... :) The change is a consequence of a bugfix in R9B (STDLIB 1.11.0): lists:sort/2 and lists:merge/3 were not stable. lists:ukeysort/3 and lists:usort/2 could leave duplicates. A bug in lists:umerge/3 has been fixed. (Own Id: OTP-4204) Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From mjtruog@REDACTED Fri Jun 26 21:47:16 2009 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 26 Jun 2009 12:47:16 -0700 Subject: init:get_arguments() lacks -env assignments Message-ID: <4A4525C4.9080302@gmail.com> It would be nice if the -env flags would be passed onto the higher layers so they are accessible in the init module. That way, programs that use the slave module can pass on the same environment to other machines, assuming they are all setup the same. I do not know of other command line flags that are inaccessible within the Erlang VM by the init module, the documentation doesn't mention any. All the init functions are affected, not just get_arguments(). An example is below: $ erl -env A_SHELL_VARIABLE 1 Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> init:get_arguments(). [{root,["/home/user/installed/lib/erlang"]}, {progname,["erl"]}, {home,["/home/user"]}] 2> Thanks, Michael Truog From baggett.patrick@REDACTED Fri Jun 26 21:52:54 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 26 Jun 2009 14:52:54 -0500 Subject: [erlang-bugs] Building R13B01 on IRIX problems In-Reply-To: <19012.38402.260725.124119@pilspetsen.it.uu.se> References: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> <19012.2443.814130.841291@pilspetsen.it.uu.se> <52f46b6b0906252355w7c77971ch34a93d33cc2ca743@mail.gmail.com> <19012.38402.260725.124119@pilspetsen.it.uu.se> Message-ID: <52f46b6b0906261252i299cb972i96f6dd8d6d717169@mail.gmail.com> Thanks for the quick response! I'll check that out tonight. Can anyone who is proficient with configure scripts modify it so that iovec/uio isn't allowed on IRIX? Patrick On Fri, Jun 26, 2009 at 4:33 AM, Mikael Pettersson wrote: > Patrick Baggett writes: > > > Correct, using GCC should be optional. > > > > > > Prior to the linkage error there ought to be some compile-time > warnings > > > about calling undeclared functions (those __builtin_*()s). > > > Can you see if these warnings are present and if so where they occur > and > > > if the compiler identifies their origin? (typically .h files) > > > > > > > I did not see any warning about it, surprisingly. The only thing that I > > found was in erts/emulator/sys/erl_sys_unix.h about __builtin_expect, > but > > nothing about __builtin_return_address. Anyone help here? > > I found two cases where these builtins could be called without > prior checks that GCC was being used. Try the patch below. > > /Mikael > > --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ 2009-02-26 > 11:45:48.000000000 +0100 > +++ otp-0622/erts/emulator/sys/unix/sys_float.c 2009-06-26 > 11:14:15.000000000 +0200 > @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f > int > matherr(struct exception *exc) > { > +#if !defined(NO_FPE_SIGNALS) > set_current_fp_exception((unsigned long)__builtin_return_address(0)); > +#endif > return 1; > } > --- otp-0622/erts/include/internal/ethread.h.~1~ 2009-02-26 > 11:45:54.000000000 +0100 > +++ otp-0622/erts/include/internal/ethread.h 2009-06-26 > 11:24:24.000000000 +0200 > @@ -681,11 +681,13 @@ ETHR_INLINE_FUNC_NAME_(ethr_write_lock)( > > #endif > > +/* __builtin_expect() is needed by both native atomics code and the > fallback code */ > +#if !defined(__GNUC__) || (__GNUC__ < 2) || (__GNUC__ == 2 && > __GNUC_MINOR__ < 96) > +#define __builtin_expect(X, Y) (X) > +#endif > + > /* For CPU-optimised atomics, spinlocks, and rwlocks. */ > #if !defined(ETHR_DISABLE_NATIVE_IMPLS) && defined(__GNUC__) > -# if __GNUC__ < 3 && (__GNUC__ != 2 || __GNUC_MINOR__ < 96) > -# define __builtin_expect(X, Y) (X) > -# endif > # if ETHR_SIZEOF_PTR == 4 > # if defined(__i386__) > # include "i386/ethread.h" > From baggett.patrick@REDACTED Sat Jun 27 02:30:41 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 26 Jun 2009 19:30:41 -0500 Subject: [erlang-bugs] Building R13B01 on IRIX problems In-Reply-To: <19012.38402.260725.124119@pilspetsen.it.uu.se> References: <52f46b6b0906251601r55d5f1e4o105a19b206ff6b5d@mail.gmail.com> <19012.2443.814130.841291@pilspetsen.it.uu.se> <52f46b6b0906252355w7c77971ch34a93d33cc2ca743@mail.gmail.com> <19012.38402.260725.124119@pilspetsen.it.uu.se> Message-ID: <52f46b6b0906261730k91ee2em56d2635d1cc38fdf@mail.gmail.com> Mikael patch fixed the build issue. Thanks for the help! I've noticed another rather odd bug. When the makefile does "depend", the options -MG and -MM are given the compiler, which are GCC specific as well. On MIPSpro, the equivalent is -M, and giving it -MG and -MM causes it to generate dependencies as expected, but also compiles the file (!) and gives warnings about the intermediate compiler file /tmp/.o not found. I can't find where the -MM and -MG options are being added. Could anyone help with that? Everytime I type gmake, it rebuilds a ton of files! Patrick From baggett.patrick@REDACTED Sat Jun 27 22:35:36 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Sat, 27 Jun 2009 15:35:36 -0500 Subject: Syntax Error in erl_resolve.c Message-ID: <52f46b6b0906271335g3970b4e4mafb7141faed35e1c@mail.gmail.com> When compiling Erlang on IRIX using MIPSpro CC, I get the following error: cc-1117 c99: ERROR File = legacy/erl_resolve.c, Line = 42 An expression appears after a "return" in a "void" function. return ei_init_resolve(); This isn't valid C99 code. It should be: ei_init_resolve(); return; Changing that allows for the code to continue. Can anyone push this change? Patrick From baggett.patrick@REDACTED Sun Jun 28 00:29:39 2009 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Sat, 27 Jun 2009 17:29:39 -0500 Subject: Another IRIX build problem Message-ID: <52f46b6b0906271529h37fd6e5v8bd757ef9e0fd15a@mail.gmail.com> When compiling Erlang on IRIX with MIPSpro 7.4.4, I get: cc-1196 c99: WARNING File = memsup.c, Line = 460 The indicated function is declared implicitly. if (get_extended_mem_sgi(me)) return; ^ The reason is that the prototype's definition in the same file is surrounded by #if defined(__sgi__), and it needs to be changed to __sgi. Can anyone push this quick fix? From egil@REDACTED Sun Jun 28 19:59:16 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Sun, 28 Jun 2009 19:59:16 +0200 Subject: [erlang-bugs] Syntax Error in erl_resolve.c In-Reply-To: <52f46b6b0906271335g3970b4e4mafb7141faed35e1c@mail.gmail.com> References: <52f46b6b0906271335g3970b4e4mafb7141faed35e1c@mail.gmail.com> Message-ID: <4A47AF74.3080208@erix.ericsson.se> Thanks for reporting this. It will be fixed in the r13b02 release Regards, Bj?rn-Egil Erlang/OTP Patrick Baggett wrote: > When compiling Erlang on IRIX using MIPSpro CC, I get the following error: > cc-1117 c99: ERROR File = legacy/erl_resolve.c, Line = 42 > An expression appears after a "return" in a "void" function. > > return ei_init_resolve(); > > This isn't valid C99 code. It should be: > > ei_init_resolve(); > return; > > Changing that allows for the code to continue. Can anyone push this change? > > Patrick > From egil@REDACTED Sun Jun 28 20:02:16 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Sun, 28 Jun 2009 20:02:16 +0200 Subject: [erlang-bugs] Another IRIX build problem In-Reply-To: <52f46b6b0906271529h37fd6e5v8bd757ef9e0fd15a@mail.gmail.com> References: <52f46b6b0906271529h37fd6e5v8bd757ef9e0fd15a@mail.gmail.com> Message-ID: <4A47B028.3080507@erix.ericsson.se> Thank you for reporting this also. I will add the "or" __sgi define too. It will be fixed to r13b02 release. Regards, Bj?rn-Egil Erlang/OTP Patrick Baggett wrote: > When compiling Erlang on IRIX with MIPSpro 7.4.4, I get: > > cc-1196 c99: WARNING File = memsup.c, Line = 460 > The indicated function is declared implicitly. > > if (get_extended_mem_sgi(me)) return; > ^ > > The reason is that the prototype's definition in the same file is surrounded > by #if defined(__sgi__), and it needs to be changed to __sgi. Can anyone > push this quick fix? > From hans.bolinder@REDACTED Mon Jun 29 10:46:19 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 29 Jun 2009 10:46:19 +0200 Subject: [erlang-bugs] lists:usort bug 1 In-Reply-To: <20090626185109.GA2914@contorpis.lisalinda.com> References: <4A44AE80.4060403@lionet.info> <19012.48317.479968.340191@ornendil.du.uab.ericsson.se> <20090626185109.GA2914@contorpis.lisalinda.com> Message-ID: <19016.32603.128800.524883@ornendil.du.uab.ericsson.se> [Matthias Lang:] > > [Lev Walkin:] > > > usort(Fun, List1) -> List2 > ... > > > > ordering function Fun... Fun(A, B) should return true if > > > A comes before B in the ordering, false otherwise. > ... > > > Contradicts description "should return true if A comes before B in the > > > ordering, false otherwise". > > > Note that it is assumed by sort/2, usort/2, merge/3, and umerge/3 that > > the fun is an "ordering function". Neither /2 is an ordering > > function. > > Your answer confuses me. You're not explicitly disagreeing with the > bug report, but it seems like you implicitly are. I could have been more explicit when explaining that the counterexamples were bogus since the funs are no ordering functions. Thanks for pointing it out. If a given fun fails to be an ordering function, the results of the sort and merge functions are not well defined, and actually changed in R9C (STDLIB 1.12.3, I think), as pointed out by Peter Lund. BTW, I erroneously referred to a ticket in R9B when replying to Peter's mail. The correct ticket, OTP-4517 (which isn't mentioned in the release notes) is about an optimization that happened to change the behaviour for funs that don't define a total ordering. > I think '=<'/2 is an ordering function. If it isn't, why not? It is an ordering function; it is antisymmetric, transitive, and total. The phrase "A comes before B in the ordering" dates back to 1999, when sort/2 was introduced. It was suggested in http://www1.erlang.org/pipermail/erlang-bugs/2008-August/000929.html to change it to "should return true if A compares less than or equal to B in the ordering, false otherwise", and I now think that is a good idea. It probably won't hurt to mention '=<'/2 as an example of an ordering function as well, and to point out that '<'/2 is not an ordering function (it is not total). Best regards, Hans Bolinder, Erlang/OTP team, Ericsson