From ulf@REDACTED Tue May 1 12:49:47 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 1 May 2012 12:49:47 +0200 Subject: [erlang-bugs] release_handler:find_script() behind the times Message-ID: <108EE391-5D2C-4745-8906-7308321A0337@feuerlabs.com> I'm playing around with release_handler, since it's a holiday, and I need something fun to do? Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> Appup = filename:join([code:lib_dir(stdlib), "ebin", "stdlib.appup"]). "/usr/lib/erlang/lib/stdlib-1.18/ebin/stdlib.appup" 2> rp(file:consult(Appup)). {ok,[{"1.18", [{<<"1\\.18(\\.[0-9]+)*">>,[restart_new_emulator]}, {<<"1\\.17(\\.[0-9]+)*">>,[restart_new_emulator]}, {<<"1\\.16(\\.[0-9]+)*">>,[restart_new_emulator]}], [{<<"1\\.18(\\.[0-9]+)*">>,[restart_new_emulator]}, {<<"1\\.17(\\.[0-9]+)*">>,[restart_new_emulator]}, {<<"1\\.16(\\.[0-9]+)*">>,[restart_new_emulator]}]}]} ok 3> release_handler:upgrade_script(stdlib,code:lib_dir(stdlib)). ** exception throw: {version_not_in_appup,"1.18"} in function release_handler:find_script/4 (release_handler.erl, line 501) in call from release_handler:upgrade_script/2 (release_handler.erl, line 439) Ok, an odd practice to try to upgrade an app to itself, but it was just a test. The thing to note is that release_handler:upgrade_script/2 ends up calling release_handler:find_script/4, which looks like this: find_script(App, Dir, OldVsn, UpOrDown) -> Appup = filename:join([Dir, "ebin", atom_to_list(App)++".appup"]), case file:consult(Appup) of {ok, [{NewVsn, UpFromScripts, DownToScripts}]} -> Scripts = case UpOrDown of up -> UpFromScripts; down -> DownToScripts end, case lists:keysearch(OldVsn, 1, Scripts) of {value, {_OldVsn, Script}} -> {NewVsn, Script}; false -> throw({version_not_in_appup, OldVsn}) end; {error, enoent} -> throw(no_appup_found); {error, Reason} -> throw(Reason) end. It tries to find the OldVsn using lists:keysearch/3, which can't possibly work, given the kind of .appup found in a modern OTP. Apologies for not just fixing it and submitting a patch, but there has to be a limit even to holiday fun. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ingela@REDACTED Wed May 2 12:30:45 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 2 May 2012 12:30:45 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F9A5EE2.2080106@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> Message-ID: <4FA10CD5.7000207@erix.ericsson.se> Hi! I ran your code and I think the problem is that your application is not running as root and you do not specify a system_dir. The default system_dir usually requiers root privilages. I also think we need to have some better handling of this error in ssh, we probably need to move the check so that it will be noticed earlier and give an errormessage when starting the server rather than getting an internal error when someone tries to connect. Regards Ingela Erlang OTP team -Ericsson AB** Ingela Anderton Andin wrote: > Hi! > > Fyodor Ustinov wrote: >> Hi! >> >> putty say "Server send disconnect message type 11 (by application): >> "Internal error" >> >> Erlang say: >> > Interesting! It seems like the server is trying to handle a request > for a channel that has for some reason been closed. > If i modify the patch like this ... > > diff --git a/lib/ssh/src/ssh_connection.erl > b/lib/ssh/src/ssh_connection.erl > index 8574e08..fbd4967 100644 > --- a/lib/ssh/src/ssh_connection.erl > +++ b/lib/ssh/src/ssh_connection.erl > @@ -723,11 +723,14 @@ > handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, > want_reply = WantReply}, > #connection{channel_cache = Cache} = Connection, > ConnectionPid, _) -> > if WantReply == true -> > - #channel{remote_id = RemoteId} = ChannelId = > - ssh_channel:cache_lookup(Cache, ChannelId), > - FailMsg = channel_failure_msg(RemoteId), > - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, > - Connection}; > + case ssh_channel:cache_lookup(Cache, ChannelId) of > + #channel{remote_id = RemoteId} = ChannelId -> > + FailMsg = channel_failure_msg(RemoteId), > + {{replies, [{connection_reply, ConnectionPid, > FailMsg}]}, > + Connection}; > + undefined -> %% Chanel has been closed > + {noreply, Connection} > + end; > true -> > {noreply, Connection} > end; > > ... you should not get the below crash. But I am wondering if your > application will > now behave as you expect? Can you give me any more information on the > senario > of your application. It would like to be able to write a minimal test > case that provokes > the problem. > > >> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >> ** Generic server <0.156.0> terminating >> ** Last message in was {ssh_msg,<0.157.0>, >> <<98,0,0,0,0,0,0,0,34,119,105,110,97,100,106, >> >> 64,112,117,116,116,121,46,112,114,111,106, >> >> 101,99,116,115,46,116,97,114,116,97,114,117, >> 115,46,111,114,103,1>>} >> ** When Server state == {state,server,undefined,undefined,<0.157.0>, >> {connection,[],315439,[],1, >> {ssh_cli,[#Fun]}, >> {10,128,0,10}, >> 2222, >> [{role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}], >> undefined,<0.153.0>,undefined}, >> 0, >> [{address,{10,128,0,10}}, >> {port,2222}, >> {role,server}, >> {socket_opts,[inet,{ip,{10,128,0,10}}]}, >> {ssh_opts, >> [{role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}]}], >> undefined,true} >> ** Reason for termination == >> ** {{badmatch, >> {disconnect, >> {11,"Internal error"}, >> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >> {connection,[],315439,[],1, >> {ssh_cli,[#Fun]}, >> {10,128,0,10}, >> 2222, >> [{role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}], >> undefined,<0.153.0>,undefined}}}}, >> [{ssh_connection_manager,handle_call,3, >> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} >> >> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >> Erlang ssh connection handler failed with reason: {{{badmatch, >> {disconnect, >> {11,"Internal >> error"}, >> {{replies, >> [{channel_data, >> <0.159.0>, >> {closed,0}}]}, >> >> {connection,[],315439, >> [],1, >> {ssh_cli, >> >> [#Fun]}, >> {10,128,0,10}, >> 2222, >> [{role,server}, >> {pwdfun, >> >> #Fun}, >> {shell, >> >> #Fun}], >> >> undefined,<0.153.0>, >> undefined}}}}, >> >> [{ssh_connection_manager, >> handle_call,3, >> [{file, >> >> "../src/ssh_connection_manager.erl"}, >> {line,271}]}, >> >> {gen_server,handle_msg, >> 5, >> >> [{file,"gen_server.erl"}, >> {line,588}]}, >> {proc_lib, >> init_p_do_apply,3, >> >> [{file,"proc_lib.erl"}, >> {line,227}]}]}, >> {gen_server,call, >> [<0.156.0>, >> {ssh_msg,<0.157.0>, >> <<93,0,0,0,0,0,0,32,106>>}, >> infinity]}} >> , Stacktace: [{gen_server,call,3,[{file,"gen_server.erl"},{line,188}]}, >> {ssh_connection_manager,call,3, >> >> [{file,"../src/ssh_connection_manager.erl"},{line,583}]}, >> {ssh_connection_handler,generate_event,4, >> [{file,"ssh_connection_handler.erl"},{line,804}]}, >> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >> >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >> please report this to erlang-bugs@REDACTED >> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >> ** State machine <0.157.0> terminating >> ** Last message in was {tcp,#Port<0.1845>,<<>>} >> ** When State == connected >> ** Data == {state,tcp,gen_tcp,tcp_closed, >> {ssh,server, >> {undefined,{{10,128,0,1},1076}}, >> {2,0}, >> {2,0}, >> "SSH-2.0-PuTTY_Release_0.62","SSH-2.0-Erlang", >> <<20,231,36,36,12,195,57,51,47,209,229,164,97,204,116, >> >> 116,90,0,0,0,154,100,105,102,102,105,101,45,104,101, >> >> 108,108,109,97,110,45,103,114,111,117,112,45,101, >> >> 120,99,104,97,110,103,101,45,115,104,97,50,53,54,44, >> >> 100,105,102,102,105,101,45,104,101,108,108,109,97, >> >> 110,45,103,114,111,117,112,45,101,120,99,104,97,110, >> >> 103,101,45,115,104,97,49,44,100,105,102,102,105,101, >> >> 45,104,101,108,108,109,97,110,45,103,114,111,117, >> >> 112,49,52,45,115,104,97,49,44,100,105,102,102,105, >> >> 101,45,104,101,108,108,109,97,110,45,103,114,111, >> >> 117,112,49,45,115,104,97,49,44,114,115,97,50,48,52, >> >> 56,45,115,104,97,50,53,54,44,114,115,97,49,48,50,52, >> >> 45,115,104,97,49,0,0,0,15,115,115,104,45,114,115,97, >> >> 44,115,115,104,45,100,115,115,0,0,0,159,97,101,115, >> >> 50,53,54,45,99,116,114,44,97,101,115,50,53,54,45,99, >> >> 98,99,44,114,105,106,110,100,97,101,108,45,99,98,99, >> >> 64,108,121,115,97,116,111,114,46,108,105,117,46,115, >> >> 101,44,97,101,115,49,57,50,45,99,116,114,44,97,101, >> >> 115,49,57,50,45,99,98,99,44,97,101,115,49,50,56,45, >> >> 99,116,114,44,97,101,115,49,50,56,45,99,98,99,44,98, >> >> 108,111,119,102,105,115,104,45,99,116,114,44,98,108, >> >> 111,119,102,105,115,104,45,99,98,99,44,51,100,101, >> >> 115,45,99,116,114,44,51,100,101,115,45,99,98,99,44, >> >> 97,114,99,102,111,117,114,50,53,54,44,97,114,99,102, >> >> 111,117,114,49,50,56,0,0,0,159,97,101,115,50,53,54, >> >> 45,99,116,114,44,97,101,115,50,53,54,45,99,98,99,44, >> >> 114,105,106,110,100,97,101,108,45,99,98,99,64,108, >> >> 121,115,97,116,111,114,46,108,105,117,46,115,101,44, >> >> 97,101,115,49,57,50,45,99,116,114,44,97,101,115,49, >> >> 57,50,45,99,98,99,44,97,101,115,49,50,56,45,99,116, >> >> 114,44,97,101,115,49,50,56,45,99,98,99,44,98,108, >> >> 111,119,102,105,115,104,45,99,116,114,44,98,108,111, >> >> 119,102,105,115,104,45,99,98,99,44,51,100,101,115, >> >> 45,99,116,114,44,51,100,101,115,45,99,98,99,44,97, >> >> 114,99,102,111,117,114,50,53,54,44,97,114,99,102, >> >> 111,117,114,49,50,56,0,0,0,31,104,109,97,99,45,115, >> >> 104,97,49,44,104,109,97,99,45,115,104,97,49,45,57, >> >> 54,44,104,109,97,99,45,109,100,53,0,0,0,31,104,109, >> >> 97,99,45,115,104,97,49,44,104,109,97,99,45,115,104, >> >> 97,49,45,57,54,44,104,109,97,99,45,109,100,53,0,0,0, >> >> 9,110,111,110,101,44,122,108,105,98,0,0,0,9,110,111, >> >> 110,101,44,122,108,105,98,0,0,0,0,0,0,0,0,0,0,0,0,0>>, >> <<20,68,106,202,126,189,248,249,152,175,237,102,43, >> >> 239,21,11,93,0,0,0,26,100,105,102,102,105,101,45, >> >> 104,101,108,108,109,97,110,45,103,114,111,117,112, >> >> 49,45,115,104,97,49,0,0,0,15,115,115,104,45,114,115, >> >> 97,44,115,115,104,45,100,115,115,0,0,0,19,97,101, >> >> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >> >> 99,0,0,0,19,97,101,115,49,50,56,45,99,98,99,44,51, >> >> 100,101,115,45,99,98,99,0,0,0,9,104,109,97,99,45, >> >> 115,104,97,49,0,0,0,9,104,109,97,99,45,115,104,97, >> >> 49,0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0, >> >> 9,110,111,110,101,44,122,108,105,98,0,0,0,0,0,0,0,0, >> 0,0,0,0,0>>, >> >> undefined,'diffie-hellman-group1-sha1','ssh-rsa', >> ssh_file,ssh_io,'hmac-sha1', >> <<92,89,171,169,113,136,6,188,156,238,58,144,38,214, >> 101,198,247,166,205,208>>, >> 20,'hmac-sha1', >> <<24,206,173,99,5,252,206,70,166,228,30,17,101,89,36, >> 241,175,116,238,86>>, >> 20,'aes128-cbc', >> <<45,208,196,236,205,82,244,222,24,132,67,151,22,62, >> 250,150>>, >> 16, >> <<219,113,112,85,250,220,170,249,194,198,230,158,76, >> 122,39,155>>, >> 'aes128-cbc', >> <<44,157,215,194,90,86,202,31,228,49,188,97,227,97, >> 233,144>>, >> 16, >> <<196,110,206,199,93,111,201,100,74,194,231,242,179, >> 201,15,112>>, >> none,undefined,none,undefined,none,none,true, >> infinity, >> >> 132151717501655075704740428602371821313660310182519774905429178494543592682738802201444120687073445805819575914576401425536104160589136387731343596760889931670361900328999551747697001054684538185039596790225261438983095509229017954492065022996307622720613396529860286665422597229362632923823896919144441708303, >> >> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >> 87,102,43,69,173,214>>, >> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >> 87,102,43,69,173,214>>, >> [{address,{10,128,0,10}}, >> {port,2222}, >> {role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}], >> 114,49, >> >> {{49985839305237737688589908016292087537304670681285167039328910635484947391794443232164854289884214947929742793900078775832939310627327467626874637085242037758449972175725827907772272533385534014381436171929411436926043326068534386929776710296045274502307637113679098707841881585433086106245829282665980090815, >> >> >> 8395950144135694221446766804944646771011612746974327140375413192360614631043395924085970461957169944119762874929925969231067866506208529309578676567265288403413833138477256106374779295193693244061192404399083583730265790053008130870886892278024924477046645863115470835406736499812828883753405586277633495326}, >> >> {2, >> >> 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007}}, >> >> undefined,undefined,"ssh-connection",undefined, >> >> "publickey,keyboard_interactive,password",undefined, >> undefined, >> ["ssh-rsa","ssh-dss"]}, >> #Port<0.1845>,<<>>, >> <<107,0,185,229,147,59,116,109,92,16,81,210,0,243,152,220, >> >> 153,112,133,2,156,113,5,213,202,236,150,200,184,190,61, >> >> 227,37,31,157,1,53,98,136,245,199,18,165,166,214,36,210, >> 12,92,130,17,174>>, >> undefined, >> {ssh_msg_kexinit, >> <<126,96,184,235,216,208,69,175,215,35,94,180,214,20, >> 246,141>>, >> ["diffie-hellman-group1-sha1"], >> ["ssh-rsa","ssh-dss"], >> ["aes128-cbc","3des-cbc"], >> ["aes128-cbc","3des-cbc"], >> ["hmac-sha1"], >> ["hmac-sha1"], >> ["none","zlib"], >> ["none","zlib"], >> [],[],false,0}, >> false,<0.156.0>,undefined,undefined,undefined, >> [{address,{10,128,0,10}}, >> {port,2222}, >> {role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}]} >> ** Reason for termination = >> ** {{{badmatch, >> {disconnect, >> {11,"Internal error"}, >> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >> {connection,[],315439,[],1, >> {ssh_cli,[#Fun]}, >> {10,128,0,10}, >> 2222, >> [{role,server}, >> {pwdfun,#Fun}, >> {shell,#Fun}], >> undefined,<0.153.0>,undefined}}}}, >> [{ssh_connection_manager,handle_call,3, >> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}, >> {gen_server,call, >> >> [<0.156.0>,{ssh_msg,<0.157.0>,<<93,0,0,0,0,0,0,32,106>>},infinity]}} >> >> >> >>> Hi! >>> >>> Daniel Goertzen wrote: >>>> The channel number on the putty side is 0x100, and on the Erlang >>>> side it is 0x0. Erlang is responding to SSH_MSG_CHANNEL_REQUEST >>>> using 0x0, however RFC4254 says the responses should be... >>>> >>>> >>>> byte SSH_MSG_CHANNEL_SUCCESS >>>> uint32 recipient channel >>>> >>>> >>>> byte SSH_MSG_CHANNEL_FAILURE >>>> uint32 recipient channel >>>> >>>> >>>> ...and I interpret "recipient channel" as being the Putty side, >>>> which is 0x100. Putty seems to cope when Erlang returns SUCCESS, >>>> but blows up when Erlang returns a FAILURE. >>>> >>> >>> Yes that is correct I remember correcting such a bug a long time >>> ago, checking the code however there seems to be one error handling >>> case that I missed. Could you check if >>> the following patch resolves your issue Fyodor? >>> >>> diff --git a/lib/ssh/src/ssh_connection.erl >>> b/lib/ssh/src/ssh_connection.erl >>> index 46f0c7e..8574e08 100644 >>> --- a/lib/ssh/src/ssh_connection.erl >>> +++ b/lib/ssh/src/ssh_connection.erl >>> @@ -720,10 +720,12 @@ >>> handle_msg(#ssh_msg_channel_request{request_type = "env"}, >>> >>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>> request_type = _Other, >>> - want_reply = WantReply}, >>> Connection, >>> + want_reply = WantReply}, >>> #connection{channel_cache = Cache} = Connection, >>> ConnectionPid, _) -> >>> if WantReply == true -> >>> - FailMsg = channel_failure_msg(ChannelId), >>> + #channel{remote_id = RemoteId} = ChannelId = >>> + ssh_channel:cache_lookup(Cache, ChannelId), >>> + FailMsg = channel_failure_msg(RemoteId), >>> {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>> Connection}; >>> true -> >>> >>> >>>> I could imagine this passing automated tests when both ends number >>>> their channels starting from 0. I bet randomizing the channel >>>> numbers would reveal this and maybe other issues. >>>> >>>> Dan. >>>> >>> I think you have a valid point however we have to change the >>> implementation in one way or an other to do that and that has not >>> been prioritized. >>> >>> >>> Regards Ingela Erlang/OTP team -Ericsson AB >>> >>>> >>>> On Tue, Apr 24, 2012 at 11:22 AM, Fyodor Ustinov >>> > wrote: >>>> >>>> Hi! >>>> >>>> I added this patch - did not help. >>>> >>>> http://blog.ufm.su/putty.log - this putty log. >>>> >>>> >>>> Hi! >>>> >>>> This might be a symptom of the "close race-condition"-bug >>>> reported by Daniel. The patch for that bug is >>>> >>>> diff --git a/lib/ssh/src/ssh_channel.erl >>>> b/lib/ssh/src/ssh_channel.erl >>>> index 7b600ed..1938858 100644 >>>> --- a/lib/ssh/src/ssh_channel.erl >>>> +++ b/lib/ssh/src/ssh_channel.erl >>>> @@ -1,7 +1,7 @@ >>>> %% >>>> %% %CopyrightBegin% >>>> %% >>>> -%% Copyright Ericsson AB 2008-2011. All Rights Reserved. >>>> +%% Copyright Ericsson AB 2008-2012. All Rights Reserved. >>>> %% >>>> %% The contents of this file are subject to the Erlang Public >>>> License, >>>> %% Version 1.1, (the "License"); you may not use this file >>>> except in >>>> @@ -215,7 +215,7 @@ handle_info({ssh_cm, ConnectionManager, >>>> {closed, ChannelId}}, >>>> close_sent = false} = State) -> >>>> %% To be on the safe side, i.e. the manager has already >>>> been terminated. >>>> (catch ssh_connection:close(ConnectionManager, ChannelId)), >>>> - {stop, normal, State}; >>>> + {stop, normal, State#state{close_sent = true}}; >>>> >>>> handle_info({ssh_cm, _, _} = Msg, #state{cm = >>>> ConnectionManager, >>>> channel_cb = Module, >>>> diff --git a/lib/ssh/src/ssh_connection_manager.erl >>>> b/lib/ssh/src/ssh_connection_manager.erl >>>> index e993f59..8c1f88e 100644 >>>> --- a/lib/ssh/src/ssh_connection_manager.erl >>>> +++ b/lib/ssh/src/ssh_connection_manager.erl >>>> @@ -384,9 +384,10 @@ handle_call({close, ChannelId}, _, >>>> #state{connection = Pid, connection_state = >>>> #connection{channel_cache = Cache}} = >>>> State) -> >>>> case ssh_channel:cache_lookup(Cache, ChannelId) of >>>> - #channel{remote_id = Id} -> >>>> + #channel{remote_id = Id} = Channel -> >>>> send_msg({connection_reply, Pid, >>>> ssh_connection:channel_close_msg(Id)}), >>>> + ssh_channel:cache_update(Cache, >>>> Channel#channel{sent_close = true}), >>>> {reply, ok, State}; >>>> undefined -> >>>> {reply, ok, State} >>>> >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> Daniel Goertzen wrote: >>>> >>>> Under Putty Session->Logging can you turn on "SSH Packets" >>>> and post the log showing the error? >>>> >>>> Dan. >>>> >>>> On Sun, Apr 22, 2012 at 3:58 AM, Fyodor Ustinov >>>> >>> >> wrote: >>>> >>>> Hi! >>>> >>>> Windows ssh client PuTTY show message "Disconnected: >>>> Received >>>> SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 0" >>>> while working >>>> with erlang ssh daemon. >>>> >>>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] >>>> [async-threads:0] [kernel-poll:false] >>>> >>>> WBR, >>>> Fyodor. >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> >>> > >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>>> >>>> >>>> >>>> -- *Daniel Goertzen | Senior Software >>>> Engineer* >>>> Office: 828.610.4596 | Fax: >>>> 828.322.5294 | >>>> dang@REDACTED >>>> >>>> >>> > >>>> *Network Integrity Systems | We Bring Security To Light?* >>>> >>>> 1937 Tate Blvd. SE >>>> >>>> Hickory, North Carolina, USA 28602 >>>> >>>> /Network Integrity Systems? INTERCEPTOR? Optical Network >>>> Security System is a Smart-PDS? that ensures superior >>>> protection and cost effectiveness of classified networks. >>>> For more information, visit our website >>>> at:www.networkintegritysystems.com >>>> >>>> ./ >>>> >>>> >>>> __________________________________________ >>>> INTERCEPTOR? Optical Network Security System is made in >>>> the USA for the USA. Although not an export controlled >>>> item, because of the role it plays in the assurance of the >>>> safety and integrity of National Security Information, >>>> Network Integrity Systems (NIS) is committed to compliance >>>> with the U.S. Export Administration Act. Accordingly, NIS >>>> will not ship INTERCEPTOR products to certain foreign >>>> government end users without U.S. government approval and >>>> will refuse transactions with individuals or entities that >>>> have been denied export privileges. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>>> >>>> >>>> >>>> -- >>>> *Daniel Goertzen | Senior Software Engineer* >>>> Office: 828.610.4596 | Fax: 828.322.5294 | >>>> dang@REDACTED >>>> >>>> *Network Integrity Systems | We Bring Security To Light?* >>>> >>>> 1937 Tate Blvd. SE >>>> >>>> Hickory, North Carolina, USA 28602 >>>> >>>> /Network Integrity Systems? INTERCEPTOR? Optical Network Security >>>> System is a Smart-PDS? that ensures superior protection and cost >>>> effectiveness of classified networks. For more information, visit >>>> our website at:www.networkintegritysystems.com >>>> ./ >>>> >>>> >>>> __________________________________________ >>>> INTERCEPTOR? Optical Network Security System is made in the USA for >>>> the USA. Although not an export controlled item, because of the >>>> role it plays in the assurance of the safety and integrity of >>>> National Security Information, Network Integrity Systems (NIS) is >>>> committed to compliance with the U.S. Export Administration Act. >>>> Accordingly, NIS will not ship INTERCEPTOR products to certain >>>> foreign government end users without U.S. government approval and >>>> will refuse transactions with individuals or entities that have >>>> been denied export privileges. >>>> >>>> >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ufm@REDACTED Wed May 2 13:15:19 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Wed, 02 May 2012 14:15:19 +0300 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4FA10CD5.7000207@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> <4FA10CD5.7000207@erix.ericsson.se> Message-ID: <4FA11747.9030502@ufm.su> On 02.05.2012 13:30, Ingela Anderton Andin wrote: > I ran your code and I think the problem is that your application is > not running as root and you do not specify a system_dir. The default > system_dir usually requiers root > privilages. I also think we need to have some better handling of this > error in ssh, we probably need to move the check so that it will be > noticed earlier and give an errormessage when starting the server > rather than getting an internal error when someone tries to connect. Ingela, my app running as root. This test code also running as root and perfectly work with unix ssh and not work with putty. After logon putty receive some lines (number depends on the length of the string) before crash. Windows and linux putty not working the same. WBR, Fyodor. From ingela@REDACTED Wed May 2 14:01:07 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 2 May 2012 14:01:07 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4FA11747.9030502@ufm.su> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> <4FA10CD5.7000207@erix.ericsson.se> <4FA11747.9030502@ufm.su> Message-ID: <4FA12203.5090301@erix.ericsson.se> Hi! Fyodor Ustinov wrote: > On 02.05.2012 13:30, Ingela Anderton Andin wrote: >> I ran your code and I think the problem is that your application is >> not running as root and you do not specify a system_dir. The default >> system_dir usually requiers root >> privilages. I also think we need to have some better handling of this >> error in ssh, we probably need to move the check so that it will be >> noticed earlier and give an errormessage when starting the server >> rather than getting an internal error when someone tries to connect. > Ingela, my app running as root. > > This test code also running as root and perfectly work with unix ssh > and not work with putty. After logon putty receive some lines (number > depends on the length of the string) before crash. > > Windows and linux putty not working the same. > > Ah, I see well have to do some more testing then, but I did find another place for improvement that is always something. Regards Ingela Erlang/OTP team - Ericsson AB From ingela@REDACTED Thu May 3 16:11:31 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 3 May 2012 16:11:31 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F9AD973.7010808@ufm.su> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> <4F9AD973.7010808@ufm.su> Message-ID: <4FA29213.9000909@erix.ericsson.se> Hello again! I tested this some more and found that adding a sleep in start_local_sshd would let the session be up longer before it crashed. I also traced the erlang code and I recive this message 6> (<0.61.0>) call ssh_connection:handle_msg({ssh_msg_channel_request,0,"winadj@REDACTED",true,<<>>},{connection,[],20497,[],1, {ssh_cli,[#Fun]}, "dain",2222, [{role,server}, {pwdfun,#Fun}, {system_dir,"."}, {shell,#Fun}], undefined,<0.58.0>,undefined},<0.62.0>,server) which seems to be related to this putty bug: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/winadj-success.html So maybe we can do something to make erlang server more graceful, but it looks like the root of the problem is putty. Regards Ingela Erlang/OTP team - Ericsson AB Fyodor Ustinov wrote: > On 27.04.2012 11:54, Ingela Anderton Andin wrote: >> Hi! >> >> Fyodor Ustinov wrote: >>> Hi! >>> >>> putty say "Server send disconnect message type 11 (by application): >>> "Internal error" >>> >>> Erlang say: >>> >> Interesting! It seems like the server is trying to handle a request >> for a channel that has for some reason been closed. >> If i modify the patch like this ... >> >> diff --git a/lib/ssh/src/ssh_connection.erl >> b/lib/ssh/src/ssh_connection.erl >> index 8574e08..fbd4967 100644 >> --- a/lib/ssh/src/ssh_connection.erl >> +++ b/lib/ssh/src/ssh_connection.erl >> @@ -723,11 +723,14 @@ >> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >> want_reply = WantReply}, >> #connection{channel_cache = Cache} = Connection, >> ConnectionPid, _) -> >> if WantReply == true -> >> - #channel{remote_id = RemoteId} = ChannelId = >> - ssh_channel:cache_lookup(Cache, ChannelId), >> - FailMsg = channel_failure_msg(RemoteId), >> - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >> - Connection}; >> + case ssh_channel:cache_lookup(Cache, ChannelId) of >> + #channel{remote_id = RemoteId} = ChannelId -> >> + FailMsg = channel_failure_msg(RemoteId), >> + {{replies, [{connection_reply, ConnectionPid, >> FailMsg}]}, >> + Connection}; >> + undefined -> %% Chanel has been closed >> + {noreply, Connection} >> + end; >> true -> >> {noreply, Connection} >> end; >> >> ... you should not get the below crash. But I am wondering if your >> application will >> now behave as you expect? Can you give me any more information on >> the senario >> of your application. It would like to be able to write a minimal test >> case that provokes >> the problem. > Hmm. I'll wait for the final patch. :) > > minimal test case is very simple: > %%%------------------------------------------------------------------- > > -module(sshd). > -export([start/0]). > > -export([start_local_sshd/2, pwdcheck/2]). > > > start() -> > crypto:start(), > ssh:start(), > ssh:daemon( > {172,28,3,22}, > 2222, > [{shell, fun (U,A) -> spawn(?MODULE, start_local_sshd, [U, A]) > end}, > {pwdfun, fun sshd:pwdcheck/2} > ] > ) > . > > pwdcheck(_Usr, _Pwd) -> > true > . > > start_local_sshd(U, Address) -> > > io:format("------------------------------------------------------------------------------------------------------------------------------------------------ > > ----~n"), > start_local_sshd(U, Address) > . >> >> >>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>> ** Generic server <0.156.0> terminating >>> ** Last message in was {ssh_msg,<0.157.0>, >>> <<98,0,0,0,0,0,0,0,34,119,105,110,97,100,106, >>> >>> 64,112,117,116,116,121,46,112,114,111,106, >>> >>> 101,99,116,115,46,116,97,114,116,97,114,117, >>> 115,46,111,114,103,1>>} >>> ** When Server state == {state,server,undefined,undefined,<0.157.0>, >>> {connection,[],315439,[],1, >>> {ssh_cli,[#Fun]}, >>> {10,128,0,10}, >>> 2222, >>> [{role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}], >>> undefined,<0.153.0>,undefined}, >>> 0, >>> [{address,{10,128,0,10}}, >>> {port,2222}, >>> {role,server}, >>> {socket_opts,[inet,{ip,{10,128,0,10}}]}, >>> {ssh_opts, >>> [{role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}]}], >>> undefined,true} >>> ** Reason for termination == >>> ** {{badmatch, >>> {disconnect, >>> {11,"Internal error"}, >>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>> {connection,[],315439,[],1, >>> {ssh_cli,[#Fun]}, >>> {10,128,0,10}, >>> 2222, >>> [{role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}], >>> undefined,<0.153.0>,undefined}}}}, >>> [{ssh_connection_manager,handle_call,3, >>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} >>> >>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>> Erlang ssh connection handler failed with reason: {{{badmatch, >>> {disconnect, >>> {11,"Internal >>> error"}, >>> {{replies, >>> [{channel_data, >>> <0.159.0>, >>> >>> {closed,0}}]}, >>> >>> {connection,[],315439, >>> [],1, >>> {ssh_cli, >>> >>> [#Fun]}, >>> {10,128,0,10}, >>> 2222, >>> [{role,server}, >>> {pwdfun, >>> >>> #Fun}, >>> {shell, >>> >>> #Fun}], >>> >>> undefined,<0.153.0>, >>> undefined}}}}, >>> >>> [{ssh_connection_manager, >>> handle_call,3, >>> [{file, >>> >>> "../src/ssh_connection_manager.erl"}, >>> {line,271}]}, >>> >>> {gen_server,handle_msg, >>> 5, >>> >>> [{file,"gen_server.erl"}, >>> {line,588}]}, >>> {proc_lib, >>> >>> init_p_do_apply,3, >>> >>> [{file,"proc_lib.erl"}, >>> {line,227}]}]}, >>> {gen_server,call, >>> [<0.156.0>, >>> >>> {ssh_msg,<0.157.0>, >>> <<93,0,0,0,0,0,0,32,106>>}, >>> infinity]}} >>> , Stacktace: [{gen_server,call,3,[{file,"gen_server.erl"},{line,188}]}, >>> {ssh_connection_manager,call,3, >>> >>> [{file,"../src/ssh_connection_manager.erl"},{line,583}]}, >>> {ssh_connection_handler,generate_event,4, >>> [{file,"ssh_connection_handler.erl"},{line,804}]}, >>> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >>> >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >>> please report this to erlang-bugs@REDACTED >>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>> ** State machine <0.157.0> terminating >>> ** Last message in was {tcp,#Port<0.1845>,<<>>} >>> ** When State == connected >>> ** Data == {state,tcp,gen_tcp,tcp_closed, >>> {ssh,server, >>> {undefined,{{10,128,0,1},1076}}, >>> {2,0}, >>> {2,0}, >>> "SSH-2.0-PuTTY_Release_0.62","SSH-2.0-Erlang", >>> <<20,231,36,36,12,195,57,51,47,209,229,164,97,204,116, >>> >>> 116,90,0,0,0,154,100,105,102,102,105,101,45,104,101, >>> >>> 108,108,109,97,110,45,103,114,111,117,112,45,101, >>> >>> 120,99,104,97,110,103,101,45,115,104,97,50,53,54,44, >>> >>> 100,105,102,102,105,101,45,104,101,108,108,109,97, >>> >>> 110,45,103,114,111,117,112,45,101,120,99,104,97,110, >>> >>> 103,101,45,115,104,97,49,44,100,105,102,102,105,101, >>> >>> 45,104,101,108,108,109,97,110,45,103,114,111,117, >>> >>> 112,49,52,45,115,104,97,49,44,100,105,102,102,105, >>> >>> 101,45,104,101,108,108,109,97,110,45,103,114,111, >>> >>> 117,112,49,45,115,104,97,49,44,114,115,97,50,48,52, >>> >>> 56,45,115,104,97,50,53,54,44,114,115,97,49,48,50,52, >>> >>> 45,115,104,97,49,0,0,0,15,115,115,104,45,114,115,97, >>> >>> 44,115,115,104,45,100,115,115,0,0,0,159,97,101,115, >>> >>> 50,53,54,45,99,116,114,44,97,101,115,50,53,54,45,99, >>> >>> 98,99,44,114,105,106,110,100,97,101,108,45,99,98,99, >>> >>> 64,108,121,115,97,116,111,114,46,108,105,117,46,115, >>> >>> 101,44,97,101,115,49,57,50,45,99,116,114,44,97,101, >>> >>> 115,49,57,50,45,99,98,99,44,97,101,115,49,50,56,45, >>> >>> 99,116,114,44,97,101,115,49,50,56,45,99,98,99,44,98, >>> >>> 108,111,119,102,105,115,104,45,99,116,114,44,98,108, >>> >>> 111,119,102,105,115,104,45,99,98,99,44,51,100,101, >>> >>> 115,45,99,116,114,44,51,100,101,115,45,99,98,99,44, >>> >>> 97,114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>> >>> 111,117,114,49,50,56,0,0,0,159,97,101,115,50,53,54, >>> >>> 45,99,116,114,44,97,101,115,50,53,54,45,99,98,99,44, >>> >>> 114,105,106,110,100,97,101,108,45,99,98,99,64,108, >>> >>> 121,115,97,116,111,114,46,108,105,117,46,115,101,44, >>> >>> 97,101,115,49,57,50,45,99,116,114,44,97,101,115,49, >>> >>> 57,50,45,99,98,99,44,97,101,115,49,50,56,45,99,116, >>> >>> 114,44,97,101,115,49,50,56,45,99,98,99,44,98,108, >>> >>> 111,119,102,105,115,104,45,99,116,114,44,98,108,111, >>> >>> 119,102,105,115,104,45,99,98,99,44,51,100,101,115, >>> >>> 45,99,116,114,44,51,100,101,115,45,99,98,99,44,97, >>> >>> 114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>> >>> 111,117,114,49,50,56,0,0,0,31,104,109,97,99,45,115, >>> >>> 104,97,49,44,104,109,97,99,45,115,104,97,49,45,57, >>> >>> 54,44,104,109,97,99,45,109,100,53,0,0,0,31,104,109, >>> >>> 97,99,45,115,104,97,49,44,104,109,97,99,45,115,104, >>> >>> 97,49,45,57,54,44,104,109,97,99,45,109,100,53,0,0,0, >>> >>> 9,110,111,110,101,44,122,108,105,98,0,0,0,9,110,111, >>> >>> 110,101,44,122,108,105,98,0,0,0,0,0,0,0,0,0,0,0,0,0>>, >>> <<20,68,106,202,126,189,248,249,152,175,237,102,43, >>> >>> 239,21,11,93,0,0,0,26,100,105,102,102,105,101,45, >>> >>> 104,101,108,108,109,97,110,45,103,114,111,117,112, >>> >>> 49,45,115,104,97,49,0,0,0,15,115,115,104,45,114,115, >>> >>> 97,44,115,115,104,45,100,115,115,0,0,0,19,97,101, >>> >>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >>> >>> 99,0,0,0,19,97,101,115,49,50,56,45,99,98,99,44,51, >>> >>> 100,101,115,45,99,98,99,0,0,0,9,104,109,97,99,45, >>> >>> 115,104,97,49,0,0,0,9,104,109,97,99,45,115,104,97, >>> >>> 49,0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0, >>> >>> 9,110,111,110,101,44,122,108,105,98,0,0,0,0,0,0,0,0, >>> 0,0,0,0,0>>, >>> >>> undefined,'diffie-hellman-group1-sha1','ssh-rsa', >>> ssh_file,ssh_io,'hmac-sha1', >>> <<92,89,171,169,113,136,6,188,156,238,58,144,38,214, >>> 101,198,247,166,205,208>>, >>> 20,'hmac-sha1', >>> <<24,206,173,99,5,252,206,70,166,228,30,17,101,89,36, >>> 241,175,116,238,86>>, >>> 20,'aes128-cbc', >>> <<45,208,196,236,205,82,244,222,24,132,67,151,22,62, >>> 250,150>>, >>> 16, >>> <<219,113,112,85,250,220,170,249,194,198,230,158,76, >>> 122,39,155>>, >>> 'aes128-cbc', >>> <<44,157,215,194,90,86,202,31,228,49,188,97,227,97, >>> 233,144>>, >>> 16, >>> <<196,110,206,199,93,111,201,100,74,194,231,242,179, >>> 201,15,112>>, >>> none,undefined,none,undefined,none,none,true, >>> infinity, >>> >>> 132151717501655075704740428602371821313660310182519774905429178494543592682738802201444120687073445805819575914576401425536104160589136387731343596760889931670361900328999551747697001054684538185039596790225261438983095509229017954492065022996307622720613396529860286665422597229362632923823896919144441708303, >>> >>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>> 87,102,43,69,173,214>>, >>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>> 87,102,43,69,173,214>>, >>> [{address,{10,128,0,10}}, >>> {port,2222}, >>> {role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}], >>> 114,49, >>> >>> {{49985839305237737688589908016292087537304670681285167039328910635484947391794443232164854289884214947929742793900078775832939310627327467626874637085242037758449972175725827907772272533385534014381436171929411436926043326068534386929776710296045274502307637113679098707841881585433086106245829282665980090815, >>> >>> >>> 8395950144135694221446766804944646771011612746974327140375413192360614631043395924085970461957169944119762874929925969231067866506208529309578676567265288403413833138477256106374779295193693244061192404399083583730265790053008130870886892278024924477046645863115470835406736499812828883753405586277633495326}, >>> >>> {2, >>> >>> 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007}}, >>> >>> >>> undefined,undefined,"ssh-connection",undefined, >>> >>> "publickey,keyboard_interactive,password",undefined, >>> undefined, >>> ["ssh-rsa","ssh-dss"]}, >>> #Port<0.1845>,<<>>, >>> <<107,0,185,229,147,59,116,109,92,16,81,210,0,243,152,220, >>> >>> 153,112,133,2,156,113,5,213,202,236,150,200,184,190,61, >>> >>> 227,37,31,157,1,53,98,136,245,199,18,165,166,214,36,210, >>> 12,92,130,17,174>>, >>> undefined, >>> {ssh_msg_kexinit, >>> <<126,96,184,235,216,208,69,175,215,35,94,180,214,20, >>> 246,141>>, >>> ["diffie-hellman-group1-sha1"], >>> ["ssh-rsa","ssh-dss"], >>> ["aes128-cbc","3des-cbc"], >>> ["aes128-cbc","3des-cbc"], >>> ["hmac-sha1"], >>> ["hmac-sha1"], >>> ["none","zlib"], >>> ["none","zlib"], >>> [],[],false,0}, >>> false,<0.156.0>,undefined,undefined,undefined, >>> [{address,{10,128,0,10}}, >>> {port,2222}, >>> {role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}]} >>> ** Reason for termination = >>> ** {{{badmatch, >>> {disconnect, >>> {11,"Internal error"}, >>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>> {connection,[],315439,[],1, >>> {ssh_cli,[#Fun]}, >>> {10,128,0,10}, >>> 2222, >>> [{role,server}, >>> {pwdfun,#Fun}, >>> {shell,#Fun}], >>> undefined,<0.153.0>,undefined}}}}, >>> [{ssh_connection_manager,handle_call,3, >>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>> >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}, >>> {gen_server,call, >>> >>> [<0.156.0>,{ssh_msg,<0.157.0>,<<93,0,0,0,0,0,0,32,106>>},infinity]}} >>> >>> >>> >>>> Hi! >>>> >>>> Daniel Goertzen wrote: >>>>> The channel number on the putty side is 0x100, and on the Erlang >>>>> side it is 0x0. Erlang is responding to SSH_MSG_CHANNEL_REQUEST >>>>> using 0x0, however RFC4254 says the responses should be... >>>>> >>>>> >>>>> byte SSH_MSG_CHANNEL_SUCCESS >>>>> uint32 recipient channel >>>>> >>>>> >>>>> byte SSH_MSG_CHANNEL_FAILURE >>>>> uint32 recipient channel >>>>> >>>>> >>>>> ...and I interpret "recipient channel" as being the Putty side, >>>>> which is 0x100. Putty seems to cope when Erlang returns SUCCESS, >>>>> but blows up when Erlang returns a FAILURE. >>>>> >>>> >>>> Yes that is correct I remember correcting such a bug a long time >>>> ago, checking the code however there seems to be one error handling >>>> case that I missed. Could you check if >>>> the following patch resolves your issue Fyodor? >>>> >>>> diff --git a/lib/ssh/src/ssh_connection.erl >>>> b/lib/ssh/src/ssh_connection.erl >>>> index 46f0c7e..8574e08 100644 >>>> --- a/lib/ssh/src/ssh_connection.erl >>>> +++ b/lib/ssh/src/ssh_connection.erl >>>> @@ -720,10 +720,12 @@ >>>> handle_msg(#ssh_msg_channel_request{request_type = "env"}, >>>> >>>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>>> request_type = _Other, >>>> - want_reply = WantReply}, >>>> Connection, >>>> + want_reply = WantReply}, >>>> #connection{channel_cache = Cache} = Connection, >>>> ConnectionPid, _) -> >>>> if WantReply == true -> >>>> - FailMsg = channel_failure_msg(ChannelId), >>>> + #channel{remote_id = RemoteId} = ChannelId = >>>> + ssh_channel:cache_lookup(Cache, ChannelId), >>>> + FailMsg = channel_failure_msg(RemoteId), >>>> {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>>> Connection}; >>>> true -> >>>> >>>> >>>>> I could imagine this passing automated tests when both ends number >>>>> their channels starting from 0. I bet randomizing the channel >>>>> numbers would reveal this and maybe other issues. >>>>> >>>>> Dan. >>>>> >>>> I think you have a valid point however we have to change the >>>> implementation in one way or an other to do that and that has not >>>> been prioritized. >>>> >>>> >>>> Regards Ingela Erlang/OTP team -Ericsson AB >>>> >>>>> >>>>> On Tue, Apr 24, 2012 at 11:22 AM, Fyodor Ustinov >>>> > wrote: >>>>> >>>>> Hi! >>>>> >>>>> I added this patch - did not help. >>>>> >>>>> http://blog.ufm.su/putty.log - this putty log. >>>>> >>>>> >>>>> Hi! >>>>> >>>>> This might be a symptom of the "close race-condition"-bug >>>>> reported by Daniel. The patch for that bug is >>>>> >>>>> diff --git a/lib/ssh/src/ssh_channel.erl >>>>> b/lib/ssh/src/ssh_channel.erl >>>>> index 7b600ed..1938858 100644 >>>>> --- a/lib/ssh/src/ssh_channel.erl >>>>> +++ b/lib/ssh/src/ssh_channel.erl >>>>> @@ -1,7 +1,7 @@ >>>>> %% >>>>> %% %CopyrightBegin% >>>>> %% >>>>> -%% Copyright Ericsson AB 2008-2011. All Rights Reserved. >>>>> +%% Copyright Ericsson AB 2008-2012. All Rights Reserved. >>>>> %% >>>>> %% The contents of this file are subject to the Erlang Public >>>>> License, >>>>> %% Version 1.1, (the "License"); you may not use this file >>>>> except in >>>>> @@ -215,7 +215,7 @@ handle_info({ssh_cm, ConnectionManager, >>>>> {closed, ChannelId}}, >>>>> close_sent = false} = State) -> >>>>> %% To be on the safe side, i.e. the manager has already >>>>> been terminated. >>>>> (catch ssh_connection:close(ConnectionManager, >>>>> ChannelId)), >>>>> - {stop, normal, State}; >>>>> + {stop, normal, State#state{close_sent = true}}; >>>>> >>>>> handle_info({ssh_cm, _, _} = Msg, #state{cm = >>>>> ConnectionManager, >>>>> channel_cb = Module, >>>>> diff --git a/lib/ssh/src/ssh_connection_manager.erl >>>>> b/lib/ssh/src/ssh_connection_manager.erl >>>>> index e993f59..8c1f88e 100644 >>>>> --- a/lib/ssh/src/ssh_connection_manager.erl >>>>> +++ b/lib/ssh/src/ssh_connection_manager.erl >>>>> @@ -384,9 +384,10 @@ handle_call({close, ChannelId}, _, >>>>> #state{connection = Pid, connection_state = >>>>> #connection{channel_cache = Cache}} = >>>>> State) -> >>>>> case ssh_channel:cache_lookup(Cache, ChannelId) of >>>>> - #channel{remote_id = Id} -> >>>>> + #channel{remote_id = Id} = Channel -> >>>>> send_msg({connection_reply, Pid, >>>>> ssh_connection:channel_close_msg(Id)}), >>>>> + ssh_channel:cache_update(Cache, >>>>> Channel#channel{sent_close = true}), >>>>> {reply, ok, State}; >>>>> undefined -> >>>>> {reply, ok, State} >>>>> >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> Daniel Goertzen wrote: >>>>> >>>>> Under Putty Session->Logging can you turn on "SSH >>>>> Packets" >>>>> and post the log showing the error? >>>>> >>>>> Dan. >>>>> >>>>> On Sun, Apr 22, 2012 at 3:58 AM, Fyodor Ustinov >>>>> >>>> >> wrote: >>>>> >>>>> Hi! >>>>> >>>>> Windows ssh client PuTTY show message "Disconnected: >>>>> Received >>>>> SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 0" >>>>> while working >>>>> with erlang ssh daemon. >>>>> >>>>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] >>>>> [async-threads:0] [kernel-poll:false] >>>>> >>>>> WBR, >>>>> Fyodor. >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> >>>> > >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>>> >>>>> >>>>> >>>>> -- *Daniel Goertzen | Senior Software >>>>> Engineer* >>>>> Office: 828.610.4596 | Fax: >>>>> 828.322.5294 | >>>>> dang@REDACTED >>>>> >>>>> >>>> > >>>>> *Network Integrity Systems | We Bring Security To Light?* >>>>> >>>>> 1937 Tate Blvd. SE >>>>> >>>>> Hickory, North Carolina, USA 28602 >>>>> >>>>> /Network Integrity Systems? INTERCEPTOR? Optical Network >>>>> Security System is a Smart-PDS? that ensures superior >>>>> protection and cost effectiveness of classified networks. >>>>> For more information, visit our website >>>>> at:www.networkintegritysystems.com >>>>> >>>>> ./ >>>>> >>>>> >>>>> __________________________________________ >>>>> INTERCEPTOR? Optical Network Security System is made in >>>>> the USA for the USA. Although not an export controlled >>>>> item, because of the role it plays in the assurance of >>>>> the >>>>> safety and integrity of National Security Information, >>>>> Network Integrity Systems (NIS) is committed to >>>>> compliance >>>>> with the U.S. Export Administration Act. Accordingly, NIS >>>>> will not ship INTERCEPTOR products to certain foreign >>>>> government end users without U.S. government approval and >>>>> will refuse transactions with individuals or entities >>>>> that >>>>> have been denied export privileges. >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Daniel Goertzen | Senior Software Engineer* >>>>> Office: 828.610.4596 | Fax: 828.322.5294 | >>>>> dang@REDACTED >>>>> >>>>> *Network Integrity Systems | We Bring Security To Light?* >>>>> >>>>> 1937 Tate Blvd. SE >>>>> >>>>> Hickory, North Carolina, USA 28602 >>>>> >>>>> /Network Integrity Systems? INTERCEPTOR? Optical Network Security >>>>> System is a Smart-PDS? that ensures superior protection and cost >>>>> effectiveness of classified networks. For more information, visit >>>>> our website at:www.networkintegritysystems.com >>>>> ./ >>>>> >>>>> >>>>> __________________________________________ >>>>> INTERCEPTOR? Optical Network Security System is made in the USA >>>>> for the USA. Although not an export controlled item, because of >>>>> the role it plays in the assurance of the safety and integrity of >>>>> National Security Information, Network Integrity Systems (NIS) is >>>>> committed to compliance with the U.S. Export Administration Act. >>>>> Accordingly, NIS will not ship INTERCEPTOR products to certain >>>>> foreign government end users without U.S. government approval and >>>>> will refuse transactions with individuals or entities that have >>>>> been denied export privileges. >>>>> >>>>> >>>> >>> >> > From ingela@REDACTED Fri May 4 12:00:39 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 4 May 2012 12:00:39 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4FA29213.9000909@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> <4F9AD973.7010808@ufm.su> <4FA29213.9000909@erix.ericsson.se> Message-ID: <4FA3A8C7.8060103@erix.ericsson.se> Hello again! After some more testing I found my first patch attempt was faulty but the following patch makes the problem go away. Maybe that is why putty described their bug as "semi"-bug ("if handled correctly it will not matter").Well never mind, if it ends up making our ssh implementation better it was, at leas in some way, a good bug ;) diff --git a/lib/ssh/src/ssh_connection.erl b/lib/ssh/src/ssh_connection.erl index 46f0c7e..c46f799 100644 --- a/lib/ssh/src/ssh_connection.erl +++ b/lib/ssh/src/ssh_connection.erl @@ -720,12 +720,17 @@ handle_msg(#ssh_msg_channel_request{request_type = "env"}, handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, request_type = _Other, - want_reply = WantReply}, Connection, + want_reply = WantReply}, #connection{channel_cache = Cache} = Connection, ConnectionPid, _) -> if WantReply == true -> - FailMsg = channel_failure_msg(ChannelId), - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, - Connection}; + case ssh_channel:cache_lookup(Cache, ChannelId) of + #channel{remote_id = RemoteId} -> + FailMsg = channel_failure_msg(RemoteId), + {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, + Connection}; + undefined -> %% Chanel has been closed + {noreply, Connection} + end; true -> {noreply, Connection} end; diff --git a/lib/ssh/src/ssh_connection_manager.erl b/lib/ssh/src/ssh_connection_manager.erl index 8c1f88e..a0ea04a 100644 --- a/lib/ssh/src/ssh_connection_manager.erl +++ b/lib/ssh/src/ssh_connection_manager.erl @@ -267,7 +267,7 @@ handle_call({ssh_msg, Pid, Msg}, From, disconnect_fun(Reason, SSHOpts), {stop, {shutdown, normal}, State#state{connection_state = Connection}} catch - _:Reason -> + _:Error -> {disconnect, Reason, {{replies, Replies}, Connection}} = ssh_connection:handle_msg( #ssh_msg_disconnect{code = ?SSH_DISCONNECT_BY_APPLICATION, @@ -277,7 +277,7 @@ handle_call({ssh_msg, Pid, Msg}, From, lists:foreach(fun send_msg/1, Replies), SSHOpts = proplists:get_value(ssh_opts, Opts), disconnect_fun(Reason, SSHOpts), - {stop, {shutdown, Reason}, State#state{connection_state = Connection}} + {stop, {shutdown, Error}, State#state{connection_state = Connection}} end; Regards Ingela Erlang/OTP team Ericsson AB Ingela Anderton Andin wrote: > Hello again! > > I tested this some more and found that adding a sleep in > start_local_sshd would let the session be up longer before it crashed. > I also traced the erlang code and I recive this message > > 6> (<0.61.0>) call > ssh_connection:handle_msg({ssh_msg_channel_request,0,"winadj@REDACTED",true,<<>>},{connection,[],20497,[],1, > > {ssh_cli,[#Fun]}, > "dain",2222, > [{role,server}, > {pwdfun,#Fun}, > {system_dir,"."}, > {shell,#Fun}], > undefined,<0.58.0>,undefined},<0.62.0>,server) > > which seems to be related to this putty bug: > http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/winadj-success.html > > > So maybe we can do something to make erlang server more graceful, but > it looks like the root of the problem is putty. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Fyodor Ustinov wrote: >> On 27.04.2012 11:54, Ingela Anderton Andin wrote: >>> Hi! >>> >>> Fyodor Ustinov wrote: >>>> Hi! >>>> >>>> putty say "Server send disconnect message type 11 (by application): >>>> "Internal error" >>>> >>>> Erlang say: >>>> >>> Interesting! It seems like the server is trying to handle a request >>> for a channel that has for some reason been closed. >>> If i modify the patch like this ... >>> >>> diff --git a/lib/ssh/src/ssh_connection.erl >>> b/lib/ssh/src/ssh_connection.erl >>> index 8574e08..fbd4967 100644 >>> --- a/lib/ssh/src/ssh_connection.erl >>> +++ b/lib/ssh/src/ssh_connection.erl >>> @@ -723,11 +723,14 @@ >>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>> want_reply = WantReply}, >>> #connection{channel_cache = Cache} = Connection, >>> ConnectionPid, _) -> >>> if WantReply == true -> >>> - #channel{remote_id = RemoteId} = ChannelId = >>> - ssh_channel:cache_lookup(Cache, ChannelId), >>> - FailMsg = channel_failure_msg(RemoteId), >>> - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>> - Connection}; >>> + case ssh_channel:cache_lookup(Cache, ChannelId) of >>> + #channel{remote_id = RemoteId} = ChannelId -> >>> + FailMsg = channel_failure_msg(RemoteId), >>> + {{replies, [{connection_reply, >>> ConnectionPid, FailMsg}]}, >>> + Connection}; >>> + undefined -> %% Chanel has been closed >>> + {noreply, Connection} >>> + end; >>> true -> >>> {noreply, Connection} >>> end; >>> >>> ... you should not get the below crash. But I am wondering if your >>> application will >>> now behave as you expect? Can you give me any more information on >>> the senario >>> of your application. It would like to be able to write a minimal >>> test case that provokes >>> the problem. >> Hmm. I'll wait for the final patch. :) >> >> minimal test case is very simple: >> %%%------------------------------------------------------------------- >> >> -module(sshd). >> -export([start/0]). >> >> -export([start_local_sshd/2, pwdcheck/2]). >> >> >> start() -> >> crypto:start(), >> ssh:start(), >> ssh:daemon( >> {172,28,3,22}, >> 2222, >> [{shell, fun (U,A) -> spawn(?MODULE, start_local_sshd, [U, >> A]) end}, >> {pwdfun, fun sshd:pwdcheck/2} >> ] >> ) >> . >> >> pwdcheck(_Usr, _Pwd) -> >> true >> . >> >> start_local_sshd(U, Address) -> >> >> io:format("------------------------------------------------------------------------------------------------------------------------------------------------ >> >> ----~n"), >> start_local_sshd(U, Address) >> . >>> >>> >>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>> ** Generic server <0.156.0> terminating >>>> ** Last message in was {ssh_msg,<0.157.0>, >>>> <<98,0,0,0,0,0,0,0,34,119,105,110,97,100,106, >>>> >>>> 64,112,117,116,116,121,46,112,114,111,106, >>>> >>>> 101,99,116,115,46,116,97,114,116,97,114,117, >>>> 115,46,111,114,103,1>>} >>>> ** When Server state == {state,server,undefined,undefined,<0.157.0>, >>>> {connection,[],315439,[],1, >>>> {ssh_cli,[#Fun]}, >>>> {10,128,0,10}, >>>> 2222, >>>> [{role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}], >>>> undefined,<0.153.0>,undefined}, >>>> 0, >>>> [{address,{10,128,0,10}}, >>>> {port,2222}, >>>> {role,server}, >>>> {socket_opts,[inet,{ip,{10,128,0,10}}]}, >>>> {ssh_opts, >>>> [{role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}]}], >>>> undefined,true} >>>> ** Reason for termination == >>>> ** {{badmatch, >>>> {disconnect, >>>> {11,"Internal error"}, >>>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>>> {connection,[],315439,[],1, >>>> {ssh_cli,[#Fun]}, >>>> {10,128,0,10}, >>>> 2222, >>>> [{role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}], >>>> undefined,<0.153.0>,undefined}}}}, >>>> [{ssh_connection_manager,handle_call,3, >>>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} >>>> >>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>> Erlang ssh connection handler failed with reason: {{{badmatch, >>>> {disconnect, >>>> {11,"Internal >>>> error"}, >>>> {{replies, >>>> >>>> [{channel_data, >>>> <0.159.0>, >>>> >>>> {closed,0}}]}, >>>> >>>> {connection,[],315439, >>>> [],1, >>>> {ssh_cli, >>>> >>>> [#Fun]}, >>>> {10,128,0,10}, >>>> 2222, >>>> >>>> [{role,server}, >>>> {pwdfun, >>>> >>>> #Fun}, >>>> {shell, >>>> >>>> #Fun}], >>>> >>>> undefined,<0.153.0>, >>>> undefined}}}}, >>>> >>>> [{ssh_connection_manager, >>>> handle_call,3, >>>> [{file, >>>> >>>> "../src/ssh_connection_manager.erl"}, >>>> {line,271}]}, >>>> >>>> {gen_server,handle_msg, >>>> 5, >>>> >>>> [{file,"gen_server.erl"}, >>>> {line,588}]}, >>>> {proc_lib, >>>> >>>> init_p_do_apply,3, >>>> >>>> [{file,"proc_lib.erl"}, >>>> {line,227}]}]}, >>>> {gen_server,call, >>>> [<0.156.0>, >>>> >>>> {ssh_msg,<0.157.0>, >>>> <<93,0,0,0,0,0,0,32,106>>}, >>>> infinity]}} >>>> , Stacktace: >>>> [{gen_server,call,3,[{file,"gen_server.erl"},{line,188}]}, >>>> {ssh_connection_manager,call,3, >>>> >>>> [{file,"../src/ssh_connection_manager.erl"},{line,583}]}, >>>> {ssh_connection_handler,generate_event,4, >>>> [{file,"ssh_connection_handler.erl"},{line,804}]}, >>>> >>>> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >>>> >>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >>>> please report this to erlang-bugs@REDACTED >>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>> ** State machine <0.157.0> terminating >>>> ** Last message in was {tcp,#Port<0.1845>,<<>>} >>>> ** When State == connected >>>> ** Data == {state,tcp,gen_tcp,tcp_closed, >>>> {ssh,server, >>>> {undefined,{{10,128,0,1},1076}}, >>>> {2,0}, >>>> {2,0}, >>>> >>>> "SSH-2.0-PuTTY_Release_0.62","SSH-2.0-Erlang", >>>> <<20,231,36,36,12,195,57,51,47,209,229,164,97,204,116, >>>> >>>> 116,90,0,0,0,154,100,105,102,102,105,101,45,104,101, >>>> >>>> 108,108,109,97,110,45,103,114,111,117,112,45,101, >>>> >>>> 120,99,104,97,110,103,101,45,115,104,97,50,53,54,44, >>>> >>>> 100,105,102,102,105,101,45,104,101,108,108,109,97, >>>> >>>> 110,45,103,114,111,117,112,45,101,120,99,104,97,110, >>>> >>>> 103,101,45,115,104,97,49,44,100,105,102,102,105,101, >>>> >>>> 45,104,101,108,108,109,97,110,45,103,114,111,117, >>>> >>>> 112,49,52,45,115,104,97,49,44,100,105,102,102,105, >>>> >>>> 101,45,104,101,108,108,109,97,110,45,103,114,111, >>>> >>>> 117,112,49,45,115,104,97,49,44,114,115,97,50,48,52, >>>> >>>> 56,45,115,104,97,50,53,54,44,114,115,97,49,48,50,52, >>>> >>>> 45,115,104,97,49,0,0,0,15,115,115,104,45,114,115,97, >>>> >>>> 44,115,115,104,45,100,115,115,0,0,0,159,97,101,115, >>>> >>>> 50,53,54,45,99,116,114,44,97,101,115,50,53,54,45,99, >>>> >>>> 98,99,44,114,105,106,110,100,97,101,108,45,99,98,99, >>>> >>>> 64,108,121,115,97,116,111,114,46,108,105,117,46,115, >>>> >>>> 101,44,97,101,115,49,57,50,45,99,116,114,44,97,101, >>>> >>>> 115,49,57,50,45,99,98,99,44,97,101,115,49,50,56,45, >>>> >>>> 99,116,114,44,97,101,115,49,50,56,45,99,98,99,44,98, >>>> >>>> 108,111,119,102,105,115,104,45,99,116,114,44,98,108, >>>> >>>> 111,119,102,105,115,104,45,99,98,99,44,51,100,101, >>>> >>>> 115,45,99,116,114,44,51,100,101,115,45,99,98,99,44, >>>> >>>> 97,114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>>> >>>> 111,117,114,49,50,56,0,0,0,159,97,101,115,50,53,54, >>>> >>>> 45,99,116,114,44,97,101,115,50,53,54,45,99,98,99,44, >>>> >>>> 114,105,106,110,100,97,101,108,45,99,98,99,64,108, >>>> >>>> 121,115,97,116,111,114,46,108,105,117,46,115,101,44, >>>> >>>> 97,101,115,49,57,50,45,99,116,114,44,97,101,115,49, >>>> >>>> 57,50,45,99,98,99,44,97,101,115,49,50,56,45,99,116, >>>> >>>> 114,44,97,101,115,49,50,56,45,99,98,99,44,98,108, >>>> >>>> 111,119,102,105,115,104,45,99,116,114,44,98,108,111, >>>> >>>> 119,102,105,115,104,45,99,98,99,44,51,100,101,115, >>>> >>>> 45,99,116,114,44,51,100,101,115,45,99,98,99,44,97, >>>> >>>> 114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>>> >>>> 111,117,114,49,50,56,0,0,0,31,104,109,97,99,45,115, >>>> >>>> 104,97,49,44,104,109,97,99,45,115,104,97,49,45,57, >>>> >>>> 54,44,104,109,97,99,45,109,100,53,0,0,0,31,104,109, >>>> >>>> 97,99,45,115,104,97,49,44,104,109,97,99,45,115,104, >>>> >>>> 97,49,45,57,54,44,104,109,97,99,45,109,100,53,0,0,0, >>>> >>>> 9,110,111,110,101,44,122,108,105,98,0,0,0,9,110,111, >>>> >>>> 110,101,44,122,108,105,98,0,0,0,0,0,0,0,0,0,0,0,0,0>>, >>>> <<20,68,106,202,126,189,248,249,152,175,237,102,43, >>>> >>>> 239,21,11,93,0,0,0,26,100,105,102,102,105,101,45, >>>> >>>> 104,101,108,108,109,97,110,45,103,114,111,117,112, >>>> >>>> 49,45,115,104,97,49,0,0,0,15,115,115,104,45,114,115, >>>> >>>> 97,44,115,115,104,45,100,115,115,0,0,0,19,97,101, >>>> >>>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >>>> >>>> 99,0,0,0,19,97,101,115,49,50,56,45,99,98,99,44,51, >>>> >>>> 100,101,115,45,99,98,99,0,0,0,9,104,109,97,99,45, >>>> >>>> 115,104,97,49,0,0,0,9,104,109,97,99,45,115,104,97, >>>> >>>> 49,0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0, >>>> >>>> 9,110,111,110,101,44,122,108,105,98,0,0,0,0,0,0,0,0, >>>> 0,0,0,0,0>>, >>>> >>>> undefined,'diffie-hellman-group1-sha1','ssh-rsa', >>>> ssh_file,ssh_io,'hmac-sha1', >>>> <<92,89,171,169,113,136,6,188,156,238,58,144,38,214, >>>> 101,198,247,166,205,208>>, >>>> 20,'hmac-sha1', >>>> <<24,206,173,99,5,252,206,70,166,228,30,17,101,89,36, >>>> 241,175,116,238,86>>, >>>> 20,'aes128-cbc', >>>> <<45,208,196,236,205,82,244,222,24,132,67,151,22,62, >>>> 250,150>>, >>>> 16, >>>> <<219,113,112,85,250,220,170,249,194,198,230,158,76, >>>> 122,39,155>>, >>>> 'aes128-cbc', >>>> <<44,157,215,194,90,86,202,31,228,49,188,97,227,97, >>>> 233,144>>, >>>> 16, >>>> <<196,110,206,199,93,111,201,100,74,194,231,242,179, >>>> 201,15,112>>, >>>> none,undefined,none,undefined,none,none,true, >>>> infinity, >>>> >>>> 132151717501655075704740428602371821313660310182519774905429178494543592682738802201444120687073445805819575914576401425536104160589136387731343596760889931670361900328999551747697001054684538185039596790225261438983095509229017954492065022996307622720613396529860286665422597229362632923823896919144441708303, >>>> >>>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>>> 87,102,43,69,173,214>>, >>>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>>> 87,102,43,69,173,214>>, >>>> [{address,{10,128,0,10}}, >>>> {port,2222}, >>>> {role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}], >>>> 114,49, >>>> >>>> {{49985839305237737688589908016292087537304670681285167039328910635484947391794443232164854289884214947929742793900078775832939310627327467626874637085242037758449972175725827907772272533385534014381436171929411436926043326068534386929776710296045274502307637113679098707841881585433086106245829282665980090815, >>>> >>>> >>>> 8395950144135694221446766804944646771011612746974327140375413192360614631043395924085970461957169944119762874929925969231067866506208529309578676567265288403413833138477256106374779295193693244061192404399083583730265790053008130870886892278024924477046645863115470835406736499812828883753405586277633495326}, >>>> >>>> {2, >>>> >>>> 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007}}, >>>> >>>> >>>> undefined,undefined,"ssh-connection",undefined, >>>> >>>> "publickey,keyboard_interactive,password",undefined, >>>> undefined, >>>> ["ssh-rsa","ssh-dss"]}, >>>> #Port<0.1845>,<<>>, >>>> <<107,0,185,229,147,59,116,109,92,16,81,210,0,243,152,220, >>>> >>>> 153,112,133,2,156,113,5,213,202,236,150,200,184,190,61, >>>> >>>> 227,37,31,157,1,53,98,136,245,199,18,165,166,214,36,210, >>>> 12,92,130,17,174>>, >>>> undefined, >>>> {ssh_msg_kexinit, >>>> <<126,96,184,235,216,208,69,175,215,35,94,180,214,20, >>>> 246,141>>, >>>> ["diffie-hellman-group1-sha1"], >>>> ["ssh-rsa","ssh-dss"], >>>> ["aes128-cbc","3des-cbc"], >>>> ["aes128-cbc","3des-cbc"], >>>> ["hmac-sha1"], >>>> ["hmac-sha1"], >>>> ["none","zlib"], >>>> ["none","zlib"], >>>> [],[],false,0}, >>>> false,<0.156.0>,undefined,undefined,undefined, >>>> [{address,{10,128,0,10}}, >>>> {port,2222}, >>>> {role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}]} >>>> ** Reason for termination = >>>> ** {{{badmatch, >>>> {disconnect, >>>> {11,"Internal error"}, >>>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>>> {connection,[],315439,[],1, >>>> {ssh_cli,[#Fun]}, >>>> {10,128,0,10}, >>>> 2222, >>>> [{role,server}, >>>> {pwdfun,#Fun}, >>>> {shell,#Fun}], >>>> undefined,<0.153.0>,undefined}}}}, >>>> [{ssh_connection_manager,handle_call,3, >>>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>>> >>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}, >>>> {gen_server,call, >>>> >>>> [<0.156.0>,{ssh_msg,<0.157.0>,<<93,0,0,0,0,0,0,32,106>>},infinity]}} >>>> >>>> >>>> >>>>> Hi! >>>>> >>>>> Daniel Goertzen wrote: >>>>>> The channel number on the putty side is 0x100, and on the Erlang >>>>>> side it is 0x0. Erlang is responding to SSH_MSG_CHANNEL_REQUEST >>>>>> using 0x0, however RFC4254 says the responses should be... >>>>>> >>>>>> >>>>>> byte SSH_MSG_CHANNEL_SUCCESS >>>>>> uint32 recipient channel >>>>>> >>>>>> >>>>>> byte SSH_MSG_CHANNEL_FAILURE >>>>>> uint32 recipient channel >>>>>> >>>>>> >>>>>> ...and I interpret "recipient channel" as being the Putty side, >>>>>> which is 0x100. Putty seems to cope when Erlang returns SUCCESS, >>>>>> but blows up when Erlang returns a FAILURE. >>>>>> >>>>> >>>>> Yes that is correct I remember correcting such a bug a long time >>>>> ago, checking the code however there seems to be one error >>>>> handling case that I missed. Could you check if >>>>> the following patch resolves your issue Fyodor? >>>>> >>>>> diff --git a/lib/ssh/src/ssh_connection.erl >>>>> b/lib/ssh/src/ssh_connection.erl >>>>> index 46f0c7e..8574e08 100644 >>>>> --- a/lib/ssh/src/ssh_connection.erl >>>>> +++ b/lib/ssh/src/ssh_connection.erl >>>>> @@ -720,10 +720,12 @@ >>>>> handle_msg(#ssh_msg_channel_request{request_type = "env"}, >>>>> >>>>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>>>> request_type = _Other, >>>>> - want_reply = WantReply}, >>>>> Connection, >>>>> + want_reply = WantReply}, >>>>> #connection{channel_cache = Cache} = Connection, >>>>> ConnectionPid, _) -> >>>>> if WantReply == true -> >>>>> - FailMsg = channel_failure_msg(ChannelId), >>>>> + #channel{remote_id = RemoteId} = ChannelId = >>>>> + ssh_channel:cache_lookup(Cache, ChannelId), >>>>> + FailMsg = channel_failure_msg(RemoteId), >>>>> {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>>>> Connection}; >>>>> true -> >>>>> >>>>> >>>>>> I could imagine this passing automated tests when both ends >>>>>> number their channels starting from 0. I bet randomizing the >>>>>> channel numbers would reveal this and maybe other issues. >>>>>> >>>>>> Dan. >>>>>> >>>>> I think you have a valid point however we have to change the >>>>> implementation in one way or an other to do that and that has not >>>>> been prioritized. >>>>> >>>>> >>>>> Regards Ingela Erlang/OTP team -Ericsson AB >>>>> >>>>>> >>>>>> On Tue, Apr 24, 2012 at 11:22 AM, Fyodor Ustinov >>>>> > wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> I added this patch - did not help. >>>>>> >>>>>> http://blog.ufm.su/putty.log - this putty log. >>>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> This might be a symptom of the "close race-condition"-bug >>>>>> reported by Daniel. The patch for that bug is >>>>>> >>>>>> diff --git a/lib/ssh/src/ssh_channel.erl >>>>>> b/lib/ssh/src/ssh_channel.erl >>>>>> index 7b600ed..1938858 100644 >>>>>> --- a/lib/ssh/src/ssh_channel.erl >>>>>> +++ b/lib/ssh/src/ssh_channel.erl >>>>>> @@ -1,7 +1,7 @@ >>>>>> %% >>>>>> %% %CopyrightBegin% >>>>>> %% >>>>>> -%% Copyright Ericsson AB 2008-2011. All Rights Reserved. >>>>>> +%% Copyright Ericsson AB 2008-2012. All Rights Reserved. >>>>>> %% >>>>>> %% The contents of this file are subject to the Erlang >>>>>> Public >>>>>> License, >>>>>> %% Version 1.1, (the "License"); you may not use this file >>>>>> except in >>>>>> @@ -215,7 +215,7 @@ handle_info({ssh_cm, ConnectionManager, >>>>>> {closed, ChannelId}}, >>>>>> close_sent = false} = State) -> >>>>>> %% To be on the safe side, i.e. the manager has already >>>>>> been terminated. >>>>>> (catch ssh_connection:close(ConnectionManager, >>>>>> ChannelId)), >>>>>> - {stop, normal, State}; >>>>>> + {stop, normal, State#state{close_sent = true}}; >>>>>> >>>>>> handle_info({ssh_cm, _, _} = Msg, #state{cm = >>>>>> ConnectionManager, >>>>>> channel_cb = Module, >>>>>> diff --git a/lib/ssh/src/ssh_connection_manager.erl >>>>>> b/lib/ssh/src/ssh_connection_manager.erl >>>>>> index e993f59..8c1f88e 100644 >>>>>> --- a/lib/ssh/src/ssh_connection_manager.erl >>>>>> +++ b/lib/ssh/src/ssh_connection_manager.erl >>>>>> @@ -384,9 +384,10 @@ handle_call({close, ChannelId}, _, >>>>>> #state{connection = Pid, connection_state = >>>>>> #connection{channel_cache = Cache}} = >>>>>> State) -> >>>>>> case ssh_channel:cache_lookup(Cache, ChannelId) of >>>>>> - #channel{remote_id = Id} -> >>>>>> + #channel{remote_id = Id} = Channel -> >>>>>> send_msg({connection_reply, Pid, >>>>>> ssh_connection:channel_close_msg(Id)}), >>>>>> + ssh_channel:cache_update(Cache, >>>>>> Channel#channel{sent_close = true}), >>>>>> {reply, ok, State}; >>>>>> undefined -> >>>>>> {reply, ok, State} >>>>>> >>>>>> >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>>> Daniel Goertzen wrote: >>>>>> >>>>>> Under Putty Session->Logging can you turn on "SSH >>>>>> Packets" >>>>>> and post the log showing the error? >>>>>> >>>>>> Dan. >>>>>> >>>>>> On Sun, Apr 22, 2012 at 3:58 AM, Fyodor Ustinov >>>>>> >>>>> >> wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> Windows ssh client PuTTY show message "Disconnected: >>>>>> Received >>>>>> SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 0" >>>>>> while working >>>>>> with erlang ssh daemon. >>>>>> >>>>>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] >>>>>> [smp:8:8] >>>>>> [async-threads:0] [kernel-poll:false] >>>>>> >>>>>> WBR, >>>>>> Fyodor. >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> >>>>>> >>>>> > >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- *Daniel Goertzen | Senior Software >>>>>> Engineer* >>>>>> Office: 828.610.4596 | Fax: >>>>>> 828.322.5294 | >>>>>> dang@REDACTED >>>>>> >>>>>> >>>>> > >>>>>> *Network Integrity Systems | We Bring Security To >>>>>> Light?* >>>>>> >>>>>> 1937 Tate Blvd. SE >>>>>> >>>>>> Hickory, North Carolina, USA 28602 >>>>>> >>>>>> /Network Integrity Systems? INTERCEPTOR? Optical Network >>>>>> Security System is a Smart-PDS? that ensures superior >>>>>> protection and cost effectiveness of classified >>>>>> networks. >>>>>> For more information, visit our website >>>>>> at:www.networkintegritysystems.com >>>>>> >>>>>> ./ >>>>>> >>>>>> >>>>>> __________________________________________ >>>>>> INTERCEPTOR? Optical Network Security System is made in >>>>>> the USA for the USA. Although not an export controlled >>>>>> item, because of the role it plays in the assurance >>>>>> of the >>>>>> safety and integrity of National Security Information, >>>>>> Network Integrity Systems (NIS) is committed to >>>>>> compliance >>>>>> with the U.S. Export Administration Act. Accordingly, >>>>>> NIS >>>>>> will not ship INTERCEPTOR products to certain foreign >>>>>> government end users without U.S. government approval >>>>>> and >>>>>> will refuse transactions with individuals or entities >>>>>> that >>>>>> have been denied export privileges. >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Daniel Goertzen | Senior Software Engineer* >>>>>> Office: 828.610.4596 | Fax: 828.322.5294 | >>>>>> dang@REDACTED >>>>>> >>>>>> *Network Integrity Systems | We Bring Security To Light?* >>>>>> >>>>>> 1937 Tate Blvd. SE >>>>>> >>>>>> Hickory, North Carolina, USA 28602 >>>>>> >>>>>> /Network Integrity Systems? INTERCEPTOR? Optical Network Security >>>>>> System is a Smart-PDS? that ensures superior protection and cost >>>>>> effectiveness of classified networks. For more information, >>>>>> visit our website at:www.networkintegritysystems.com >>>>>> ./ >>>>>> >>>>>> >>>>>> __________________________________________ >>>>>> INTERCEPTOR? Optical Network Security System is made in the USA >>>>>> for the USA. Although not an export controlled item, because of >>>>>> the role it plays in the assurance of the safety and integrity of >>>>>> National Security Information, Network Integrity Systems (NIS) is >>>>>> committed to compliance with the U.S. Export Administration Act. >>>>>> Accordingly, NIS will not ship INTERCEPTOR products to certain >>>>>> foreign government end users without U.S. government approval and >>>>>> will refuse transactions with individuals or entities that have >>>>>> been denied export privileges. >>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ufm@REDACTED Fri May 4 12:33:57 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Fri, 04 May 2012 13:33:57 +0300 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4FA3A8C7.8060103@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> <4F983005.9080803@ufm.su> <4F9A5EE2.2080106@erix.ericsson.se> <4F9AD973.7010808@ufm.su> <4FA29213.9000909@erix.ericsson.se> <4FA3A8C7.8060103@erix.ericsson.se> Message-ID: <4FA3B095.7070302@ufm.su> On 04.05.2012 13:00, Ingela Anderton Andin wrote: > Hello again! > > After some more testing I found my first patch attempt was faulty but > the following patch makes the problem > go away. Maybe that is why putty described their bug as "semi"-bug > ("if handled correctly it will not matter").Well never mind, if it > ends up making our > ssh implementation better it was, at leas in some way, a good bug ;) Yes! You catch it! :) Big thanx! > > diff --git a/lib/ssh/src/ssh_connection.erl > b/lib/ssh/src/ssh_connection.erl > index 46f0c7e..c46f799 100644 > --- a/lib/ssh/src/ssh_connection.erl > +++ b/lib/ssh/src/ssh_connection.erl > @@ -720,12 +720,17 @@ handle_msg(#ssh_msg_channel_request{request_type > = "env"}, > > handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, > request_type = _Other, > - want_reply = WantReply}, Connection, > + want_reply = WantReply}, > #connection{channel_cache = Cache} = Connection, > ConnectionPid, _) -> > if WantReply == true -> > - FailMsg = channel_failure_msg(ChannelId), > - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, > - Connection}; > + case ssh_channel:cache_lookup(Cache, ChannelId) of > + #channel{remote_id = RemoteId} -> > + FailMsg = channel_failure_msg(RemoteId), > + {{replies, [{connection_reply, ConnectionPid, > FailMsg}]}, > + Connection}; > + undefined -> %% Chanel has been closed > + {noreply, Connection} > + end; > true -> > {noreply, Connection} > end; > diff --git a/lib/ssh/src/ssh_connection_manager.erl > b/lib/ssh/src/ssh_connection_manager.erl > index 8c1f88e..a0ea04a 100644 > --- a/lib/ssh/src/ssh_connection_manager.erl > +++ b/lib/ssh/src/ssh_connection_manager.erl > @@ -267,7 +267,7 @@ handle_call({ssh_msg, Pid, Msg}, From, > disconnect_fun(Reason, SSHOpts), > {stop, {shutdown, normal}, State#state{connection_state = > Connection}} > catch > - _:Reason -> > + _:Error -> > {disconnect, Reason, {{replies, Replies}, Connection}} = > ssh_connection:handle_msg( > #ssh_msg_disconnect{code = > ?SSH_DISCONNECT_BY_APPLICATION, > @@ -277,7 +277,7 @@ handle_call({ssh_msg, Pid, Msg}, From, > lists:foreach(fun send_msg/1, Replies), > SSHOpts = proplists:get_value(ssh_opts, Opts), > disconnect_fun(Reason, SSHOpts), > - {stop, {shutdown, Reason}, > State#state{connection_state = Connection}} > + {stop, {shutdown, Error}, State#state{connection_state > = Connection}} > end; > > > > Regards Ingela Erlang/OTP team Ericsson AB > > > > Ingela Anderton Andin wrote: >> Hello again! >> >> I tested this some more and found that adding a sleep in >> start_local_sshd would let the session be up longer before it crashed. >> I also traced the erlang code and I recive this message >> >> 6> (<0.61.0>) call >> ssh_connection:handle_msg({ssh_msg_channel_request,0,"winadj@REDACTED",true,<<>>},{connection,[],20497,[],1, >> >> {ssh_cli,[#Fun]}, >> "dain",2222, >> [{role,server}, >> {pwdfun,#Fun}, >> {system_dir,"."}, >> {shell,#Fun}], >> undefined,<0.58.0>,undefined},<0.62.0>,server) >> >> which seems to be related to this putty bug: >> http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/winadj-success.html >> >> >> So maybe we can do something to make erlang server more graceful, but >> it looks like the root of the problem is putty. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Fyodor Ustinov wrote: >>> On 27.04.2012 11:54, Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> Fyodor Ustinov wrote: >>>>> Hi! >>>>> >>>>> putty say "Server send disconnect message type 11 (by >>>>> application): "Internal error" >>>>> >>>>> Erlang say: >>>>> >>>> Interesting! It seems like the server is trying to handle a request >>>> for a channel that has for some reason been closed. >>>> If i modify the patch like this ... >>>> >>>> diff --git a/lib/ssh/src/ssh_connection.erl >>>> b/lib/ssh/src/ssh_connection.erl >>>> index 8574e08..fbd4967 100644 >>>> --- a/lib/ssh/src/ssh_connection.erl >>>> +++ b/lib/ssh/src/ssh_connection.erl >>>> @@ -723,11 +723,14 @@ >>>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>>> want_reply = WantReply}, >>>> #connection{channel_cache = Cache} = Connection, >>>> ConnectionPid, _) -> >>>> if WantReply == true -> >>>> - #channel{remote_id = RemoteId} = ChannelId = >>>> - ssh_channel:cache_lookup(Cache, ChannelId), >>>> - FailMsg = channel_failure_msg(RemoteId), >>>> - {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>>> - Connection}; >>>> + case ssh_channel:cache_lookup(Cache, ChannelId) of >>>> + #channel{remote_id = RemoteId} = ChannelId -> >>>> + FailMsg = channel_failure_msg(RemoteId), >>>> + {{replies, [{connection_reply, >>>> ConnectionPid, FailMsg}]}, >>>> + Connection}; >>>> + undefined -> %% Chanel has been closed >>>> + {noreply, Connection} >>>> + end; >>>> true -> >>>> {noreply, Connection} >>>> end; >>>> >>>> ... you should not get the below crash. But I am wondering if your >>>> application will >>>> now behave as you expect? Can you give me any more information on >>>> the senario >>>> of your application. It would like to be able to write a minimal >>>> test case that provokes >>>> the problem. >>> Hmm. I'll wait for the final patch. :) >>> >>> minimal test case is very simple: >>> %%%------------------------------------------------------------------- >>> >>> -module(sshd). >>> -export([start/0]). >>> >>> -export([start_local_sshd/2, pwdcheck/2]). >>> >>> >>> start() -> >>> crypto:start(), >>> ssh:start(), >>> ssh:daemon( >>> {172,28,3,22}, >>> 2222, >>> [{shell, fun (U,A) -> spawn(?MODULE, start_local_sshd, [U, >>> A]) end}, >>> {pwdfun, fun sshd:pwdcheck/2} >>> ] >>> ) >>> . >>> >>> pwdcheck(_Usr, _Pwd) -> >>> true >>> . >>> >>> start_local_sshd(U, Address) -> >>> >>> io:format("------------------------------------------------------------------------------------------------------------------------------------------------ >>> >>> ----~n"), >>> start_local_sshd(U, Address) >>> . >>>> >>>> >>>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>>> ** Generic server <0.156.0> terminating >>>>> ** Last message in was {ssh_msg,<0.157.0>, >>>>> <<98,0,0,0,0,0,0,0,34,119,105,110,97,100,106, >>>>> >>>>> 64,112,117,116,116,121,46,112,114,111,106, >>>>> >>>>> 101,99,116,115,46,116,97,114,116,97,114,117, >>>>> 115,46,111,114,103,1>>} >>>>> ** When Server state == {state,server,undefined,undefined,<0.157.0>, >>>>> {connection,[],315439,[],1, >>>>> {ssh_cli,[#Fun]}, >>>>> {10,128,0,10}, >>>>> 2222, >>>>> [{role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}], >>>>> undefined,<0.153.0>,undefined}, >>>>> 0, >>>>> [{address,{10,128,0,10}}, >>>>> {port,2222}, >>>>> {role,server}, >>>>> {socket_opts,[inet,{ip,{10,128,0,10}}]}, >>>>> {ssh_opts, >>>>> [{role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}]}], >>>>> undefined,true} >>>>> ** Reason for termination == >>>>> ** {{badmatch, >>>>> {disconnect, >>>>> {11,"Internal error"}, >>>>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>>>> {connection,[],315439,[],1, >>>>> {ssh_cli,[#Fun]}, >>>>> {10,128,0,10}, >>>>> 2222, >>>>> [{role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}], >>>>> undefined,<0.153.0>,undefined}}}}, >>>>> [{ssh_connection_manager,handle_call,3, >>>>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>>>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>>>> >>>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} >>>>> >>>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>>> Erlang ssh connection handler failed with reason: {{{badmatch, >>>>> {disconnect, >>>>> >>>>> {11,"Internal error"}, >>>>> {{replies, >>>>> >>>>> [{channel_data, >>>>> <0.159.0>, >>>>> >>>>> {closed,0}}]}, >>>>> >>>>> {connection,[],315439, >>>>> [],1, >>>>> {ssh_cli, >>>>> >>>>> [#Fun]}, >>>>> >>>>> {10,128,0,10}, >>>>> 2222, >>>>> >>>>> [{role,server}, >>>>> {pwdfun, >>>>> >>>>> #Fun}, >>>>> {shell, >>>>> >>>>> #Fun}], >>>>> >>>>> undefined,<0.153.0>, >>>>> >>>>> undefined}}}}, >>>>> >>>>> [{ssh_connection_manager, >>>>> handle_call,3, >>>>> [{file, >>>>> >>>>> "../src/ssh_connection_manager.erl"}, >>>>> {line,271}]}, >>>>> >>>>> {gen_server,handle_msg, >>>>> 5, >>>>> >>>>> [{file,"gen_server.erl"}, >>>>> {line,588}]}, >>>>> {proc_lib, >>>>> >>>>> init_p_do_apply,3, >>>>> >>>>> [{file,"proc_lib.erl"}, >>>>> >>>>> {line,227}]}]}, >>>>> {gen_server,call, >>>>> [<0.156.0>, >>>>> >>>>> {ssh_msg,<0.157.0>, >>>>> <<93,0,0,0,0,0,0,32,106>>}, >>>>> infinity]}} >>>>> , Stacktace: >>>>> [{gen_server,call,3,[{file,"gen_server.erl"},{line,188}]}, >>>>> {ssh_connection_manager,call,3, >>>>> >>>>> [{file,"../src/ssh_connection_manager.erl"},{line,583}]}, >>>>> {ssh_connection_handler,generate_event,4, >>>>> [{file,"ssh_connection_handler.erl"},{line,804}]}, >>>>> >>>>> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,494}]}, >>>>> >>>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}] >>>>> please report this to erlang-bugs@REDACTED >>>>> =ERROR REPORT==== 25-Apr-2012::20:03:09 === >>>>> ** State machine <0.157.0> terminating >>>>> ** Last message in was {tcp,#Port<0.1845>,<<>>} >>>>> ** When State == connected >>>>> ** Data == {state,tcp,gen_tcp,tcp_closed, >>>>> {ssh,server, >>>>> {undefined,{{10,128,0,1},1076}}, >>>>> {2,0}, >>>>> {2,0}, >>>>> >>>>> "SSH-2.0-PuTTY_Release_0.62","SSH-2.0-Erlang", >>>>> <<20,231,36,36,12,195,57,51,47,209,229,164,97,204,116, >>>>> >>>>> 116,90,0,0,0,154,100,105,102,102,105,101,45,104,101, >>>>> >>>>> 108,108,109,97,110,45,103,114,111,117,112,45,101, >>>>> >>>>> 120,99,104,97,110,103,101,45,115,104,97,50,53,54,44, >>>>> >>>>> 100,105,102,102,105,101,45,104,101,108,108,109,97, >>>>> >>>>> 110,45,103,114,111,117,112,45,101,120,99,104,97,110, >>>>> >>>>> 103,101,45,115,104,97,49,44,100,105,102,102,105,101, >>>>> >>>>> 45,104,101,108,108,109,97,110,45,103,114,111,117, >>>>> >>>>> 112,49,52,45,115,104,97,49,44,100,105,102,102,105, >>>>> >>>>> 101,45,104,101,108,108,109,97,110,45,103,114,111, >>>>> >>>>> 117,112,49,45,115,104,97,49,44,114,115,97,50,48,52, >>>>> >>>>> 56,45,115,104,97,50,53,54,44,114,115,97,49,48,50,52, >>>>> >>>>> 45,115,104,97,49,0,0,0,15,115,115,104,45,114,115,97, >>>>> >>>>> 44,115,115,104,45,100,115,115,0,0,0,159,97,101,115, >>>>> >>>>> 50,53,54,45,99,116,114,44,97,101,115,50,53,54,45,99, >>>>> >>>>> 98,99,44,114,105,106,110,100,97,101,108,45,99,98,99, >>>>> >>>>> 64,108,121,115,97,116,111,114,46,108,105,117,46,115, >>>>> >>>>> 101,44,97,101,115,49,57,50,45,99,116,114,44,97,101, >>>>> >>>>> 115,49,57,50,45,99,98,99,44,97,101,115,49,50,56,45, >>>>> >>>>> 99,116,114,44,97,101,115,49,50,56,45,99,98,99,44,98, >>>>> >>>>> 108,111,119,102,105,115,104,45,99,116,114,44,98,108, >>>>> >>>>> 111,119,102,105,115,104,45,99,98,99,44,51,100,101, >>>>> >>>>> 115,45,99,116,114,44,51,100,101,115,45,99,98,99,44, >>>>> >>>>> 97,114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>>>> >>>>> 111,117,114,49,50,56,0,0,0,159,97,101,115,50,53,54, >>>>> >>>>> 45,99,116,114,44,97,101,115,50,53,54,45,99,98,99,44, >>>>> >>>>> 114,105,106,110,100,97,101,108,45,99,98,99,64,108, >>>>> >>>>> 121,115,97,116,111,114,46,108,105,117,46,115,101,44, >>>>> >>>>> 97,101,115,49,57,50,45,99,116,114,44,97,101,115,49, >>>>> >>>>> 57,50,45,99,98,99,44,97,101,115,49,50,56,45,99,116, >>>>> >>>>> 114,44,97,101,115,49,50,56,45,99,98,99,44,98,108, >>>>> >>>>> 111,119,102,105,115,104,45,99,116,114,44,98,108,111, >>>>> >>>>> 119,102,105,115,104,45,99,98,99,44,51,100,101,115, >>>>> >>>>> 45,99,116,114,44,51,100,101,115,45,99,98,99,44,97, >>>>> >>>>> 114,99,102,111,117,114,50,53,54,44,97,114,99,102, >>>>> >>>>> 111,117,114,49,50,56,0,0,0,31,104,109,97,99,45,115, >>>>> >>>>> 104,97,49,44,104,109,97,99,45,115,104,97,49,45,57, >>>>> >>>>> 54,44,104,109,97,99,45,109,100,53,0,0,0,31,104,109, >>>>> >>>>> 97,99,45,115,104,97,49,44,104,109,97,99,45,115,104, >>>>> >>>>> 97,49,45,57,54,44,104,109,97,99,45,109,100,53,0,0,0, >>>>> >>>>> 9,110,111,110,101,44,122,108,105,98,0,0,0,9,110,111, >>>>> >>>>> 110,101,44,122,108,105,98,0,0,0,0,0,0,0,0,0,0,0,0,0>>, >>>>> <<20,68,106,202,126,189,248,249,152,175,237,102,43, >>>>> >>>>> 239,21,11,93,0,0,0,26,100,105,102,102,105,101,45, >>>>> >>>>> 104,101,108,108,109,97,110,45,103,114,111,117,112, >>>>> >>>>> 49,45,115,104,97,49,0,0,0,15,115,115,104,45,114,115, >>>>> >>>>> 97,44,115,115,104,45,100,115,115,0,0,0,19,97,101, >>>>> >>>>> 115,49,50,56,45,99,98,99,44,51,100,101,115,45,99,98, >>>>> >>>>> 99,0,0,0,19,97,101,115,49,50,56,45,99,98,99,44,51, >>>>> >>>>> 100,101,115,45,99,98,99,0,0,0,9,104,109,97,99,45, >>>>> >>>>> 115,104,97,49,0,0,0,9,104,109,97,99,45,115,104,97, >>>>> >>>>> 49,0,0,0,9,110,111,110,101,44,122,108,105,98,0,0,0, >>>>> >>>>> 9,110,111,110,101,44,122,108,105,98,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0>>, >>>>> >>>>> undefined,'diffie-hellman-group1-sha1','ssh-rsa', >>>>> ssh_file,ssh_io,'hmac-sha1', >>>>> <<92,89,171,169,113,136,6,188,156,238,58,144,38,214, >>>>> 101,198,247,166,205,208>>, >>>>> 20,'hmac-sha1', >>>>> <<24,206,173,99,5,252,206,70,166,228,30,17,101,89,36, >>>>> 241,175,116,238,86>>, >>>>> 20,'aes128-cbc', >>>>> <<45,208,196,236,205,82,244,222,24,132,67,151,22,62, >>>>> 250,150>>, >>>>> 16, >>>>> <<219,113,112,85,250,220,170,249,194,198,230,158,76, >>>>> 122,39,155>>, >>>>> 'aes128-cbc', >>>>> <<44,157,215,194,90,86,202,31,228,49,188,97,227,97, >>>>> 233,144>>, >>>>> 16, >>>>> <<196,110,206,199,93,111,201,100,74,194,231,242,179, >>>>> 201,15,112>>, >>>>> >>>>> none,undefined,none,undefined,none,none,true, >>>>> infinity, >>>>> >>>>> 132151717501655075704740428602371821313660310182519774905429178494543592682738802201444120687073445805819575914576401425536104160589136387731343596760889931670361900328999551747697001054684538185039596790225261438983095509229017954492065022996307622720613396529860286665422597229362632923823896919144441708303, >>>>> >>>>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>>>> 87,102,43,69,173,214>>, >>>>> <<163,238,219,114,10,240,95,30,207,178,78,138,146,58, >>>>> 87,102,43,69,173,214>>, >>>>> [{address,{10,128,0,10}}, >>>>> {port,2222}, >>>>> {role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}], >>>>> 114,49, >>>>> >>>>> {{49985839305237737688589908016292087537304670681285167039328910635484947391794443232164854289884214947929742793900078775832939310627327467626874637085242037758449972175725827907772272533385534014381436171929411436926043326068534386929776710296045274502307637113679098707841881585433086106245829282665980090815, >>>>> >>>>> >>>>> 8395950144135694221446766804944646771011612746974327140375413192360614631043395924085970461957169944119762874929925969231067866506208529309578676567265288403413833138477256106374779295193693244061192404399083583730265790053008130870886892278024924477046645863115470835406736499812828883753405586277633495326}, >>>>> >>>>> {2, >>>>> >>>>> 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007}}, >>>>> >>>>> >>>>> undefined,undefined,"ssh-connection",undefined, >>>>> >>>>> "publickey,keyboard_interactive,password",undefined, >>>>> undefined, >>>>> ["ssh-rsa","ssh-dss"]}, >>>>> #Port<0.1845>,<<>>, >>>>> <<107,0,185,229,147,59,116,109,92,16,81,210,0,243,152,220, >>>>> >>>>> 153,112,133,2,156,113,5,213,202,236,150,200,184,190,61, >>>>> >>>>> 227,37,31,157,1,53,98,136,245,199,18,165,166,214,36,210, >>>>> 12,92,130,17,174>>, >>>>> undefined, >>>>> {ssh_msg_kexinit, >>>>> <<126,96,184,235,216,208,69,175,215,35,94,180,214,20, >>>>> 246,141>>, >>>>> ["diffie-hellman-group1-sha1"], >>>>> ["ssh-rsa","ssh-dss"], >>>>> ["aes128-cbc","3des-cbc"], >>>>> ["aes128-cbc","3des-cbc"], >>>>> ["hmac-sha1"], >>>>> ["hmac-sha1"], >>>>> ["none","zlib"], >>>>> ["none","zlib"], >>>>> [],[],false,0}, >>>>> false,<0.156.0>,undefined,undefined,undefined, >>>>> [{address,{10,128,0,10}}, >>>>> {port,2222}, >>>>> {role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}]} >>>>> ** Reason for termination = >>>>> ** {{{badmatch, >>>>> {disconnect, >>>>> {11,"Internal error"}, >>>>> {{replies,[{channel_data,<0.159.0>,{closed,0}}]}, >>>>> {connection,[],315439,[],1, >>>>> {ssh_cli,[#Fun]}, >>>>> {10,128,0,10}, >>>>> 2222, >>>>> [{role,server}, >>>>> {pwdfun,#Fun}, >>>>> {shell,#Fun}], >>>>> undefined,<0.153.0>,undefined}}}}, >>>>> [{ssh_connection_manager,handle_call,3, >>>>> [{file,"../src/ssh_connection_manager.erl"},{line,271}]}, >>>>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,588}]}, >>>>> >>>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}, >>>>> {gen_server,call, >>>>> >>>>> [<0.156.0>,{ssh_msg,<0.157.0>,<<93,0,0,0,0,0,0,32,106>>},infinity]}} >>>>> >>>>> >>>>> >>>>>> Hi! >>>>>> >>>>>> Daniel Goertzen wrote: >>>>>>> The channel number on the putty side is 0x100, and on the Erlang >>>>>>> side it is 0x0. Erlang is responding to SSH_MSG_CHANNEL_REQUEST >>>>>>> using 0x0, however RFC4254 says the responses should be... >>>>>>> >>>>>>> >>>>>>> byte SSH_MSG_CHANNEL_SUCCESS >>>>>>> uint32 recipient channel >>>>>>> >>>>>>> >>>>>>> byte SSH_MSG_CHANNEL_FAILURE >>>>>>> uint32 recipient channel >>>>>>> >>>>>>> >>>>>>> ...and I interpret "recipient channel" as being the Putty side, >>>>>>> which is 0x100. Putty seems to cope when Erlang returns >>>>>>> SUCCESS, but blows up when Erlang returns a FAILURE. >>>>>>> >>>>>> >>>>>> Yes that is correct I remember correcting such a bug a long time >>>>>> ago, checking the code however there seems to be one error >>>>>> handling case that I missed. Could you check if >>>>>> the following patch resolves your issue Fyodor? >>>>>> >>>>>> diff --git a/lib/ssh/src/ssh_connection.erl >>>>>> b/lib/ssh/src/ssh_connection.erl >>>>>> index 46f0c7e..8574e08 100644 >>>>>> --- a/lib/ssh/src/ssh_connection.erl >>>>>> +++ b/lib/ssh/src/ssh_connection.erl >>>>>> @@ -720,10 +720,12 @@ >>>>>> handle_msg(#ssh_msg_channel_request{request_type = "env"}, >>>>>> >>>>>> handle_msg(#ssh_msg_channel_request{recipient_channel = ChannelId, >>>>>> request_type = _Other, >>>>>> - want_reply = WantReply}, >>>>>> Connection, >>>>>> + want_reply = WantReply}, >>>>>> #connection{channel_cache = Cache} = Connection, >>>>>> ConnectionPid, _) -> >>>>>> if WantReply == true -> >>>>>> - FailMsg = channel_failure_msg(ChannelId), >>>>>> + #channel{remote_id = RemoteId} = ChannelId = >>>>>> + ssh_channel:cache_lookup(Cache, ChannelId), >>>>>> + FailMsg = channel_failure_msg(RemoteId), >>>>>> {{replies, [{connection_reply, ConnectionPid, FailMsg}]}, >>>>>> Connection}; >>>>>> true -> >>>>>> >>>>>> >>>>>>> I could imagine this passing automated tests when both ends >>>>>>> number their channels starting from 0. I bet randomizing the >>>>>>> channel numbers would reveal this and maybe other issues. >>>>>>> >>>>>>> Dan. >>>>>>> >>>>>> I think you have a valid point however we have to change the >>>>>> implementation in one way or an other to do that and that has not >>>>>> been prioritized. >>>>>> >>>>>> >>>>>> Regards Ingela Erlang/OTP team -Ericsson AB >>>>>> >>>>>>> >>>>>>> On Tue, Apr 24, 2012 at 11:22 AM, Fyodor Ustinov >>>>>> > wrote: >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> I added this patch - did not help. >>>>>>> >>>>>>> http://blog.ufm.su/putty.log - this putty log. >>>>>>> >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> This might be a symptom of the "close race-condition"-bug >>>>>>> reported by Daniel. The patch for that bug is >>>>>>> >>>>>>> diff --git a/lib/ssh/src/ssh_channel.erl >>>>>>> b/lib/ssh/src/ssh_channel.erl >>>>>>> index 7b600ed..1938858 100644 >>>>>>> --- a/lib/ssh/src/ssh_channel.erl >>>>>>> +++ b/lib/ssh/src/ssh_channel.erl >>>>>>> @@ -1,7 +1,7 @@ >>>>>>> %% >>>>>>> %% %CopyrightBegin% >>>>>>> %% >>>>>>> -%% Copyright Ericsson AB 2008-2011. All Rights Reserved. >>>>>>> +%% Copyright Ericsson AB 2008-2012. All Rights Reserved. >>>>>>> %% >>>>>>> %% The contents of this file are subject to the Erlang >>>>>>> Public >>>>>>> License, >>>>>>> %% Version 1.1, (the "License"); you may not use this file >>>>>>> except in >>>>>>> @@ -215,7 +215,7 @@ handle_info({ssh_cm, ConnectionManager, >>>>>>> {closed, ChannelId}}, >>>>>>> close_sent = false} = State) -> >>>>>>> %% To be on the safe side, i.e. the manager has already >>>>>>> been terminated. >>>>>>> (catch ssh_connection:close(ConnectionManager, >>>>>>> ChannelId)), >>>>>>> - {stop, normal, State}; >>>>>>> + {stop, normal, State#state{close_sent = true}}; >>>>>>> >>>>>>> handle_info({ssh_cm, _, _} = Msg, #state{cm = >>>>>>> ConnectionManager, >>>>>>> channel_cb = Module, >>>>>>> diff --git a/lib/ssh/src/ssh_connection_manager.erl >>>>>>> b/lib/ssh/src/ssh_connection_manager.erl >>>>>>> index e993f59..8c1f88e 100644 >>>>>>> --- a/lib/ssh/src/ssh_connection_manager.erl >>>>>>> +++ b/lib/ssh/src/ssh_connection_manager.erl >>>>>>> @@ -384,9 +384,10 @@ handle_call({close, ChannelId}, _, >>>>>>> #state{connection = Pid, connection_state = >>>>>>> #connection{channel_cache = Cache}} = >>>>>>> State) -> >>>>>>> case ssh_channel:cache_lookup(Cache, ChannelId) of >>>>>>> - #channel{remote_id = Id} -> >>>>>>> + #channel{remote_id = Id} = Channel -> >>>>>>> send_msg({connection_reply, Pid, >>>>>>> ssh_connection:channel_close_msg(Id)}), >>>>>>> + ssh_channel:cache_update(Cache, >>>>>>> Channel#channel{sent_close = true}), >>>>>>> {reply, ok, State}; >>>>>>> undefined -> >>>>>>> {reply, ok, State} >>>>>>> >>>>>>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> >>>>>>> Daniel Goertzen wrote: >>>>>>> >>>>>>> Under Putty Session->Logging can you turn on "SSH >>>>>>> Packets" >>>>>>> and post the log showing the error? >>>>>>> >>>>>>> Dan. >>>>>>> >>>>>>> On Sun, Apr 22, 2012 at 3:58 AM, Fyodor Ustinov >>>>>>> >>>>>> >> wrote: >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> Windows ssh client PuTTY show message >>>>>>> "Disconnected: >>>>>>> Received >>>>>>> SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 0" >>>>>>> while working >>>>>>> with erlang ssh daemon. >>>>>>> >>>>>>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] >>>>>>> [smp:8:8] >>>>>>> [async-threads:0] [kernel-poll:false] >>>>>>> >>>>>>> WBR, >>>>>>> Fyodor. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> erlang-bugs mailing list >>>>>>> erlang-bugs@REDACTED >>>>>>> >>>>>>> >>>>>> > >>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- *Daniel Goertzen | Senior Software >>>>>>> Engineer* >>>>>>> Office: 828.610.4596 | Fax: >>>>>>> 828.322.5294 | >>>>>>> dang@REDACTED >>>>>>> >>>>>>> >>>>>> > >>>>>>> *Network Integrity Systems | We Bring Security To >>>>>>> Light?* >>>>>>> >>>>>>> 1937 Tate Blvd. SE >>>>>>> >>>>>>> Hickory, North Carolina, USA 28602 >>>>>>> >>>>>>> /Network Integrity Systems? INTERCEPTOR? Optical >>>>>>> Network >>>>>>> Security System is a Smart-PDS? that ensures superior >>>>>>> protection and cost effectiveness of classified >>>>>>> networks. >>>>>>> For more information, visit our website >>>>>>> at:www.networkintegritysystems.com >>>>>>> >>>>>>> ./ >>>>>>> >>>>>>> >>>>>>> __________________________________________ >>>>>>> INTERCEPTOR? Optical Network Security System is made in >>>>>>> the USA for the USA. Although not an export controlled >>>>>>> item, because of the role it plays in the assurance >>>>>>> of the >>>>>>> safety and integrity of National Security Information, >>>>>>> Network Integrity Systems (NIS) is committed to >>>>>>> compliance >>>>>>> with the U.S. Export Administration Act. >>>>>>> Accordingly, NIS >>>>>>> will not ship INTERCEPTOR products to certain foreign >>>>>>> government end users without U.S. government >>>>>>> approval and >>>>>>> will refuse transactions with individuals or >>>>>>> entities that >>>>>>> have been denied export privileges. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> erlang-bugs mailing list >>>>>>> erlang-bugs@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> erlang-bugs mailing list >>>>>>> erlang-bugs@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Daniel Goertzen | Senior Software Engineer* >>>>>>> Office: 828.610.4596 | Fax: 828.322.5294 | >>>>>>> dang@REDACTED >>>>>>> >>>>>>> *Network Integrity Systems | We Bring Security To Light?* >>>>>>> >>>>>>> 1937 Tate Blvd. SE >>>>>>> >>>>>>> Hickory, North Carolina, USA 28602 >>>>>>> >>>>>>> /Network Integrity Systems? INTERCEPTOR? Optical Network >>>>>>> Security System is a Smart-PDS? that ensures superior protection >>>>>>> and cost effectiveness of classified networks. For more >>>>>>> information, visit our website >>>>>>> at:www.networkintegritysystems.com >>>>>>> ./ >>>>>>> >>>>>>> >>>>>>> __________________________________________ >>>>>>> INTERCEPTOR? Optical Network Security System is made in the USA >>>>>>> for the USA. Although not an export controlled item, because of >>>>>>> the role it plays in the assurance of the safety and integrity >>>>>>> of National Security Information, Network Integrity Systems >>>>>>> (NIS) is committed to compliance with the U.S. Export >>>>>>> Administration Act. Accordingly, NIS will not ship INTERCEPTOR >>>>>>> products to certain foreign government end users without U.S. >>>>>>> government approval and will refuse transactions with >>>>>>> individuals or entities that have been denied export privileges. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > From videlalvaro@REDACTED Fri May 4 13:25:11 2012 From: videlalvaro@REDACTED (Alvaro Videla) Date: Fri, 4 May 2012 13:25:11 +0200 Subject: [erlang-bugs] epmd fails to start In-Reply-To: <36FAA97FB521470B8668928069340FF7@gmail.com> References: <36FAA97FB521470B8668928069340FF7@gmail.com> Message-ID: Hi, Any comments on this issue? Regards, Alvaro On Sun, Apr 22, 2012 at 11:56 AM, Alvaro Videla wrote: > Hi, > > I've found a but that if Erlang is installed in a path with spaces then > _epmd_ fails to start when started automatically by _erl_. You can still > start epmd manually. > > Platform where the bug happens: Linux & Mac (where I tested at least). > > How to reproduce: > > Install Erlang in a path with spaces like "/tmp/path with spaces/" > > Start Erlang like this: > > erl -sname foo > > You will get this error: > > sh: /tmp/path: No such file or directory > {error_logger,{{2012,4,22},{11,50,7}},"Protocol: ~p: register error: > ~p~n",["inet_tcp",{{badmatch,{error,econnrefused}},[{inet_tcp_dist,listen,1,[{file,"inet_tcp_dist.erl"},{line,70}]},{net_kernel,start_protos,4,[{file,"net_kernel.erl"},{line,1314}]},{net_kernel,start_protos,3,[{file,"net_kernel.erl"},{line,1307}]},{net_kernel,init_node,2,[{file,"net_kernel.erl"},{line,1197}]},{net_kernel,init,1,[{file,"net_kernel.erl"},{line,357}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}]} > > {error_logger,{{2012,4,22},{11,50,7}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.19.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,320}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[#Port<0.53>,<0.16.0>]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,474}],[]]} > > {error_logger,{{2012,4,22},{11,50,7}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfargs,{net_kernel,start_link,[[a,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} > > {error_logger,{{2012,4,22},{11,50,7}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} > > {error_logger,{{2012,4,22},{11,50,7}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} > {"Kernel pid > terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) > > If you DTrace it like this for example: > > sudo dtruss -f ./erts-5.9.1/bin/erl -boot ./releases/2.8.1/start_clean > -sname a > > > You will see that the error happens in this system call: > > > execve("/tmp/path\0", 0x10C204BD0, 0x10C2049E0) = -1 Err#2 > > > Which I think is part of this file: erts/emulator/sys/unix/sys.c > > In the Mac is quite common to have User home folders in path with spaces. > I've found this while trying to create an Erlang release and distribute it > via inside a Mac.app > > The bug happens in R15B01 so I guess it also appears in earlier versions. > > Also perhaps if epmd is not running for whatever the reason maybe Erlang > could give a more meaningful error. > > Regards, > > Alvaro > > -- > Sent with Sparrow > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vychodil.hynek@REDACTED Fri May 4 14:09:38 2012 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Fri, 4 May 2012 14:09:38 +0200 Subject: [erlang-bugs] binary:compile_pattern/1 spec doesn't match binary:cp() opaque definition Message-ID: Hello, binary:compile_pattern/1 spec makes dialyzer unhappy. This minimal module shows it. -module(binary_compile_dialyzer_issue). -export([test/0]). test() -> binary:split(<<>>, binary:compile_pattern(<<>>), []). Dialyzer output is $ dialyzer -q binary_compile_dialyzer_issue.erl binary_compile_dialyzer_issue.erl:5: Function test/0 has no local return binary_compile_dialyzer_issue.erl:6: The call binary:split(#{}#,{'ac',binary()} | {'bm',binary()},[]) does not have a term of type binary() | [binary()] | binary:cp() (with opaque subterms) as 2nd argument If I understand it right /usr/lib/erlang/lib/hipe-3.9.1/cerl/erl_bif_types.erl:4672 t_binary_compiled_pattern() -> t_tuple([t_sup(t_atom('bm'), t_atom('ac')), t_binary()]). should return opaque type. Unfortunately I seems not skilled enough to provide patch. Best regards -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss.? Be a data hero! Try GoodData now for free: www.gooddata.com From lukas@REDACTED Fri May 4 15:30:43 2012 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 4 May 2012 15:30:43 +0200 Subject: [erlang-bugs] binary:compile_pattern/1 spec doesn't match binary:cp() opaque definition In-Reply-To: References: Message-ID: <4FA3DA03.8070102@erlang.org> Hi, Which version of Erlang are you running? The specs of BIFs in the master branch on github (which will be part of the R16 release) have been completely rewritten so the issue might be fixed there. Lukas On 04/05/12 14:09, Hynek Vychodil wrote: > Hello, > > binary:compile_pattern/1 spec makes dialyzer unhappy. This minimal > module shows it. > > -module(binary_compile_dialyzer_issue). > > -export([test/0]). > > test() -> > binary:split(<<>>, binary:compile_pattern(<<>>), []). > > Dialyzer output is > > $ dialyzer -q binary_compile_dialyzer_issue.erl > > binary_compile_dialyzer_issue.erl:5: Function test/0 has no local return > binary_compile_dialyzer_issue.erl:6: The call > binary:split(#{}#,{'ac',binary()} | {'bm',binary()},[]) does not have > a term of type binary() | [binary()] | binary:cp() (with opaque > subterms) as 2nd argument > > If I understand it right > > /usr/lib/erlang/lib/hipe-3.9.1/cerl/erl_bif_types.erl:4672 > t_binary_compiled_pattern() -> > t_tuple([t_sup(t_atom('bm'), t_atom('ac')), t_binary()]). > > should return opaque type. Unfortunately I seems not skilled enough to > provide patch. > > Best regards > From hynek@REDACTED Fri May 4 17:47:25 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Fri, 4 May 2012 17:47:25 +0200 Subject: [erlang-bugs] binary:compile_pattern/1 spec doesn't match binary:cp() opaque definition In-Reply-To: <4FA3DA03.8070102@erlang.org> References: <4FA3DA03.8070102@erlang.org> Message-ID: On Fri, May 4, 2012 at 3:30 PM, Lukas Larsson wrote: > Hi, > > Which version of Erlang are you running? > > The specs of BIFs in the master branch on github (which will be part of the > R16 release) have been completely rewritten so the issue might be fixed > there. > > Lukas Erlang R15B01 (erts-5.9.1) > > > On 04/05/12 14:09, Hynek Vychodil wrote: >> >> Hello, >> >> binary:compile_pattern/1 spec makes dialyzer unhappy. This minimal >> module shows it. >> >> -module(binary_compile_dialyzer_issue). >> >> -export([test/0]). >> >> test() -> >> ? binary:split(<<>>, binary:compile_pattern(<<>>), []). >> >> Dialyzer output is >> >> $ dialyzer -q binary_compile_dialyzer_issue.erl >> >> binary_compile_dialyzer_issue.erl:5: Function test/0 has no local return >> binary_compile_dialyzer_issue.erl:6: The call >> binary:split(#{}#,{'ac',binary()} | {'bm',binary()},[]) does not have >> a term of type binary() | [binary()] | binary:cp() (with opaque >> subterms) as 2nd argument >> >> If I understand it right >> >> /usr/lib/erlang/lib/hipe-3.9.1/cerl/erl_bif_types.erl:4672 >> t_binary_compiled_pattern() -> >> ? t_tuple([t_sup(t_atom('bm'), t_atom('ac')), t_binary()]). >> >> should return opaque type. Unfortunately I seems not skilled enough to >> provide patch. >> >> Best regards >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Hynek Vychodil Chief Scientists GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From jovan@REDACTED Sat May 5 14:01:14 2012 From: jovan@REDACTED (=?iso-8859-1?Q?J=F3van_Sean_Dippenaar?=) Date: Sat, 5 May 2012 14:01:14 +0200 Subject: [erlang-bugs] Common Test 1.6.1 - Surefire Message-ID: Errors in Common Test 1.6.1 - cth_surefire.erl cth_surefire.erl has a two errors : 1. " on_tc_fail( TC, Res, State)" should be "on_tc_fail(_Tc, Res, State)", as the TC causes a bad match on inside the function with regards to the TC record. this causes surefire results to generate .xml which indicate passed tests when in actual fact the tests have failed. 2. failures in "init_per_suite" cause "on_tc_skip" to be called which is correct up until "on_tc_skip" is called for "end_per_suite" as well. This also means that "post_end_per_suite" is never called, which is the problem. As "post_end_per_suite" takes all test cases results and places in State#state{ test_suites ). This is important as the xml generation on terminate iterates thru the test suites. here's a fix : on_tc_skip(Tc, Res, State) -> TCs = State#state.test_cases, [TC | RestTCs ] = TCs, {CurTC, CurRestTCs} = case TC#testcase.failure of passed -> {TC, RestTCs}; _OtherFailure -> Name = atom_to_list(Tc), NTC = new_tc_rec(Name, State#state{timer = now()}), {NTC, TCs} end, NewTC = CurTC#testcase{ failure = {skipped, lists:flatten(io_lib:format("~p",[Res])) } }, NewState = State#state{ test_cases = [NewTC | CurRestTCs]}, case Tc of end_per_suite -> Suite = get_suite(NewState, TCs), AltState = NewState#state{ test_cases = [], test_suites = [Suite | NewState#state.test_suites]}, AltState; _Other -> NewState end. / Jovan Sean Dippenaar - Aeonmind Enterprises -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-7.pdf Type: application/pdf Size: 35462 bytes Desc: not available URL: -------------- next part -------------- From luis.rascao@REDACTED Sun May 6 21:22:45 2012 From: luis.rascao@REDACTED (=?ISO-8859-1?Q?Luis_Rasc=E3o?=) Date: Sun, 6 May 2012 20:22:45 +0100 Subject: [erlang-bugs] [driver_select in windows] no handlers fired on socket activity, possible bug? Message-ID: Hi all, I made an erlang port driver that simply does the following: - initializes with a start() method - creates a socket, binds on port 5555 and invokes listen on it on a listen method - invoke driver_select for said socket with ERL_DRV_READ set - the port driver declares a ready_input on the ErlDrvEntry structure - on linux, when i connect to port 5555, the ready_input fires up correctly - on windows, i get nothing, no handler is fired up i tried with a bunch of different erlang versions including the latest (R15B01) and keep getting the same problem is there something i'm missing? is there some special directive that should be issued for windows? i'm attaching this simple port driver along with the vs2010 solution that i'm using for building it (located in build-aux\msvc) any help would be greatly appreciated Luis Rasc?o -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tcp_drv.zip Type: application/zip Size: 13980 bytes Desc: not available URL: From lukas@REDACTED Mon May 7 09:39:47 2012 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 7 May 2012 09:39:47 +0200 Subject: [erlang-bugs] binary:compile_pattern/1 spec doesn't match binary:cp() opaque definition In-Reply-To: References: <4FA3DA03.8070102@erlang.org> Message-ID: <4FA77C43.4040607@erlang.org> Hi, I just confirmed that this has been fixed in the master branch which will be released in the next major release. Lukas On 04/05/12 17:47, Hynek Vychodil wrote: > On Fri, May 4, 2012 at 3:30 PM, Lukas Larsson wrote: >> Hi, >> >> Which version of Erlang are you running? >> >> The specs of BIFs in the master branch on github (which will be part of the >> R16 release) have been completely rewritten so the issue might be fixed >> there. >> >> Lukas > Erlang R15B01 (erts-5.9.1) > >> >> On 04/05/12 14:09, Hynek Vychodil wrote: >>> Hello, >>> >>> binary:compile_pattern/1 spec makes dialyzer unhappy. This minimal >>> module shows it. >>> >>> -module(binary_compile_dialyzer_issue). >>> >>> -export([test/0]). >>> >>> test() -> >>> binary:split(<<>>, binary:compile_pattern(<<>>), []). >>> >>> Dialyzer output is >>> >>> $ dialyzer -q binary_compile_dialyzer_issue.erl >>> >>> binary_compile_dialyzer_issue.erl:5: Function test/0 has no local return >>> binary_compile_dialyzer_issue.erl:6: The call >>> binary:split(#{}#,{'ac',binary()} | {'bm',binary()},[]) does not have >>> a term of type binary() | [binary()] | binary:cp() (with opaque >>> subterms) as 2nd argument >>> >>> If I understand it right >>> >>> /usr/lib/erlang/lib/hipe-3.9.1/cerl/erl_bif_types.erl:4672 >>> t_binary_compiled_pattern() -> >>> t_tuple([t_sup(t_atom('bm'), t_atom('ac')), t_binary()]). >>> >>> should return opaque type. Unfortunately I seems not skilled enough to >>> provide patch. >>> >>> Best regards >>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > From lukas@REDACTED Mon May 7 17:25:12 2012 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 7 May 2012 17:25:12 +0200 Subject: [erlang-bugs] Common Test 1.6.1 - Surefire In-Reply-To: References: Message-ID: <4FA7E958.6060409@erlang.org> Hello, Thanks for the bug report and provided fix. I'll include it in the next release. I'm a bit uncertain what you mean with the first issue though. The code is already the way you propose it to be: https://github.com/erlang/otp/blob/bb1734e95a5f6a7315819c24bc1fdd799534c787/lib/common_test/src/cth_surefire.erl#L86 Lukas On 05/05/12 14:01, J?van Sean Dippenaar wrote: > Errors in Common Test 1.6.1 - cth_surefire.erl > > > cth_surefire.erl has a two errors : > > 1. " on_tc_fail( TC, Res, State)" should be "on_tc_fail(_Tc, Res, State)", as the TC causes a bad match on inside the function with regards to the TC record. > this causes surefire results to generate .xml which indicate passed tests when in actual fact the tests have failed. > > 2. failures in "init_per_suite" cause "on_tc_skip" to be called which is correct up until "on_tc_skip" is called for "end_per_suite" as well. This also means that > "post_end_per_suite" is never called, which is the problem. As "post_end_per_suite" takes all test cases results and places in State#state{ test_suites ). > This is important as the xml generation on terminate iterates thru the test suites. > > here's a fix : > > on_tc_skip(Tc, Res, State) -> > TCs = State#state.test_cases, > [TC | RestTCs ] = TCs, > {CurTC, CurRestTCs} = case TC#testcase.failure of > passed -> {TC, RestTCs}; > _OtherFailure -> > Name = atom_to_list(Tc), > NTC = new_tc_rec(Name, State#state{timer = now()}), > {NTC, TCs} > end, > > NewTC = CurTC#testcase{ > failure = {skipped, lists:flatten(io_lib:format("~p",[Res])) } > }, > NewState = State#state{ test_cases = [NewTC | CurRestTCs]}, > > case Tc of > end_per_suite -> > Suite = get_suite(NewState, TCs), > AltState = NewState#state{ test_cases = [], test_suites = [Suite | NewState#state.test_suites]}, > AltState; > _Other -> > NewState > end. > > > > > / Jovan Sean Dippenaar - Aeonmind Enterprises > > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jovan@REDACTED Tue May 8 10:49:14 2012 From: jovan@REDACTED (=?iso-8859-1?Q?J=F3van_Sean_Dippenaar?=) Date: Tue, 8 May 2012 10:49:14 +0200 Subject: [erlang-bugs] Common Test 1.6.1 - Surefire In-Reply-To: <4FA7E958.6060409@erlang.org> References: <4FA7E958.6060409@erlang.org> Message-ID: <32AE59C0-BAD2-4170-959D-9164CB3A07F1@aeonmind.co.za> Good day I must have changed it when debugging "skipped" tests problem, I was experiencing in bamboo. Due to observing that the "on_tc_skip" uses " _Tc " ( note small 'c' ), noting that Tc is an atom and TC is a record. Hence when debugging "on_tc_fail" I unwittingly removed the underscore for a debug, thinking that it would not conflict. ( the curse of long working hours :) ) A note on skipped test cases in bamboo : The JUnit parser in bamboo does not acknowledge "skipped" test cases, which unfortunately cause a "false positive" sistuation. Changing the "skipped" to "failed", the bamboo junit parser shows the failed test cases. I personally prefer this when for project management reasons. I hope is helps anyone integrating into bamboo. / Jovan Sean Dippenaar - Aeonmind Enterprises On 07 May 2012, at 5:25 PM, Lukas Larsson wrote: > Hello, > > Thanks for the bug report and provided fix. I'll include it in the next release. > > I'm a bit uncertain what you mean with the first issue though. The code is already the way you propose it to be: https://github.com/erlang/otp/blob/bb1734e95a5f6a7315819c24bc1fdd799534c787/lib/common_test/src/cth_surefire.erl#L86 > > Lukas > > On 05/05/12 14:01, J?van Sean Dippenaar wrote: >> >> Errors in Common Test 1.6.1 - cth_surefire.erl >> >> >> cth_surefire.erl has a two errors : >> >> 1. " on_tc_fail( TC, Res, State)" should be "on_tc_fail(_Tc, Res, State)", as the TC causes a bad match on inside the function with regards to the TC record. >> this causes surefire results to generate .xml which indicate passed tests when in actual fact the tests have failed. >> >> 2. failures in "init_per_suite" cause "on_tc_skip" to be called which is correct up until "on_tc_skip" is called for "end_per_suite" as well. This also means that >> "post_end_per_suite" is never called, which is the problem. As "post_end_per_suite" takes all test cases results and places in State#state{ test_suites ). >> This is important as the xml generation on terminate iterates thru the test suites. >> >> here's a fix : >> >> on_tc_skip(Tc, Res, State) -> >> TCs = State#state.test_cases, >> [TC | RestTCs ] = TCs, >> {CurTC, CurRestTCs} = case TC#testcase.failure of >> passed -> {TC, RestTCs}; >> _OtherFailure -> >> Name = atom_to_list(Tc), >> NTC = new_tc_rec(Name, State#state{timer = now()}), >> {NTC, TCs} >> end, >> >> NewTC = CurTC#testcase{ >> failure = {skipped, lists:flatten(io_lib:format("~p",[Res])) } >> }, >> NewState = State#state{ test_cases = [NewTC | CurRestTCs]}, >> >> case Tc of >> end_per_suite -> >> Suite = get_suite(NewState, TCs), >> AltState = NewState#state{ test_cases = [], test_suites = [Suite | NewState#state.test_suites]}, >> AltState; >> _Other -> >> NewState >> end. >> >> >> >> >> / Jovan Sean Dippenaar - Aeonmind Enterprises >> >> >> >> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-7.pdf Type: application/pdf Size: 35462 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jovan@REDACTED Tue May 8 14:37:20 2012 From: jovan@REDACTED (=?iso-8859-1?Q?J=F3van_Sean_Dippenaar?=) Date: Tue, 8 May 2012 14:37:20 +0200 Subject: [erlang-bugs] Common Test 1.6.1 - Surefire In-Reply-To: <32AE59C0-BAD2-4170-959D-9164CB3A07F1@aeonmind.co.za> References: <4FA7E958.6060409@erlang.org> <32AE59C0-BAD2-4170-959D-9164CB3A07F1@aeonmind.co.za> Message-ID: <432CB421-C671-41A1-BA7C-E074BB531DD8@aeonmind.co.za> Snippet of "skipped" test cases change for bamboo integration. to_xml(#testcase{ group = Group, classname = CL, log = L, name = N, time = T, timestamp = TS, failure = F}) -> ["", case F of passed -> []; {skipped,Reason} -> ["", sanitize(Reason),""]; {fail,Reason} -> ["", sanitize(Reason),""] end, ""]; /Jovan Sean Dippenaar - Aeonmind Enterprises On 08 May 2012, at 10:49 AM, J?van Sean Dippenaar wrote: > Good day > > > I must have changed it when debugging "skipped" tests problem, I was experiencing in bamboo. > > Due to observing that the "on_tc_skip" uses " _Tc " ( note small 'c' ), noting that Tc is an atom and TC > is a record. Hence when debugging "on_tc_fail" I unwittingly removed the underscore for a debug, thinking that it would not conflict. ( the curse of long working hours :) ) > > > A note on skipped test cases in bamboo : > > The JUnit parser in bamboo does not acknowledge "skipped" test cases, which unfortunately cause a "false positive" sistuation. > Changing the "skipped" to "failed", the bamboo junit parser shows the failed test cases. I personally prefer this when for project management reasons. > > I hope is helps anyone integrating into bamboo. > > > > / Jovan Sean Dippenaar - Aeonmind Enterprises > > > > > > On 07 May 2012, at 5:25 PM, Lukas Larsson wrote: > >> Hello, >> >> Thanks for the bug report and provided fix. I'll include it in the next release. >> >> I'm a bit uncertain what you mean with the first issue though. The code is already the way you propose it to be: https://github.com/erlang/otp/blob/bb1734e95a5f6a7315819c24bc1fdd799534c787/lib/common_test/src/cth_surefire.erl#L86 >> >> Lukas >> >> On 05/05/12 14:01, J?van Sean Dippenaar wrote: >>> >>> Errors in Common Test 1.6.1 - cth_surefire.erl >>> >>> >>> cth_surefire.erl has a two errors : >>> >>> 1. " on_tc_fail( TC, Res, State)" should be "on_tc_fail(_Tc, Res, State)", as the TC causes a bad match on inside the function with regards to the TC record. >>> this causes surefire results to generate .xml which indicate passed tests when in actual fact the tests have failed. >>> >>> 2. failures in "init_per_suite" cause "on_tc_skip" to be called which is correct up until "on_tc_skip" is called for "end_per_suite" as well. This also means that >>> "post_end_per_suite" is never called, which is the problem. As "post_end_per_suite" takes all test cases results and places in State#state{ test_suites ). >>> This is important as the xml generation on terminate iterates thru the test suites. >>> >>> here's a fix : >>> >>> on_tc_skip(Tc, Res, State) -> >>> TCs = State#state.test_cases, >>> [TC | RestTCs ] = TCs, >>> {CurTC, CurRestTCs} = case TC#testcase.failure of >>> passed -> {TC, RestTCs}; >>> _OtherFailure -> >>> Name = atom_to_list(Tc), >>> NTC = new_tc_rec(Name, State#state{timer = now()}), >>> {NTC, TCs} >>> end, >>> >>> NewTC = CurTC#testcase{ >>> failure = {skipped, lists:flatten(io_lib:format("~p",[Res])) } >>> }, >>> NewState = State#state{ test_cases = [NewTC | CurRestTCs]}, >>> >>> case Tc of >>> end_per_suite -> >>> Suite = get_suite(NewState, TCs), >>> AltState = NewState#state{ test_cases = [], test_suites = [Suite | NewState#state.test_suites]}, >>> AltState; >>> _Other -> >>> NewState >>> end. >>> >>> >>> >>> >>> / Jovan Sean Dippenaar - Aeonmind Enterprises >>> >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-7.pdf Type: application/pdf Size: 35462 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericbmerritt@REDACTED Wed May 9 16:51:57 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Wed, 9 May 2012 09:51:57 -0500 Subject: [erlang-bugs] Issues integrating Common Test into CI frameworks Message-ID: Guys, ct_run does not return a non-zero exit status on failure. This is needed to integrate well in any make based environment, which includes many of the continuous integration systems out there. There are work arounds for this, but I think this is something that should probably at the source. Eric From peppe@REDACTED Wed May 9 23:20:59 2012 From: peppe@REDACTED (Peter Andersson) Date: Wed, 9 May 2012 23:20:59 +0200 Subject: [erlang-bugs] Issues integrating Common Test into CI frameworks In-Reply-To: References: Message-ID: Hi Eric, Thanks for the report. I can certainly see the usefulness, and I agree it should be implemented in ct_run preferrably. We need to look into a few things, such as what (besides failing test cases obviously), should result in non-zero exit. Auto skips? Failing end configuration functions? I'll create a ticket and give this some more thought. I'll get back to you. Best regards, Peter On Wed, 9 May 2012, Eric Merritt wrote: > Guys, > > ct_run does not return a non-zero exit status on failure. This is > needed to integrate well in any make based environment, which includes > many of the continuous integration systems out there. There are work > arounds for this, but I think this is something that should probably > at the source. > > Eric > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From beads.d.land@REDACTED Thu May 10 18:15:05 2012 From: beads.d.land@REDACTED (Beads Land-Trujillo) Date: Thu, 10 May 2012 12:15:05 -0400 Subject: [erlang-bugs] Issues integrating Common Test into CI frameworks In-Reply-To: References: Message-ID: <011d01cd2ec8$10ad9280$3208b780$@gmail.com> Hi Peter, Eric, A thought that probably occurred to you already, but perhaps what returns non-zero might be controlled by flag options? - Beads http://twitter.com/beadsland From fritchie@REDACTED Thu May 10 22:57:19 2012 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 10 May 2012 15:57:19 -0500 Subject: [erlang-bugs] SystemTap kludge omitted from DTrace mega-patch for R15B01 Message-ID: <28988.1336683439@snookles.snookles.com> Hi, all. I just noticed that there was one part of my DTrace mega-patch for R1501 that was omitted ... and causes some icky problems for SystemTap. That change looked mostly like this: https://github.com/slfritchie/otp/commit/f4d2ff83f550244e5fa36472ad06231624b256cd ... and was included in the 5-part squished feature branch that was submitted to the OTP team for the R15B01 release. I assume that this particular kludge wasn't used because it is ugly? Well, granted, it's quite ugly. But it makes stuff *work*. From some small testing efforts with SystemTap 1.6, a kludge-less build does not work correctly. Nor does Solaris 10, though the loss of function is much smaller for Solaris 10 than for Linux's SystemTap. What is the tolerance level for this kind of ugliness for R15B02? I've started putting Erlang-triggered probes into Riak, but if the entire SystemTap-using community cannot get those probes to work, then the value of adding the probes is significantly diminished. -Scott From gli@REDACTED Fri May 11 15:59:12 2012 From: gli@REDACTED (Ivan Glushkov) Date: Fri, 11 May 2012 17:59:12 +0400 Subject: [erlang-bugs] List comprehension generate "function clause" exception instead of "bad generator" Message-ID: Hi. We have found recently an interesting behaviour: - erlang console generate "bad generator" exception for the code: 1> [ {A,B} || {A,B} <- aaa ]. ** exception error: bad generator aaa - if compiled, the code throw "function clause" exception: $ cat a.erl -module(a). -export([a/1]). a(List) -> [ {A,B} || {A,B} <- List ]. $ erl 1> c(a). {ok,a} 2> a:a(aaa). ** exception error: no function clause matching a:'-a/1-lc$^0/1-0-'(aaa) The reason is that new anonymous function is created to handle the list comprehension, but it expects only lists. So incorrect generator also would cause a "function clause" exception. I suppose that the reason of such an exception here is for the similarity with the lists:map, it also generates a "function clause" for unsupported arguments: 2> lists:map(fun(A) -> A end, aaa). ** exception error: no function clause matching lists:map(#Fun,aaa) To my mind this behavior is not correct as somebody might expect "bad generator" exception and he will try to catch it, but instead another exception is thrown. Ivan From vjache@REDACTED Fri May 11 16:43:23 2012 From: vjache@REDACTED (Vyacheslav Vorobyov) Date: Fri, 11 May 2012 18:43:23 +0400 Subject: [erlang-bugs] rpc:call hide throw Message-ID: Hello, % 1. Good behavior {badrpc,{'EXIT', some_reson }} = rpc:call(node(),erlang,exit,[some_reson]). % 2. Bad behavior some_reson = rpc:call(node(),erlang,throw,[some_reson]). The second case describes an issue. It makes indistinguishable normal result from exception. -- Best Regargs, ? ?? Vyacheslav From beads.d.land@REDACTED Sat May 12 00:40:44 2012 From: beads.d.land@REDACTED (Beads Land-Trujillo) Date: Fri, 11 May 2012 18:40:44 -0400 Subject: [erlang-bugs] lists:suffix/2 (R15B01 x64) Message-ID: <014001cd2fc7$1ac778d0$50566a70$@gmail.com> Not the behaviour I was expecting: Running Erlang Eshell V5.9.1 (abort with ^G) 1> lists:suffix("ala", "a") false Is this a release-wide issue? - Beads http://tanglelabs.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc@REDACTED Sat May 12 00:48:59 2012 From: nc@REDACTED (Nicolas Charpentier) Date: Fri, 11 May 2012 23:48:59 +0100 Subject: [erlang-bugs] lists:suffix/2 (R15B01 x64) In-Reply-To: <014001cd2fc7$1ac778d0$50566a70$@gmail.com> References: <014001cd2fc7$1ac778d0$50566a70$@gmail.com> Message-ID: <994765C7-AC3A-4EAC-A0C9-502B417007D0@charpi.net> http://www.erlang.org/doc/man/lists.html#suffix-2 suffix(List1, List2) -> boolean() Returns true if List1 is a suffix of List2, otherwise false I think you wanted to call lists:suffix("a", "ala"). /Nicolas On 11 May 2012, at 23:40, Beads Land-Trujillo wrote: > Not the behaviour I was expecting: > > Running Erlang > Eshell V5.9.1 (abort with ^G) > 1> lists:suffix("ala", "a") > false > > Is this a release-wide issue? > > - Beads > > http://tanglelabs.com/ > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From beads.d.land@REDACTED Sat May 12 02:40:02 2012 From: beads.d.land@REDACTED (Beads Land-Trujillo) Date: Fri, 11 May 2012 20:40:02 -0400 Subject: [erlang-bugs] lists:suffix/2 (R15B01 x64) In-Reply-To: <994765C7-AC3A-4EAC-A0C9-502B417007D0@charpi.net> References: <014001cd2fc7$1ac778d0$50566a70$@gmail.com> <994765C7-AC3A-4EAC-A0C9-502B417007D0@charpi.net> Message-ID: <015001cd2fd7$c51eda20$4f5c8e60$@gmail.com> Doh! - Beads http://tanglelabs.com/ From: Nicolas Charpentier [mailto:nc@REDACTED] Sent: Friday, May 11, 2012 6:49 PM To: Beads Land-Trujillo Cc: erlang-bugs@REDACTED Subject: Re: [erlang-bugs] lists:suffix/2 (R15B01 x64) http://www.erlang.org/doc/man/lists.html#suffix-2 suffix(List1, List2) -> boolean() Returns true if List1 is a suffix of List2, otherwise false I think you wanted to call lists:suffix("a", "ala"). /Nicolas On 11 May 2012, at 23:40, Beads Land-Trujillo wrote: Not the behaviour I was expecting: Running Erlang Eshell V5.9.1 (abort with ^G) 1> lists:suffix("ala", "a") false Is this a release-wide issue? - Beads http://tanglelabs.com/ _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From vjache@REDACTED Sat May 12 22:53:43 2012 From: vjache@REDACTED (Vyacheslav Vorobyov) Date: Sun, 13 May 2012 00:53:43 +0400 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Vyacheslav Vorobyov Date: 2012/5/11 Subject: rpc:call hide throw To: erlang-bugs@REDACTED Hello, % 1. Good behavior {badrpc,{'EXIT', some_reson }} = rpc:call(node(),erlang,exit,[some_reson]). % 2. Bad behavior some_reson = rpc:call(node(),erlang,throw,[some_reson]). The second case describes an issue. It makes indistinguishable normal result from exception. -- Best Regargs, ? ?? Vyacheslav -- Best Regargs, ? ?? Vyacheslav From robert.virding@REDACTED Mon May 14 08:33:24 2012 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 14 May 2012 07:33:24 +0100 (BST) Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: Message-ID: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See http://www.erlang.org/doc/man/erlang.html#throw-1 We don't throw errors in erlang. :-) Robert ----- Original Message ----- > ---------- Forwarded message ---------- > From: Vyacheslav Vorobyov > Date: 2012/5/11 > Subject: rpc:call hide throw > To: erlang-bugs@REDACTED > > > Hello, > > % 1. Good behavior > {badrpc,{'EXIT', some_reson }} = > rpc:call(node(),erlang,exit,[some_reson]). > > % 2. Bad behavior > some_reson = rpc:call(node(),erlang,throw,[some_reson]). > > The second case describes an issue. It makes indistinguishable normal > result from exception. > > > -- > Best Regargs, > ? ?? Vyacheslav > > > -- > Best Regargs, > ? ?? Vyacheslav > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From carlsson.richard@REDACTED Mon May 14 11:12:13 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 14 May 2012 11:12:13 +0200 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> References: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> Message-ID: <4FB0CC6D.4030505@gmail.com> Well, a "nonlocal return" is also an exception. It's just a different class of exception than exits and errors. The question here is whether the rpc really ought to catch the trow and convert it to a regular return value, as done currently, or if it should let the caller know for sure that the code terminated with a throw. The documentation for rpc:call() just says that you should get {badrpc, Reason} "if the call fails". And exactly what Reason is in this case is not specified further. Turns out, it's whatever you got from "catch apply(M,F,As)" if that yields {'EXIT',...}, so if the rpc failed with an error, you get a stack trace, but if it failed with an exit, you don't get a stack trace. This is all rather messy. /Richard On 2012-05-14 08:33, Robert Virding wrote: > erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See > > http://www.erlang.org/doc/man/erlang.html#throw-1 > > We don't throw errors in erlang. :-) > > Robert > > ----- Original Message ----- >> ---------- Forwarded message ---------- >> From: Vyacheslav Vorobyov >> Date: 2012/5/11 >> Subject: rpc:call hide throw >> To: erlang-bugs@REDACTED >> >> >> Hello, >> >> % 1. Good behavior >> {badrpc,{'EXIT', some_reson }} = >> rpc:call(node(),erlang,exit,[some_reson]). >> >> % 2. Bad behavior >> some_reson = rpc:call(node(),erlang,throw,[some_reson]). >> >> The second case describes an issue. It makes indistinguishable normal >> result from exception. >> >> >> -- >> Best Regargs, >> Vyacheslav >> >> >> -- >> Best Regargs, >> Vyacheslav >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From vjache@REDACTED Mon May 14 16:17:42 2012 From: vjache@REDACTED (Vyacheslav Vorobyov) Date: Mon, 14 May 2012 18:17:42 +0400 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> References: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> Message-ID: Let me disagree with "erlang:throw/1 does not generate an exception". Am I wrong addressing you to http://www.erlang.org/doc/reference_manual/errors.html#id81437. I think it does generate exception of class 'throw' ;-) About "We don't throw errors in erlang.", probably yes, but we also don't want to loose (hide) information when using rpc:call. Information about HOW value returned. Currently rpc:call provides us with doubtful "service" it decides for us that normally returned value and thrown one are "equally good". 2012/5/14 Robert Virding : > erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See > > http://www.erlang.org/doc/man/erlang.html#throw-1 > > We don't throw errors in erlang. :-) > > Robert > > ----- Original Message ----- >> ---------- Forwarded message ---------- >> From: Vyacheslav Vorobyov >> Date: 2012/5/11 >> Subject: rpc:call hide throw >> To: erlang-bugs@REDACTED >> >> >> Hello, >> >> % 1. Good behavior >> {badrpc,{'EXIT', some_reson }} = >> rpc:call(node(),erlang,exit,[some_reson]). >> >> % 2. Bad behavior >> some_reson = rpc:call(node(),erlang,throw,[some_reson]). >> >> The second case describes an issue. It makes indistinguishable normal >> result from exception. >> >> >> -- >> Best Regargs, >> ? ?? Vyacheslav >> >> >> -- >> Best Regargs, >> ? ?? Vyacheslav >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> -- Best Regargs, ? ?? Vyacheslav From ericbmerritt@REDACTED Mon May 14 16:31:47 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Mon, 14 May 2012 09:31:47 -0500 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: References: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> Message-ID: Just to throw my 2c and agree with the original poster. Regardless of whether exceptions are encouraged or not, the fact is that thrown exceptions are a documented part of the language, and for rpc:call not to return some indicator of the excepted state is broken. I would equate this to the use of 'catch'. The argument against that use that you can't tell valid return values from thrown return values. The solution is "don't use catch, use one of the try forms". That same argument would seem to apply here. However, In this case there is no form that propagates the exception in any way. Perhaps some additional rpc:call_ or rpc:_call needs to be added that either propagates the exception as an exception (problematic I know) or wraps all values in a tuple in the normal erlang way. `{ok, }` or `{exit | throw | error, }`. On Mon, May 14, 2012 at 9:17 AM, Vyacheslav Vorobyov wrote: > Let me disagree with "erlang:throw/1 does not generate an exception". > > Am I wrong addressing you to > http://www.erlang.org/doc/reference_manual/errors.html#id81437. I > think it does generate exception of class 'throw' ;-) > > About "We don't throw errors in erlang.", probably yes, but we also > don't want to loose (hide) information when using rpc:call. > Information about HOW value returned. Currently rpc:call provides us > with doubtful "service" it decides for us that normally returned value > and thrown one are "equally good". > > 2012/5/14 Robert Virding : >> erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See >> >> http://www.erlang.org/doc/man/erlang.html#throw-1 >> >> We don't throw errors in erlang. :-) >> >> Robert >> >> ----- Original Message ----- >>> ---------- Forwarded message ---------- >>> From: Vyacheslav Vorobyov >>> Date: 2012/5/11 >>> Subject: rpc:call hide throw >>> To: erlang-bugs@REDACTED >>> >>> >>> Hello, >>> >>> % 1. Good behavior >>> {badrpc,{'EXIT', some_reson }} = >>> rpc:call(node(),erlang,exit,[some_reson]). >>> >>> % 2. Bad behavior >>> some_reson = rpc:call(node(),erlang,throw,[some_reson]). >>> >>> The second case describes an issue. It makes indistinguishable normal >>> result from exception. >>> >>> >>> -- >>> Best Regargs, >>> ? ?? Vyacheslav >>> >>> >>> -- >>> Best Regargs, >>> ? ?? Vyacheslav >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> > > > > -- > Best Regargs, > ? ?? Vyacheslav > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From samuelrivas@REDACTED Mon May 14 17:23:45 2012 From: samuelrivas@REDACTED (Samuel) Date: Mon, 14 May 2012 17:23:45 +0200 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: References: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> Message-ID: > I would equate this to the use of 'catch'. The argument against that > use that you can't tell valid return values from thrown return values. > The solution is "don't use catch, use one of the try forms". ?That > same argument would seem to apply here. However, In this case there is > no form that propagates the exception in any way. Perhaps some > additional rpc:call_ or rpc:_call needs to be added that either > propagates the exception as an exception (problematic I know) or wraps > all values in a tuple in the normal erlang way. `{ok, }` > or `{exit | throw | error, }`. The problem with that is that once you propagate the exception to the caller you loose the stack trace. Also throwing outside a catching construct is an error in the called side, that should't propagate as valid return to the calling side. I've come across many instances of these problem trying to use throws as exceptions. We (me and Richard Carlsson reported a possible bug to the list as OTP behaviour callbacks do the same thing, and recently we saw the same problem in dynamic pages in yaws (though that has already been fixed by Steve Vinoski). The underlying issue is that catch and try-catch have really different behaviour concerning throws. I'd like to think that catch is legacy and shouldn't be used, as that enables developers to use throw as it is defined in http://www.erlang.se/workshop/2004/exception.pdf. That is, an uncaught exception behaves as a no_catch error, with a proper stack trace. This way, throws can be used both as non-local returns and as exceptions. However, there seem to be lots of catches in tools there that hinder what I understand is "the intended use of throw nowadays." For this concrete case I think the rpc should fail, as throw(some_reason) does fail if you call it outside any catch construct. Regards -- Samuel From ericbmerritt@REDACTED Mon May 14 17:39:11 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Mon, 14 May 2012 10:39:11 -0500 Subject: [erlang-bugs] rpc:call hide throw In-Reply-To: References: <10b44fb8-5a9c-4074-a6f7-da65434696bc@knuth> Message-ID: On Mon, May 14, 2012 at 10:23 AM, Samuel wrote: > > The problem with that is that once you propagate the exception to the > caller you loose the stack trace. I am not saying its a good idea mind you, but could you not catch the exception where its propagated and reraise it in the client with erlang:raise/3. Again, let me reiterate that I am *not* proposing this as a solution, I would really need to think out the repercussions before doing that. > Also throwing outside a catching > construct is an error in the called side, that should't propagate as > valid return to the calling side. I think we are agreeing here. > I've come across many instances of these problem trying to use throws > as exceptions. We (me and Richard Carlsson reported a possible bug to > the list as OTP behaviour callbacks do the same thing, and recently we > saw the same problem in dynamic pages in yaws (though that has already > been fixed by Steve Vinoski). > > The underlying issue is that catch and try-catch have really different > behaviour concerning throws. I'd like to think that catch is legacy > and shouldn't be used, as that enables developers to use throw as it > is defined in http://www.erlang.se/workshop/2004/exception.pdf. I thought that catch was actually deprecated. After going and looking I realize that it is not. Not only that, but the docs don't seem to mention that its a bad idea. > That > is, an uncaught exception behaves as a no_catch error, with a proper > stack trace. This way, throws can be used both as non-local returns > and as exceptions. However, there seem to be lots of catches in tools > there that hinder what I understand is "the intended use of throw > nowadays." This also sounds like a problem that needs to be fixed, perhaps actual deprecation and removal of catch? > > For this concrete case I think the rpc should fail, as > throw(some_reason) does fail if you call it outside any catch > construct. That sounds reasonable to me. > Regards > -- > Samuel From tuncer.ayaz@REDACTED Tue May 15 21:50:30 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 15 May 2012 21:50:30 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression Message-ID: Tthere seems to be a spec or Dialyzer regression in otp master revealed when dialyzing rebar. Steps to reproduce: $ git clone git://github.com/basho/rebar.git && cd rebar # assuming ~/.dialzer_plt is for otp master $ make check # otherwise, use custom PLT $ make debug && dialyzer --plt otp_master_plt ebin You can ignore the extra warnings enabled via 'make check'. They make no difference. R15B01: rebar_utils.erl:154: Call to missing or unexported function escript:foldl/3 R16 (OTP_R15B01-386-g77c47cd): rebar_core.erl:440: The call rebar_core:apply_hook({_,{_,_}}) will never return since it differs in the 1st argument from the success typing arguments: ({_,{binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | non_neg_integer(),binary() | []) | {'re_pattern',_,_,_},_,_}}) rebar_ct.erl:64: Function run_test/3 has no local return rebar_ct.erl:91: Function check_log/1 will never be called rebar_ct.erl:113: Function show_log/1 will never be called rebar_deps.erl:287: Function require_source_engine/1 has no local return rebar_deps.erl:325: The pattern can never match the type <#dep{},3> rebar_deps.erl:355: Function download_source/2 will never be called rebar_deps.erl:411: Function update_source/2 will never be called rebar_deps.erl:443: Function source_engine_avail/1 has no local return rebar_deps.erl:447: Function source_engine_avail/2 has no local return rebar_deps.erl:450: The pattern 'true' can never match the type 'false' rebar_deps.erl:464: Function will never be called rebar_erlc_compiler.erl:272: Function compile_mib/3 has no local return rebar_erlydtl_compiler.erl:128: The pattern 'false' can never match the type 'true' rebar_erlydtl_compiler.erl:162: Function referenced_dtls/2 has no local return rebar_erlydtl_compiler.erl:163: The call rebar_erlydtl_compiler:referenced_dtls1([atom() | binary() | [atom() | [any()] | char()],...],Config::any(),set()) will never return since it differs in the 1st argument from the success typing arguments: ([],rebar_config:config(),set()) rebar_erlydtl_compiler.erl:167: Function referenced_dtls1/3 has no local return rebar_erlydtl_compiler.erl:175: The created fun has no local return rebar_erlydtl_compiler.erl:175: Fun application with arguments (Step::[atom() | binary() | [atom() | [any()] | char()],...]) will never return since it differs in the 1st argument from the success typing arguments: ([]) rebar_erlydtl_compiler.erl:175: The pattern [] can never match the type [atom() | binary() | [atom() | [any()] | char()],...] rebar_erlydtl_compiler.erl:186: Function will never be called rebar_erlydtl_compiler.erl:187: Function will never be called rebar_file_utils.erl:75: Function mv/2 has no local return rebar_file_utils.erl:123: Function xcopy_win32/2 has no local return rebar_neotoma_compiler.erl:88: The pattern 'false' can never match the type 'true' rebar_neotoma_compiler.erl:116: Function referenced_pegs/2 has no local return rebar_neotoma_compiler.erl:117: The call rebar_neotoma_compiler:referenced_pegs1([atom() | binary() | [atom() | [any()] | char()],...],Config::any(),set()) will never return since it differs in the 1st argument from the success typing arguments: ([],rebar_config:config(),set()) rebar_neotoma_compiler.erl:121: Function referenced_pegs1/3 has no local return rebar_neotoma_compiler.erl:129: The created fun has no local return rebar_neotoma_compiler.erl:129: Fun application with arguments (Step::[atom() | binary() | [atom() | [any()] | char()],...]) will never return since it differs in the 1st argument from the success typing arguments: ([]) rebar_neotoma_compiler.erl:129: The pattern [] can never match the type [atom() | binary() | [atom() | [any()] | char()],...] rebar_neotoma_compiler.erl:140: Function will never be called rebar_neotoma_compiler.erl:141: Function will never be called rebar_utils.erl:93: Function sh/2 has no local return rebar_utils.erl:154: Call to missing or unexported function escript:foldl/3 rebar_utils.erl:442: Function vcs_vsn_invoke/2 has no local return From kostis@REDACTED Tue May 15 22:24:34 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 15 May 2012 22:24:34 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: Message-ID: <4FB2BB82.7000303@cs.ntua.gr> On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: > There seems to be a spec or Dialyzer regression in otp master > revealed when dialyzing rebar. Since Tuncer did not submit all the info he has, let me add that the behavior reported in his mail exists in the *master* branch of OTP and *not* in the maint branch which works correctly in rebar's code base. It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's code is the same in these two branches, but it's most likely either due to some erroneous spec that was introduced/changed in the master branch or a problem in rebar's code base. IMO, Tuncer should have checked the latter before filling the report. It would be nice if he did that. Kostis From tuncer.ayaz@REDACTED Wed May 16 01:24:21 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 16 May 2012 01:24:21 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: <4FB2BB82.7000303@cs.ntua.gr> References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: > On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: >> >> There seems to be a spec or Dialyzer regression in otp master >> revealed when dialyzing rebar. > > Since Tuncer did not submit all the info he has, let me add that the > behavior reported in his mail exists in the *master* branch of OTP > and *not* in the maint branch which works correctly in rebar's code > base. Forgot to test with maint, but will do. That's why it's not mentioned. > It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's > code is the same in these two branches, but it's most likely either > due to some erroneous spec that was introduced/changed in the master > branch or a problem in rebar's code base. Upon review of the rebar code which provokes the warnings, the substantial changes to erl_bif_types seem like a good candidate for further analysis (commits bd941f50 03715097 9d870a01). Maybe the changes are not finished yet. > IMO, Tuncer should have checked the latter before filling the > report. It would be nice if he did that. That's a good idea. I will git bisect rebar. From tuncer.ayaz@REDACTED Wed May 16 16:54:55 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 16 May 2012 16:54:55 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: On Wed, 16 May 2012 01:24:21 +0200, Tuncer Ayaz wrote: > On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: > > On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: > > > > > > There seems to be a spec or Dialyzer regression in otp master > > > revealed when dialyzing rebar. > > > > Since Tuncer did not submit all the info he has, let me add that the > > behavior reported in his mail exists in the *master* branch of OTP > > and *not* in the maint branch which works correctly in rebar's code > > base. > > Forgot to test with maint, but will do. That's why it's not mentioned. Checked, maint results are the same as R15B01. > > It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's > > code is the same in these two branches, but it's most likely either > > due to some erroneous spec that was introduced/changed in the master > > branch or a problem in rebar's code base. > > Upon review of the rebar code which provokes the warnings, the > substantial changes to erl_bif_types seem like a good candidate for > further analysis (commits bd941f50 03715097 9d870a01). Maybe the > changes are not finished yet. > > > IMO, Tuncer should have checked the latter before filling the > > report. It would be nice if he did that. > > That's a good idea. I will git bisect rebar. Done, found no erroneous commit in rebar. From vjache@REDACTED Fri May 18 14:47:47 2012 From: vjache@REDACTED (Vyacheslav Vorobyov) Date: Fri, 18 May 2012 16:47:47 +0400 Subject: [erlang-bugs] httpc_manager cancel_request seems not ok Message-ID: Seems that me the only person who is using this functionality :). Anyway. I have a problem with cancel request when using a httpc to get data as a stream. My version of Erlang is R14B03, but after some digging in freshest code on github I have found the following interesting things in httpc_manager: % The thing 1. . It seems it is supposed that ets table will contain records #handler_info do_init(ProfileName, CookiesDir) -> ... HandlerDbName = handler_db_name(ProfileName), ets:new(HandlerDbName, [protected, set, named_table, {keypos, #handler_info.id}]), ... . % The thing 2. . It seems it is supposed that ets table will contain a tuples of arity 3 handle_call({cancel_request, RequestId}, From, State) -> ?hcri("cancel_request", [{request_id, RequestId}]), case ets:lookup(State#state.handler_db, RequestId) of [] -> ...; [{_, Pid, _}] -> httpc_handler:cancel(RequestId, Pid, From), {noreply, State#state{cancel = [{RequestId, Pid, From} | State#state.cancel]}} end; The arity of a tuple #handler_info is slightly not 3. -- Best Regargs, ? ?? Vyacheslav From fmgdias@REDACTED Sat May 19 20:28:46 2012 From: fmgdias@REDACTED (=?UTF-8?Q?Fabr=C3=ADcio_Dias?=) Date: Sat, 19 May 2012 15:28:46 -0300 Subject: [erlang-bugs] R15B01 Bug - Fail to Compile in Solaris 5.10 - i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if Message-ID: Hi, I'm new here on the list, and I signed up to help to compile the version R15 on Solaris. The following procedure that I performed ... PS: In the past, I compiled a version R14B04, using the same procedure *-- Config* #uname -a SunOS HOST 5.10 Generic_142910-17 i86pc i386 i86pc # gcc --version gcc (GCC) 4.6.3 # autoconf --version autoconf (GNU Autoconf) 2.69 # echo $PATH /usr/sbin:/usr/bin:/usr/ccs/bin:/opt/csw/bin: *-- Procedure* cd /dados/install-src wget http://www.erlang.org/download/otp_src_R15B01.tar.gz gunzip otp_src_R15B01.tar.gz gtar -xvf otp_src_R15B01.tar cd /dados/install-src/otp_src_R15B01 export ERL_TOP=`pwd` echo $ERL_TOP ./otp_build autoconf ./configure --prefix=/opt gmake gmake install rm /usr/bin/erl rm /usr/bin/erlc ln -s /opt/bin/erl /usr/bin ln -s /opt/bin/erlc /usr/bin *-- Result* ./otp_build autoconf: Ok ./configure --prefix=/opt: Ok But, in gmake, we have: *...bla bla bla....* gcc -g -O3 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c hipe/hipe_x86.c -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86.o gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c hipe/hipe_x86_glue.S -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_glue.o m4 -DERTS_SMP=1 -DTARGET=i386-pc-solaris2.10 -DOPSYS=sol2 -DARCH=x86 hipe/hipe_x86_bifs.m4 > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if gmake[3]: *** [obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o] Error 1 gmake[3]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[1]: *** [smp] Error 2 gmake[1]: Leaving directory `/dados/install-src/otp_src_R15B01/erts' gmake: *** [emulator] Error 2 I tried deleting the "endif" spare in line 2176 (HAVE_nbif_emulate_fpe), but got another error linking: ...bla bla bla... obj/i386-pc-solaris2.10/opt/smp/hipe_mode_switch.o obj/i386-pc-solaris2.10/opt/smp/hipe_native_bif.o obj/i386-pc-solaris2.10/opt/smp/hipe_stack.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_glue.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_signal.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_stack.o obj/i386-pc-solaris2.10/opt/smp/efile_drv.o obj/i386-pc-solaris2.10/opt/smp/inet_drv.o obj/i386-pc-solaris2.10/opt/smp/zlib_drv.o obj/i386-pc-solaris2.10/opt/smp/ram_file_drv.o obj/i386-pc-solaris2.10/opt/smp/ttsl_drv.o -lsendfile -lrt -ldlpi -ldl -lm -lsocket -lnsl -lncurses -L../lib/internal/i386-pc-solaris2.10 -lkstat /dados/install-src/otp_src_R15B01/erts/emulator/zlib/obj/i386-pc-solaris2.10/opt/libz.a /dados/install-src/otp_src_R15B01/erts/emulator/pcre/obj/i386-pc-solaris2.10/opt/libepcre.a -lethread -lerts_internal_r -lpthread -lkstat -lrt Undefined first referenced symbol in file hipe_emulate_fpe obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o ld: fatal: Symbol referencing errors. No output written to /dados/install-src/otp_src_R15B01/bin/i386-pc-solaris2.10/beam.smp gmake[3]: *** [/dados/install-src/otp_src_R15B01/bin/i386-pc-solaris2.10/beam.smp] Error 1 gmake[3]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[1]: *** [smp] Error 2 gmake[1]: Leaving directory `/dados/install-src/otp_src_R15B01/erts' gmake: *** [emulator] Error 2 Can anyone help me? -- Fabr?cio Dias fmgdias@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Sun May 20 12:54:58 2012 From: mikpe@REDACTED (Mikael Pettersson) Date: Sun, 20 May 2012 12:54:58 +0200 Subject: [erlang-bugs] R15B01 Bug - Fail to Compile in Solaris 5.10 - i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if In-Reply-To: References: Message-ID: <20408.52610.798271.20226@pilspetsen.it.uu.se> > m4 -DERTS_SMP=3D1 -DTARGET=3Di386-pc-solaris2.10 -DOPSYS=3Dsol2 -DARCH=3Dx= > 86 > hipe/hipe_x86_bifs.m4 > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S > gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 -fno-tree-copyrename > -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT > -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp > -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe > -I../include -I../include/i386-pc-solaris2.10 -I../include/internal > -I../include/internal/i386-pc-solaris2.10 -c > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S -o > obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without > #if Make sure m4 is a link to GNU m4, not /usr/ccs/bin/m4, then try again in a clean unpack of the sources (i.e., rm -rf the old source dir first, do not try a 'make clean' because that just doesn't work). If that still fails, email me a copy of the offending hipe_x86_bifs.S file and I'll have a look. From fmgdias@REDACTED Sun May 20 19:56:15 2012 From: fmgdias@REDACTED (=?UTF-8?Q?Fabr=C3=ADcio_Dias?=) Date: Sun, 20 May 2012 14:56:15 -0300 Subject: [erlang-bugs] R15B01 Bug - Fail to Compile in Solaris 5.10 - i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if In-Reply-To: <20408.52610.798271.20226@pilspetsen.it.uu.se> References: <20408.52610.798271.20226@pilspetsen.it.uu.se> Message-ID: Uowww....it works... I changed path to: export PATH=/usr/sbin:/usr/bin:/opt/csw/bin:/opt/csw/i386-pc-solaris2.9/bin # Links #ln -s /opt/csw/bin/gcc /usr/bin #ln -s /opt/csw/bin/autoconf /usr/bin #ln -s /opt/csw/gnu/m4 /usr/bin #ln -s /opt/csw/i386-pc-solaris2.9/bin/ar /usr/bin #ln -s /opt/csw/i386-pc-solaris2.9/bin/ld /usr/bin -bash-3.00# uname -a SunOS HOST 5.10 Generic_142910-17 i86pc i386 i86pc -bash-3.00# echo $PATH /usr/sbin:/usr/bin:/opt/csw/bin:/opt/csw/i386-pc-solaris2.9/bin -bash-3.00# gcc --version gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -bash-3.00# autoconf --version autoconf (GNU Autoconf) 2.69 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later , This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. -bash-3.00# m4 --version m4 (GNU M4) 1.4.16 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Rene' Seindal. -bash-3.00# ar --version GNU ar (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. -bash-3.00# ld --version GNU ld (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -bash-3.00# And... ./bin/erl --version Erlang R15B01 (erts-5.9.1) [source] [smp:16:16] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution ^C-bash-3.00# Thanks Mikael Pettersson 2012/5/20 Mikael Pettersson > > m4 -DERTS_SMP=3D1 -DTARGET=3Di386-pc-solaris2.10 -DOPSYS=3Dsol2 > -DARCH=3Dx= > > 86 > > hipe/hipe_x86_bifs.m4 > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S > > gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 -fno-tree-copyrename > > -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes > > -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT > > -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp > > -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre > -Ihipe > > -I../include -I../include/i386-pc-solaris2.10 -I../include/internal > > -I../include/internal/i386-pc-solaris2.10 -c > > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S -o > > obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o > > i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without > > #if > > Make sure m4 is a link to GNU m4, not /usr/ccs/bin/m4, then try again > in a clean unpack of the sources (i.e., rm -rf the old source dir first, > do not try a 'make clean' because that just doesn't work). > > If that still fails, email me a copy of the offending hipe_x86_bifs.S file > and I'll have a look. > -- Fabr?cio Dias fmgdias@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Sun May 20 20:03:55 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 20 May 2012 20:03:55 +0200 Subject: [erlang-bugs] R15B01 Bug - Fail to Compile in Solaris 5.10 - i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if In-Reply-To: References: <20408.52610.798271.20226@pilspetsen.it.uu.se> Message-ID: <4FB9320B.8060500@cs.ntua.gr> On 05/20/2012 07:56 PM, Fabr?cio Dias wrote: > Uowww....it works... > > I changed path to: > export PATH=/usr/sbin:/usr/bin:/opt/csw/bin:/opt/csw/i386-pc-solaris2.9/bin > > ... > > -bash-3.00# m4 --version > m4 (GNU M4) 1.4.16 > > Thanks Mikael Pettersson This is not the first time that this is reported. The question is why the configure script doesn't report some error if the m4 found in the path is not GNU m4, which is required. > 2012/5/20 Mikael Pettersson > > > Make sure m4 is a link to GNU m4, not /usr/ccs/bin/m4, Perhaps somebody who is knowledgeable about configure scripts can investigate this and provide some appropriate patch (test for GNU m4) so that Solaris users do not experience such compilation errors. Kostis From micael.karlberg@REDACTED Mon May 21 18:55:29 2012 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Mon, 21 May 2012 18:55:29 +0200 Subject: [erlang-bugs] httpc_manager cancel_request seems not ok In-Reply-To: References: Message-ID: <4FBA7381.6050407@erix.ericsson.se> Hi, You are correct. This is indeed a bug. Thanks for pointing it out. I will try to have a fix in R15B02. Regards, /BMK On 05/18/2012 02:47 PM, Vyacheslav Vorobyov wrote: > Seems that me the only person who is using this functionality :). Anyway. > I have a problem with cancel request when using a httpc to get data as > a stream. My version of Erlang is R14B03, but after some digging in > freshest code on github I have found the following interesting things > in httpc_manager: > > % The thing 1. . It seems it is supposed that ets table will contain > records #handler_info > do_init(ProfileName, CookiesDir) -> > ... > HandlerDbName = handler_db_name(ProfileName), > ets:new(HandlerDbName, > [protected, set, named_table, {keypos, #handler_info.id}]), > > ... > . > > % The thing 2. . It seems it is supposed that ets table will contain a > tuples of arity 3 > handle_call({cancel_request, RequestId}, From, State) -> > ?hcri("cancel_request", [{request_id, RequestId}]), > case ets:lookup(State#state.handler_db, RequestId) of > [] -> > ...; > [{_, Pid, _}] -> > httpc_handler:cancel(RequestId, Pid, From), > {noreply, State#state{cancel = > [{RequestId, Pid, From} | > State#state.cancel]}} > end; > > > The arity of a tuple #handler_info is slightly not 3. > From luc.tanguay@REDACTED Wed May 23 06:07:23 2012 From: luc.tanguay@REDACTED (luc.tanguay@REDACTED) Date: Wed, 23 May 2012 00:07:23 -0400 Subject: [erlang-bugs] bug in filelib:ensure_dir on Windows. Message-ID: <462990D3EDDFE5458F928506D32D40C95CD297A783@MBX05.bell.corp.bce.ca> Hi. I run R14B02 on Windows 2K8 64-bit server (but Erlang is 32-bit). But looking at the latest code from GitHub, the problem is still there. When I try filelib:ensure_dir("Y:/toto.txt") and the drive "Y:" does not exist, the VM crashes after a few minutes with eheap_alloc cannot allocate 1425410620 bytes of memory (of type "heap"). Looking at the Erlang source code for ensure_dir/1, and if I'm reading it right, the endless loop is caused because the dirname in "Y:/toto.txt" is "Y:/" but "Y:/" is not considered a directory by do_is_dir/2. So a recursive call to ensure_dir/1 is done, and..... Is it really a bug? Luc --- Le cri du nourrisson est le r?sultat de plusieurs ann?es de recherche dans le domaine du signal d'alarme. (Serge Bouchard) --- Luc Tanguay, ing./P.Eng. Bell Canada 671 De La Gaucheti?re 4e ?tage, Montr?al H3B 2M8 514-786-6440 cell: 514-229-7585 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed May 23 10:11:43 2012 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 23 May 2012 10:11:43 +0200 Subject: [erlang-bugs] bug in filelib:ensure_dir on Windows. In-Reply-To: <462990D3EDDFE5458F928506D32D40C95CD297A783@MBX05.bell.corp.bce.ca> References: <462990D3EDDFE5458F928506D32D40C95CD297A783@MBX05.bell.corp.bce.ca> Message-ID: <4FBC9BBF.6000705@erlang.org> Hi! Thanks for reporting this! The following patch[1] should solve the problem. I'll let it run through our tests and then merge it to maint. Thanks, Lukas [1] diff --git a/lib/stdlib/src/filelib.erl b/lib/stdlib/src/filelib.erl index d532cea..b098d4c 100644 --- a/lib/stdlib/src/filelib.erl +++ b/lib/stdlib/src/filelib.erl @@ -264,6 +264,9 @@ ensure_dir(F) -> case do_is_dir(Dir, file) of true -> ok; + false when Dir =:= F -> + %% Protect against infinite loop + {error,einval}; false -> ensure_dir(Dir), case file:make_dir(Dir) of On 23/05/12 06:07, luc.tanguay@REDACTED wrote: > > Hi. > > I run R14B02 on Windows 2K8 64-bit server (but Erlang is 32-bit). But > looking at the latest code from GitHub, the problem is still there. > > When I try filelib:ensure_dir("Y:/toto.txt") and the drive "Y:" does > not exist, the VM crashes after a few minutes with eheap_alloc cannot > allocate 1425410620 bytes of memory (of type "heap"). > > Looking at the Erlang source code for ensure_dir/1, and if I'm reading > it right, the endless loop is caused because the dirname in > "Y:/toto.txt" is "Y:/" but "Y:/" is not considered a directory by > do_is_dir/2. So a recursive call to ensure_dir/1 is done, and..... > > Is it really a bug? > > Luc > > --- > > //Le cri du nourrisson est le r?sultat de plusieurs ann?es de > recherche dans le domaine du signal d'alarme.// > > //(Serge Bouchard)// > > --- > > Luc Tanguay, ing./P.Eng. > Bell Canada > 671 De La Gaucheti?re 4e ?tage, > > Montr?al H3B 2M8 > 514-786-6440 > > cell: 514-229-7585 > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Wed May 23 17:49:11 2012 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 23 May 2012 17:49:11 +0200 Subject: [erlang-bugs] 64bit windows installer In-Reply-To: <4F8ECCC4.1030008@rabbitmq.com> References: <4F8ECCC4.1030008@rabbitmq.com> Message-ID: <20120523154911.GA26062@erix.ericsson.se> On Wed, Apr 18, 2012 at 03:16:36PM +0100, Emile Joubert wrote: > Hi, > > While attempting to perform an unattended installation of the 64bit > R15B01 Windows version of Erlang we discovered a possible flaw with the > VC++ redistributable version checking. > > If you pre-install vcredist_x64.exe and run the Erlang installer with > the "/S" flag for silent install, then a dialogue pops up to ask whether > you wish to repair or remove the x64 redistributable. > > If you pre-install both vcredist_x86.exe and vcredist_x64.exe and run > the Erlang installer with the "/S" flag then the installation completes > silently. > > This seems unexpected and might be considered a bug. I am now digging into this. Can you search for msvcr100.dll under C:\WINDOWS on your malfunctioning installation (pre-installed vcredist_x64.exe) to see where it is installed? Your help is much appreciated. > > > > -- > Emile Joubert > > RabbitMQ > SpringSource, a division of VMware > VMware > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Fri May 25 11:40:44 2012 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 25 May 2012 11:40:44 +0200 Subject: [erlang-bugs] 64bit windows installer In-Reply-To: <20120523154911.GA26062@erix.ericsson.se> References: <4F8ECCC4.1030008@rabbitmq.com> <20120523154911.GA26062@erix.ericsson.se> Message-ID: <20120525094044.GA15412@erix.ericsson.se> On Wed, May 23, 2012 at 05:49:11PM +0200, Raimo Niskanen wrote: > On Wed, Apr 18, 2012 at 03:16:36PM +0100, Emile Joubert wrote: > > Hi, > > > > While attempting to perform an unattended installation of the 64bit > > R15B01 Windows version of Erlang we discovered a possible flaw with the > > VC++ redistributable version checking. > > > > If you pre-install vcredist_x64.exe and run the Erlang installer with > > the "/S" flag for silent install, then a dialogue pops up to ask whether > > you wish to repair or remove the x64 redistributable. > > > > If you pre-install both vcredist_x86.exe and vcredist_x64.exe and run > > the Erlang installer with the "/S" flag then the installation completes > > silently. > > > > This seems unexpected and might be considered a bug. > > I am now digging into this. > > Can you search for msvcr100.dll under C:\WINDOWS on your malfunctioning > installation (pre-installed vcredist_x64.exe) to see where it is installed? > > Your help is much appreciated. I think we have found the root cause and can reproduce the corresponding problem if you have just the 32-bit VC++ redistributable installed the Erlang installer will think it does not need to intall the 64-bit VC++ redistributable and install an Erlang that will not start. The root cause we have found is that the installer runs in 32-bit mode and hence Windows does not show it the same system directory as an 64-bit application will see. Luckily there is a mapped fake directory where the installer can see the hidden 64-bit system directory. A fix for this will most likely make it into R15B02. > > > > > > > > > -- > > Emile Joubert > > > > RabbitMQ > > SpringSource, a division of VMware > > VMware > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB