From stupalo@REDACTED Mon Mar 2 15:13:32 2009 From: stupalo@REDACTED (=?ISO-8859-1?Q?G=F6ran_Stupalo?=) Date: Mon, 02 Mar 2009 15:13:32 +0100 Subject: [erlang-bugs] release_handler_1 still broken In-Reply-To: References: Message-ID: <49ABE98C.9060506@erix.ericsson.se> Hello Paul, Thank you for the fix. It will be included in R13A. -- G?ran Stupalo, Erlang/OTP, Ericsson AB Paul Mineiro wrote: > Hey. I just upgraded to r12b5. Thanks and kudos. > > Unfortunately I noticed that release_handler_1 still fails on dynamic > child specifications. Here's a patch (the patch says sasl-2.1.5.1 but it > works with r12b5 as well; the file does not appear to have > changed). > > Cheers. > > -- p > > --- /usr/lib/erlang/lib/sasl-2.1.5.1/src/release_handler_1.erl 2007-08-05 08:48:53.000000000 -0700 > +++ release_handler_1.erl 2008-03-25 19:39:29.000000000 -0700 > @@ -505,7 +505,7 @@ > application:which_applications())). > > get_procs([{Name, Pid, worker, dynamic} | T], Sup) when is_pid(Pid) -> > - Mods = get_dynamic_mods(Name), > + Mods = get_dynamic_mods(Pid), > [{Sup, Name, Pid, Mods} | get_procs(T, Sup)]; > get_procs([{Name, Pid, worker, Mods} | T], Sup) when is_pid(Pid), is_list(Mods) -> > [{Sup, Name, Pid, Mods} | get_procs(T, Sup)]; > > > In an artificial world, only extremists live naturally. > > -- Paul Graham > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From john.hughes@REDACTED Tue Mar 3 17:44:55 2009 From: john.hughes@REDACTED (John Hughes) Date: Tue, 3 Mar 2009 17:44:55 +0100 Subject: [erlang-bugs] Documentation of group_leader seems to be wrong Message-ID: <1B824C2A25914C74926DEAB1DF299F7C@HallDesktop> The documentation of group_leader/2 says: group_leader(GroupLeader, Pid) -> true Types: GroupLeader = Pid = pid() Sets the group leader of Pid to GroupLeader. Typically, this is used when a processes started from a certain shell should have another group leader than init. As far as I can tell by experiment, though, the arguments are the other way around. I've checked this on the online documentation, as well as that documentation that came with R12-B. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Tue Mar 3 22:37:25 2009 From: john.hughes@REDACTED (John Hughes) Date: Tue, 3 Mar 2009 22:37:25 +0100 Subject: [erlang-bugs] Please ignore my message on group_leader Message-ID: I just seem to have confused myself thoroughly--sorry! John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike@REDACTED Tue Mar 3 18:47:31 2009 From: mike@REDACTED (Mike Ziebeck) Date: Tue, 03 Mar 2009 18:47:31 +0100 Subject: [erlang-bugs] erl_tar:add cannot alter archives Message-ID: <49AD6D33.3030207@ziebeck.net> Hello, using erl_tar:add existing tar archives cannot be altered. Existing file entries are dropped. The manual does not tell anything about that limit. (As it would do about e.g. module:zip) test code as follows: t() -> % delete file from previous tests file:delete( TFile="tc_01.tar"), % open, save Bin1, close {ok,Tar1}=erl_tar:open(TFile, [write]), ok=erl_tar:add(Tar1, <<"Bin1">>, "Bin1.txt",[]), ok=erl_tar:close(Tar1), % now there is an archive and in there as expected file: Bin1.txt % open, save Bin2, close {ok,Tar2}=erl_tar:open(TFile, [write]), ok=erl_tar:add(Tar2, <<"Bin2">>, "Bin2.txt",[]), ok=erl_tar:close(Tar2). % now there is an archive and in there as expected file: Bin2.txt % but file Bin1.txt is lost Chears. --mz-- From bgustavsson@REDACTED Wed Mar 4 14:15:46 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 4 Mar 2009 14:15:46 +0100 Subject: [erlang-bugs] erl_tar:add cannot alter archives In-Reply-To: <49AD6D33.3030207@ziebeck.net> References: <49AD6D33.3030207@ziebeck.net> Message-ID: <6672d0160903040515g55bb7c3fg98b0afb04104ae0e@mail.gmail.com> Thanks! On Tue, Mar 3, 2009 at 6:47 PM, Mike Ziebeck wrote: > Hello, > > using erl_tar:add existing tar archives cannot be > altered. Existing file entries are dropped. Yes. The functionality for updating existing tar files is entirely missing from erl_tar. > The manual does not tell anything about that limit. > (As it would do about e.g. module:zip) I will update the documentation in R13A. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ingela@REDACTED Thu Mar 5 16:25:18 2009 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 05 Mar 2009 16:25:18 +0100 Subject: [erlang-bugs] inets HTTP stream bugs In-Reply-To: <65b2728e0902271226y11bde54bi94e34007d97c96e3@mail.gmail.com> References: <65b2728e0902271226y11bde54bi94e34007d97c96e3@mail.gmail.com> Message-ID: <49AFEEDE.8070104@erix.ericsson.se> Hi Steve, thank you for the patch. Steve Vinoski wrote: > The following problems were found in R12B-5 by my colleague Matt > Evans, and he created and tested the attached patches for them. > > The inets HTTP code does not handle HTTP status code 206 (Partial > Content) responses when using streaming. Handling this is required > when a server streams only part of a file (i.e., a range) and thus > returns 206 rather than 200. Without this fix, on Linux the client > would just block and eat 100% of the CPU. > This part of the patch has been accepted for R13. > The patches also include a new feature, httpc_response:user_action/4, > which passes HTTP status codes other than 200 or 206 back to the > client's receive loop for handling. This allows for the handling of > redirects, for example. This adds a user_action message to the > existing stream_start, stream, stream_end, etc. message types the > client can handle. Without this addition it doesn't seem possible for > the client to fully know what the server is doing. > > Humm .. I am not quite sure this is needed. If the status code is not 200 or 206 you should get the response {http, {RequestId, Result}} that expands to {http, {RequestId, {status_line(), headers(), body()}}, where status_line() = {http_version(), status_code(), reason_phrase()} that should do the trick. Maybe we could add some more examples to the user guide and probably a few more test cases on streaming would not be a bad idea. All a question about priorities as usual. Regards Ingela Erlang/OTP - Ericsson From vinoski@REDACTED Fri Mar 6 00:17:38 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 5 Mar 2009 18:17:38 -0500 Subject: [erlang-bugs] inets HTTP stream bugs In-Reply-To: <49AFEEDE.8070104@erix.ericsson.se> References: <65b2728e0902271226y11bde54bi94e34007d97c96e3@mail.gmail.com> <49AFEEDE.8070104@erix.ericsson.se> Message-ID: <65b2728e0903051517j667523cfj411e6ee5da28dd8a@mail.gmail.com> On 3/5/09, Ingela Anderton Andin wrote: > Hi Steve, thank you for the patch. Glad to help, and thank you very much for the wonderful Erlang/OTP language and system and the great work you guys put into it. > Humm .. I am not quite sure this is needed. If the status code is not 200 > or 206 > you should get the response {http, {RequestId, Result}} > that expands to {http, {RequestId, {status_line(), headers(), body()}}, > where > status_line() = {http_version(), status_code(), reason_phrase()} that > should do the > trick. Maybe we could add some more examples to the user guide and > probably a > few more test cases on streaming would not be a bad idea. All a question > about priorities > as usual. Oops, you are of course correct -- this was operator error on our part. Sorry for the confusion. --steve From zl9d97p02@REDACTED Fri Mar 6 01:34:54 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Thu, 5 Mar 2009 16:34:54 -0800 Subject: [erlang-bugs] Can't send SCTP ABORT chunk Message-ID: <16613-46297@sneakemail.com> Under Solaris, gen_sctp:abort(Sock,SAC) always fails with {error, emsgsize} because XPG 4.2 compliance doesn't allow msg_iovlen = 0. Patch attached. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: inet_drv.c.diff Type: application/octet-stream Size: 880 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Fri Mar 6 11:15:08 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 6 Mar 2009 11:15:08 +0100 Subject: [erlang-bugs] Can't send SCTP ABORT chunk In-Reply-To: <16613-46297@sneakemail.com> References: <16613-46297@sneakemail.com> Message-ID: <20090306101507.GA3276@erix.ericsson.se> On Thu, Mar 05, 2009 at 04:34:54PM -0800, Simon Cornish wrote: > Under Solaris, gen_sctp:abort(Sock,SAC) always fails with {error, > emsgsize} because XPG 4.2 compliance doesn't allow msg_iovlen = 0. > Patch attached. > /Simon Thank you! We will probable just get it into the next release. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From johanmon@REDACTED Sat Mar 7 08:55:27 2009 From: johanmon@REDACTED (Johan Montelius) Date: Sat, 7 Mar 2009 08:55:27 +0100 Subject: [erlang-bugs] implementation of pg library not what it should be Message-ID: <01155FE84766EC4D95AEA8E070E5EC810DC87B7D31@MAIL01.ug.kth.se> Looking at the implementation of pg I think some improvements could be done. Look at how pg:join/2 is implemented. It sends a message to the group manager and then waits for a reply. Now we could of course have this strange situation: 5> pg:create(foo). ok 6> self() ! {gurka, {members, strange}}, pg:join(foo, self()). strange Since the receive statement in pg:join/2 will accept any message on the form {_,{members,_}} things will not behave as expected. The pg module is "experimental" but it doues not give the guarantees that it claims: "When messages are sent to the named group, all members of the group receive the message." This is of course only true if messages actually arrive (which is not guaranteed by Erlang send opeation). Even if send was reliable we coudl end up with only half of the members receiving a message if the group manager dies. Johan From masse@REDACTED Thu Mar 12 00:04:18 2009 From: masse@REDACTED (mats cronqvist) Date: Thu, 12 Mar 2009 00:04:18 +0100 Subject: [erlang-bugs] httpc exits Message-ID: <874oxzpsp9.fsf@dixie.cronqvi.st> In httpc_handler.erl; handle_info({tcp_closed, _}, State) -> {stop, session_remotly_closed, State}; This will generate a 300-line error report if the server we're talking to closes the socket. Is there any reason to expect that a user of the http client wants this? I sure don't. mats From masse@REDACTED Thu Mar 12 00:05:38 2009 From: masse@REDACTED (mats cronqvist) Date: Thu, 12 Mar 2009 00:05:38 +0100 Subject: [erlang-bugs] http version Message-ID: <87zlfroe2l.fsf@dixie.cronqvi.st> There appears to be a typo in inets-5.0.12 / http.erl http_options([{version, Val} | Settings], Acc) when is_atom(Val)-> http_options(Settings, Acc#http_options{version = Val}); the typo being that Val is supposed to be a string. mats From ingela@REDACTED Fri Mar 13 15:13:13 2009 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 13 Mar 2009 15:13:13 +0100 Subject: [erlang-bugs] http version In-Reply-To: <87zlfroe2l.fsf@dixie.cronqvi.st> References: <87zlfroe2l.fsf@dixie.cronqvi.st> Message-ID: <49BA69F9.9010409@erix.ericsson.se> Hi! Yes you are correct it should be is_list. It looks like it will work anyway as unknown options in this list are ignored, and our test case for this works fine. Will be fixed for R13B. Regards Ingela Erlang/OTP - Ericsson mats cronqvist wrote: > There appears to be a typo in > > inets-5.0.12 / http.erl > > http_options([{version, Val} | Settings], Acc) > when is_atom(Val)-> > http_options(Settings, Acc#http_options{version = Val}); > > the typo being that Val is supposed to be a string. > > mats > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From ingela@REDACTED Fri Mar 13 15:22:16 2009 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 13 Mar 2009 15:22:16 +0100 Subject: [erlang-bugs] httpc exits In-Reply-To: <874oxzpsp9.fsf@dixie.cronqvi.st> References: <874oxzpsp9.fsf@dixie.cronqvi.st> Message-ID: <49BA6C18.6080602@erix.ericsson.se> Hi! I suppose you are talking about SASL-reports? The client should only receive a {error, session_remotly_close} tuple. It should be fairly easy to change the implementation so that we use stop, normal and use the state to hold the reason so that terminate will send the correct message to the client. Regards Ingela Erlang/OTP - Ericsson mats cronqvist wrote: > In httpc_handler.erl; > > handle_info({tcp_closed, _}, State) -> > {stop, session_remotly_closed, State}; > > This will generate a 300-line error report if the server we're > talking to closes the socket. Is there any reason to expect that a > user of the http client wants this? I sure don't. > > mats > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From steven.charles.davis@REDACTED Sat Mar 14 16:25:27 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 14 Mar 2009 10:25:27 -0500 Subject: [erlang-bugs] wxErlang: using wxSizer with wxStaticBox causes shell crash on frame close Message-ID: <49BBCC67.9050803@gmail.com> Dan and co. This is reproable on Windows XP SP3, I don't have another platform to hand... The following function contains a line that causes a SHELL crash on frame close. Note! the exactly equivalent code using wxPanel does not cause the crash. %% Function causes shell to crash on top level window close... why? box(Parent, Opts) -> GxName = get_atom(id, Opts), Label = get_string(label, Opts), Box = wxStaticBox:new(Parent, -1, Label), %% Do sizer stuff... Sizer = wxStaticBoxSizer:new(Box, ?wxVERTICAL), wxWindow:setSizer(Box, Sizer), SizerFlags = wxSizerFlags:new(), wxSizerFlags:expand(SizerFlags), ParentSizer = wxWindow:getSizer(Parent), % layout doesn't doesn't work without the following line... wxSizer:add(ParentSizer, Sizer, SizerFlags), % ...but this sizer addition crashes the SHELL on top level window close wxSizer:fit(Sizer, Parent), gx:register(GxName, Box). BR, Steve From steven.charles.davis@REDACTED Sat Mar 14 23:41:26 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 14 Mar 2009 17:41:26 -0500 Subject: [erlang-bugs] wxErlang: using wxSizer with wxStaticBox causes shell crash on frame close In-Reply-To: <49BBCC67.9050803@gmail.com> References: <49BBCC67.9050803@gmail.com> Message-ID: <49BC3296.7090802@gmail.com> More info: This is not wxErlang per se but the wxWidgets code. While the erlang code below is "legal", the wxWidgets documentation for wxStaticBoxSizer explicitly states that it should be added as a sibling to the controls that should be visually enclosed, and not used as a parent; and that using it as a parent will cause a crash. However, perhaps wxErlang can catch that problem before it results in a complete system thread crash that takes erl/werl with it? Regs, Steve Steve Davis wrote: > Dan and co. > > This is reproable on Windows XP SP3, I don't have another platform to > hand... > > The following function contains a line that causes a SHELL crash on > frame close. > > Note! the exactly equivalent code using wxPanel does not cause the crash. > > %% Function causes shell to crash on top level window close... why? > box(Parent, Opts) -> > GxName = get_atom(id, Opts), > Label = get_string(label, Opts), > Box = wxStaticBox:new(Parent, -1, Label), > > %% Do sizer stuff... > Sizer = wxStaticBoxSizer:new(Box, ?wxVERTICAL), > wxWindow:setSizer(Box, Sizer), > SizerFlags = wxSizerFlags:new(), > wxSizerFlags:expand(SizerFlags), > ParentSizer = wxWindow:getSizer(Parent), > > % layout doesn't doesn't work without the following line... > > wxSizer:add(ParentSizer, Sizer, SizerFlags), > > % ...but this sizer addition crashes the SHELL on top level window close > > wxSizer:fit(Sizer, Parent), > gx:register(GxName, Box). > > > BR, > Steve > From steven.charles.davis@REDACTED Sun Mar 15 00:39:35 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 14 Mar 2009 18:39:35 -0500 Subject: [erlang-bugs] wxErlang: using wxSizer with wxStaticBox causes shell crash on frame close In-Reply-To: <49BC3296.7090802@gmail.com> References: <49BBCC67.9050803@gmail.com> <49BC3296.7090802@gmail.com> Message-ID: <49BC4037.5090409@gmail.com> This seems to be the correct way to deal with wxStaticBox, that is pretty unintuitive, but stable and works correctly. I post this for comparison with the code that causes the crash issue, since having the comparison may help nail things down a bit further. %% box(Parent, Opts) -> GxName = get_atom(id, Opts), Label = get_string(label, Opts), %% NOTE: wxStaticBox must be added as a first sibling, and not used as %% the parent or wxWidgets will *crash* on exit. Thus we enclose the %% box in a panel and add in the StaticBox as the first child. Panel = wxPanel:new(Parent), Sizer = wxBoxSizer:new(?wxVERTICAL), Box = wxStaticBox:new(Panel, -1, Label), BoxSizer = wxStaticBoxSizer:new(Box, ?wxVERTICAL), wxSizer:add(BoxSizer, Sizer), wxPanel:setSizer(Panel, BoxSizer), ParentSizer = wxWindow:getSizer(Parent), SizerFlags = get_sizer_flags(Opts), wxSizer:add(ParentSizer, Panel, SizerFlags), wxSizer:fit(Sizer, Parent), gx:register(GxName, Panel). Steve Davis wrote: > More info: This is not wxErlang per se but the wxWidgets code. > > While the erlang code below is "legal", the wxWidgets documentation for > wxStaticBoxSizer explicitly states that it should be added as a sibling > to the controls that should be visually enclosed, and not used as a > parent; and that using it as a parent will cause a crash. > > However, perhaps wxErlang can catch that problem before it results in a > complete system thread crash that takes erl/werl with it? > > Regs, > Steve > > Steve Davis wrote: >> Dan and co. >> >> This is reproable on Windows XP SP3, I don't have another platform to >> hand... >> >> The following function contains a line that causes a SHELL crash on >> frame close. >> >> Note! the exactly equivalent code using wxPanel does not cause the crash. >> >> %% Function causes shell to crash on top level window close... why? >> box(Parent, Opts) -> >> GxName = get_atom(id, Opts), >> Label = get_string(label, Opts), >> Box = wxStaticBox:new(Parent, -1, Label), >> >> %% Do sizer stuff... >> Sizer = wxStaticBoxSizer:new(Box, ?wxVERTICAL), >> wxWindow:setSizer(Box, Sizer), >> SizerFlags = wxSizerFlags:new(), >> wxSizerFlags:expand(SizerFlags), >> ParentSizer = wxWindow:getSizer(Parent), >> >> % layout doesn't doesn't work without the following line... >> >> wxSizer:add(ParentSizer, Sizer, SizerFlags), >> >> % ...but this sizer addition crashes the SHELL on top level window close >> >> wxSizer:fit(Sizer, Parent), gx:register(GxName, Box). >> >> >> BR, >> Steve >> > > From pguyot@REDACTED Mon Mar 16 17:07:09 2009 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 16 Mar 2009 17:07:09 +0100 Subject: [erlang-bugs] delete_module in appup Message-ID: <4C8D1A06-EF63-4C70-BB6E-054A4C83EDC2@kallisys.net> Hello, There seems to be a bug in the appup handling. delete_module appup instructions fail if the module was not previously loaded (with an interactive code server). The stack trace is as follows: {error,{'EXIT',{{badmatch,{error,beam_lib, {file_error,"non_existing.beam",enoent}}}, [{release_handler_1,get_vsn,1}, {release_handler_1,add_old_vsn,2}, {release_handler_1,eval,2}, {lists,foldl,3}, {release_handler_1,eval_script,4}, {release_handler,eval_script,4}, {release_handler,do_install_release,3}, {release_handler,handle_call,3}]}}} (this is with OTP R12B4). The workaround is to add an apply tuple to the appup recipe to make sure the module is loaded (for example by calling module_info). Regards, Paul From ulf@REDACTED Tue Mar 17 11:07:18 2009 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 17 Mar 2009 11:07:18 +0100 Subject: [erlang-bugs] dets:open_file/1 repairs when it shouldn't? Message-ID: <8209f740903170307n7e7b16cdx8491cfcee5f3ab55@mail.gmail.com> Reading the documentation for dets:open_file/1, it says: "Opens an existing table. If the table has not been properly closed, the error {error, need_repair} is returned." (http://www.erlang.org/doc/man/dets.html - R12B-5, I assume.) Yet, Eshell V5.6.4 (abort with ^G) 1> dets:open_file("dets_file",[{repair,false}]). {error,{needs_repair,"dets_file"}} 2> dets:open_file("dets_file"). dets: file "dets_file" not properly closed, repairing ... {ok,#Ref<0.0.0.41>} In other words, open_file/1 is unlikely to ever return the {error,need_repair} that the documentation talks about. It should either be described as returning {error, {'needs_repair', Fname}} (if the implementation is changed to default to {repair,false}, or the documentation should state that the file is automatically repaired. BR, Ulf W From anders.nygren@REDACTED Tue Mar 17 18:59:14 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 17 Mar 2009 11:59:14 -0600 Subject: [erlang-bugs] R13A documentation Message-ID: Hi In the documentation of erlang:system_info(Type), the possible values of type are listed in alphabetical order, except scheduler_bind_type, which is for some reason listed after {allocator_sizes, Alloc} /Anders From mike@REDACTED Tue Mar 17 21:35:36 2009 From: mike@REDACTED (Mike Ziebeck) Date: Tue, 17 Mar 2009 21:35:36 +0100 Subject: [erlang-bugs] Possible Bug in http:cookie_header(Url) Message-ID: <49C00998.1060101@ziebeck.net> Hallo, using cookies with otp's http:request/1 I was missing a correct answer from http:cookie_header(Url). It returns {"cookie",[]} where http_cookie:cookies(HEADER, "/", [46|Host]) returns [{http_cookie,[46|Host],false,Field,Value, undefined,Expiration,"/",false,false,"0"}] Test case included. Best Regards mz. cookie_test() -> Url="http://google.de", Field="set-cookie", % 1st (cookies disabled) we ask URL twice and get 2 different cookies inets:start(), {ok,{_,H1,_}}=http:request(Url), Cookie1=proplists:get_value(Field, H1), {cookie_1,true}={cookie_1,(undefined=/=Cookie1)}, % get sure it is defined {ok,{_,H2,_}}=http:request(Url), Cookie2=proplists:get_value(Field, H2), {cookie_2,true}={cookie_2,(undefined=/=Cookie2)}, % get sure it is defined true=(Cookie1=/=Cookie2), % get sure both differ inets:stop(), % 2nd (cookies enabled) we ask URL twice and get a cookie only once inets:start(), http:set_options([{cookies, enabled}]), {_,_,Host,_,_,_}=http_uri:parse(Url), {ok,{_,H3,_}}=http:request(Url), Cookie3=proplists:get_value(Field, H3), {cookie_3,true}={cookie_3,(undefined=/=Cookie3)}, % get sure it is defined % ================== This will cause an exception ======================= CookieHeaderA=http:cookie_header(Url), % test http:cookie_header CookieHeaderB=http_cookie:cookies(H3, "/", [46|Host]), {CookieHeaderA,CookieHeaderA}={CookieHeaderA,CookieHeaderB}, % ========================================================================= {ok,{_,H4,_}}=http:request(Url), Cookie4=proplists:get_value(Field, H4), {cookie_4,true}={cookie_4,(undefined==Cookie4)}, % get sure it is undefined true=(Cookie3=/=Cookie4), % get sure both differ inets:stop(). Results: ** exception error: no match of right hand side value {{"cookie",[]}, [{http_cookie,".google.de",false,"PREF", "ID=d780114c65e8ea39:TM=1237321924:LM=1237321924:S=JYbYCgOBocUxi0lC", undefined,63467613124,"/",false,false, "0"}]} in function inets_tools:cookie_test/0 From rickard.s.green@REDACTED Tue Mar 17 22:10:56 2009 From: rickard.s.green@REDACTED (Rickard Green) Date: Tue, 17 Mar 2009 22:10:56 +0100 Subject: [erlang-bugs] R13A documentation Message-ID: <49C011E0.9070301@ericsson.com> > Hi > In the documentation of erlang:system_info(Type), the possible > values of type are listed in alphabetical order, except scheduler_bind_type, > which is for some reason listed after {allocator_sizes, Alloc} > > /Anders Thanks for the bug report. The argument name was changed in last minute. It will moved in R13B. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From nexes300@REDACTED Wed Mar 18 07:02:09 2009 From: nexes300@REDACTED (Charles Ahn) Date: Tue, 17 Mar 2009 23:02:09 -0700 Subject: [erlang-bugs] mnesia:clear_table bug Message-ID: Is it just me or does mnesia:clear_table now crash the process it's in when the table is already empty? ** exception error: no match of right hand side value {aborted, {{case_clause,{mnesia,{tid,12,<0.94.0>}, {tidstore ,69667,[],1}}}, [{mnesia,clear_table,1}, Charles -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: From nexes300@REDACTED Wed Mar 18 07:17:24 2009 From: nexes300@REDACTED (Charles Ahn) Date: Tue, 17 Mar 2009 23:17:24 -0700 Subject: [erlang-bugs] ssh:daemon bug, ignoring option pwdfun Message-ID: <9C6F7C95-36FB-40E3-86EE-5F03458D969D@gmail.com> When a ssh daemon is started with: ssh:daemon({0,0,0,0}, 1122, [{shell, fun ?MODULE:dispatch/1}, {pwdfun, fun is_user_authenticated/2}, {system_dir, "/erlang_test"}]) The fun is_user_authenticated/2 is not called. The function is supposed to be called with the username and the password the user is attempting to connect with and the function is supposed to return true or false. However, now users are instantly connected without being prompted for a password instead. Charles -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: From hans.bolinder@REDACTED Wed Mar 18 10:08:41 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 18 Mar 2009 10:08:41 +0100 Subject: [erlang-bugs] dets:open_file/1 repairs when it shouldn't? In-Reply-To: <8209f740903170307n7e7b16cdx8491cfcee5f3ab55@mail.gmail.com> References: <8209f740903170307n7e7b16cdx8491cfcee5f3ab55@mail.gmail.com> Message-ID: <18880.47641.387314.351923@ornendil.du.uab.ericsson.se> [Ulf Wiger:] > Reading the documentation for dets:open_file/1, it says: > > "Opens an existing table. If the table has not been properly closed, > the error {error, need_repair} is returned." > > (http://www.erlang.org/doc/man/dets.html - R12B-5, I assume.) > > Yet, > > Eshell V5.6.4 (abort with ^G) > 1> dets:open_file("dets_file",[{repair,false}]). > {error,{needs_repair,"dets_file"}} > 2> dets:open_file("dets_file"). > dets: file "dets_file" not properly closed, repairing ... > {ok,#Ref<0.0.0.41>} > > In other words, open_file/1 is unlikely to ever return the > {error,need_repair} that the documentation talks about. > > It should either be described as returning {error, {'needs_repair', > Fname}} (if the implementation is changed to default to > {repair,false}, or the documentation should state that the file is > automatically repaired. Thanks. I'll update the docs. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From raimo+erlang-bugs@REDACTED Wed Mar 18 16:11:42 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 18 Mar 2009 16:11:42 +0100 Subject: [erlang-bugs] jinterface 1.4.2 : OtpErlangRef missing hashCode method In-Reply-To: <564676F1-2773-4F7F-A7C4-FA81401C0F91@kallisys.net> References: <564676F1-2773-4F7F-A7C4-FA81401C0F91@kallisys.net> Message-ID: <20090318151142.GA12449@erix.ericsson.se> On Mon, Nov 24, 2008 at 07:07:33AM +0100, Paul Guyot wrote: > Hello, > > OtpErlangRef class (and probably others) is missing the hashCode > method, while it overrides the equal method. As a result, refs cannot > be put in a hash structure (e.g. HashMap). > > final HashMap myMap = new HashMap Object>(); > myMap.put(ref1, obj1); > assertNotNull(myMap.get(ref1)); // <-- fails > > The attached patch adds an implementation of hashCode for > OtpErlangRef, which is compatible with the equal method. > > Regards, > > Paul Thank you for pointing this out. We will try to fix it for R13B. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dgud@REDACTED Thu Mar 19 10:28:30 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 19 Mar 2009 10:28:30 +0100 Subject: [erlang-bugs] mnesia:clear_table bug In-Reply-To: References: Message-ID: <49C2103E.8090209@erix.ericsson.se> Thanks, you are calling clear_table inside your transaction, you have never been allowed to do that, but there is a bug in the error handling. Patch mnesia.erl: 2393c2393 < true -> %% Not allowed for clear_table --- > _ -> %% Not allowed for clear_table /Dan Charles Ahn wrote: > Is it just me or does mnesia:clear_table now crash the process it's in > when the table is already empty? > > ** exception error: no match of right hand side value > {aborted,{{case_clause,{mnesia,{tid,12,<0.94.0>}, > > {tidstore,69667,[],1}}}, > > [{mnesia,clear_table,1}, > > Charles > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From masse@REDACTED Mon Mar 23 17:50:03 2009 From: masse@REDACTED (mats cronqvist) Date: Mon, 23 Mar 2009 17:50:03 +0100 Subject: [erlang-bugs] inets doc Message-ID: <87iqm0fakk.fsf@sterlett.hq.kred> I was a bit confused by this (in http.html); body_format() = string() | binary() shouldn't it be; body_format() = string | binary or, if the code is to be believed; body_format() = string | any() mats From ext@REDACTED Wed Mar 25 10:18:45 2009 From: ext@REDACTED (David Sveningsson) Date: Wed, 25 Mar 2009 10:18:45 +0100 Subject: [erlang-bugs] Wrong spec for filelib:wildcard in R13A Message-ID: <49C9F6F5.1040901@sidvind.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The documentation and implementation for filelib:wildcard accepts a dirname() but the spec says atom(). This causes dialyzer to warn when using a string as Cwd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJ9vUACgkQ6pa1H/H5pqWIZQCeMT3mZWBr63SQUvJ2WtVQjYoc qIUAnjvEddk1hMB/BwFzcTZYD1iaWZKu =VfB/ -----END PGP SIGNATURE----- From hakan@REDACTED Wed Mar 25 14:10:56 2009 From: hakan@REDACTED (Hakan Mattsson) Date: Wed, 25 Mar 2009 14:10:56 +0100 (CET) Subject: [erlang-bugs] Wrong spec for filelib:wildcard in R13A In-Reply-To: <49C9F6F5.1040901@sidvind.com> References: <49C9F6F5.1040901@sidvind.com> Message-ID: On Wed, 25 Mar 2009, David Sveningsson wrote: > The documentation and implementation for filelib:wildcard accepts a > dirname() but the spec says atom(). This causes dialyzer to warn when > using a string as Cwd. Thank you for reporting this. It will be fixed to R13B. /H?kan --- H?kan Mattsson (uabhams) Erlang/OTP, Ericsson AB From matthew@REDACTED Tue Mar 31 05:26:11 2009 From: matthew@REDACTED (Matthew Dempsky) Date: Mon, 30 Mar 2009 20:26:11 -0700 Subject: [erlang-bugs] erlang:binary_to_term/1 does not correctly decode LIST_EXT records of length 0 Message-ID: >From my reading of the External Term Format chapter of the erts manual, a LIST_EXT record should still have a Tail field even when Length = 0. However, in R12B-3 and R13A, a LIST_EXT record with Length = 0 is decoded to just [] without examining Tail at all. For example: > binary_to_term(<<131,$h,2,$l,0:32,$j,$a,42>>). {[],[]} The patch below changes this to what I believe is correct behavior: > binary_to_term(<<131,$h,2,$l,0:32,$j,$a,42>>). {[],42} --- external.c.orig 2009-03-30 19:35:39.000000000 -0700 +++ external.c 2009-03-30 20:01:19.000000000 -0700 @@ -1099,7 +1099,7 @@ n = get_int32(ep); ep += 4; if (n == 0) { - *objp = NIL; + next = objp; break; } *objp = make_list(hp); From davidepesa@REDACTED Tue Mar 31 22:13:30 2009 From: davidepesa@REDACTED (Davide Pesavento) Date: Tue, 31 Mar 2009 22:13:30 +0200 Subject: [erlang-bugs] Build system ignores LDFLAGS Message-ID: <2da21fe50903311313h11e175dfwee2a6b742deacc2d@mail.gmail.com> Hello, Erlang's build system seems to ignore custom LDFLAGS. This is the QA warning shown by Portage (Gentoo Linux's package manager) after building R12B-5 with LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" QA Notice: Files built without respecting LDFLAGS have been detected Please include the following list of files in your report: /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_file_drv.so /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_ip_drv.so /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv_mt.so /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv.so /usr/lib64/erlang/lib/erl_interface-3.5.9/bin/erl_call /usr/lib64/erlang/lib/ssl-3.10/priv/bin/ssl_esock /usr/lib64/erlang/lib/asn1-1.6.2/priv/lib/asn1_erl_drv.so /usr/lib64/erlang/lib/crypto-1.5.3/priv/lib/crypto_drv.so /usr/lib64/erlang/lib/common_test-1.3.4/priv/lib/erl_rx_driver.so /usr/lib64/erlang/erts-5.6.5/bin/child_setup Before digging into the Makefiles, I'd like to know if you already have some ideas about the root cause of this issue. Thanks, Davide