From prouleau001@REDACTED Sun Apr 1 17:59:47 2012 From: prouleau001@REDACTED (Pierre Rouleau) Date: Sun, 1 Apr 2012 11:59:47 -0400 Subject: [erlang-bugs] Is there a public bug-tracker for Erlang? Message-ID: Hi all, aside from this (erlang-bugs) mailing list, is there a publicly accessible bug-tracker system where we can take a look at the status of the various bugs, read the discussions related to the bug and provide feedback? Something like the Rondup bug tracker for Python (http://bugs.python.org/) ? I looked around a little and all I could find were references to this mailing list and old articles stating that there is no public Erlang bug tracker. Is this still the case? Thanks /Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.winston.101@REDACTED Tue Apr 3 05:04:00 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Mon, 2 Apr 2012 23:04:00 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) Message-ID: I have run into the following issue with R15B cross compiled to an AVR32 (similar to ARM) system (no HiPE). (mynode@REDACTED)6> mnesia:stop(). TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def: 0x8e422b5c Aborted Interestingly, if I bring up a standalone erl, I don't get the assert, it segfaults instead: # erts-5.9/bin/erl Eshell V5.9 ?(abort with ^G) 1> mnesia:create_schema([node()]). ok 2> mnesia:start(). ok 3> mnesia:stop(). Segmentation fault I wasn't able to get much from the core file (I'm using a cross compiled version of gdb), I supposed I'd need to build a debug version of OTP: Program terminated with signal 11, Segmentation fault. #0 ?0x00000000 in ?? () (gdb) bt #0 ?0x00000000 in ?? () #1 ?0xff7f0000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Any thoughts on tracking this down? It's possible it's a low memory problem, I am already restricting the footprint to just stdlib, kernel, inets and mnesia (and my app which is small). - is there any way to enable any kind of allocation tracing so I can pinpoint this? - Does mnesia have a low-memory footprint mode that I can try to see if that ameliorates the problem? Thanks! W. From gustav.simonsson@REDACTED Tue Apr 3 10:25:05 2012 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Tue, 03 Apr 2012 09:25:05 +0100 (BST) Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: Message-ID: Hi Winston, A few ideas which might be of some use: Try starting your node with the mnesia "debug" or "trace" level debugging (http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76624). That might show at which part of the shutdown the crash occurs. When you create a table, you can give the compressed option in the storage_properties tuple, though I don't know of any low-memory options for mnesia itself. If you want to look at what the Erlang allocators have allocated you can use erlang:system_info({allocator, ets_alloc}). and then look at the blocks_size tuple which is on the format {blocks_size, CurrentSize, MaxSizeSinceLastAllocation, MaxSizeSinceEmulatorStarted}. The values are in bytes. // Gustav Simonsson Sent from my PC ----- Original Message ----- > From: "Winston Smith" > To: "erlang-bugs" > Sent: Tuesday, 3 April, 2012 5:04:00 AM > Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) > > I have run into the following issue with R15B cross compiled to an > AVR32 (similar to ARM) system (no HiPE). > > > (mynode@REDACTED)6> mnesia:stop(). > TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def: > 0x8e422b5c > Aborted > > > Interestingly, if I bring up a standalone erl, I don't get the > assert, > it segfaults instead: > > > # erts-5.9/bin/erl > Eshell V5.9 ?(abort with ^G) > 1> mnesia:create_schema([node()]). > ok > 2> mnesia:start(). > ok > 3> mnesia:stop(). > Segmentation fault > > > > I wasn't able to get much from the core file (I'm using a cross > compiled version of gdb), I supposed I'd need to build a debug > version > of OTP: > > > Program terminated with signal 11, Segmentation fault. > #0 ?0x00000000 in ?? () > (gdb) bt > #0 ?0x00000000 in ?? () > #1 ?0xff7f0000 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > > Any thoughts on tracking this down? > > It's possible it's a low memory problem, I am already restricting the > footprint to just stdlib, kernel, inets and mnesia (and my app which > is small). > - is there any way to enable any kind of allocation tracing so I > can pinpoint this? > - Does mnesia have a low-memory footprint mode that I can try to > see if that ameliorates the problem? > > Thanks! > > > W. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From aronisstav@REDACTED Tue Apr 3 11:35:15 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 3 Apr 2012 11:35:15 +0200 Subject: [erlang-bugs] Dialyzer bug related to contract checking In-Reply-To: <0F738B23-F9C4-4546-AC2D-4A4602B1F0E8@entelios.com> References: <0F738B23-F9C4-4546-AC2D-4A4602B1F0E8@entelios.com> Message-ID: Hi! I have confirmed this bug and I will submit a patch for it soon. Thanks for the report! Stavros On Sat, Mar 31, 2012 at 5:51 PM, Sebastian Egner < sebastian.egner@REDACTED> wrote: > Hello, > > The two modules a and b below seem to crash the Dialyzer in OTP R15B: > > ./dialyzer --src a.erl b.erl > > --> Error in process <0.29.0> with exit value: > {{badmatch,{c,list,[any,any],nonempty}},[{erl_types,t_abstract_records,2,[{file,"erl_types.erl"},{line,3194}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-',2,[{file,"erl_types.erl"},{line,3204}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-'... > > (Checking a.erl and b.erl individually is inconspicious.) > > For a possible workaround, see below. > > Sebastian > > > *Details* > > Here is the reduced example: > > % --------------- > > -module(a). > -export([g/1]). > > -export_type([a/0, t/0]). > -type a() :: integer(). > -type t() :: a() | maybe_improper_list(t(), t()). > > -spec g(t()) -> t(). > g(X) -> X. > > % --- > > -module(b). > -export([f/1]). > > -spec f(a:t()) -> a:t(). > f(X) -> a:g(X). > > % --------------- > > > *Workaround* > > My understanding of the inner workings of Dialyzer is too limited to fix > it at the quality needed to submit a patch directly through Github. > > However, the following patch of t_abstract_records/2 in > "otp_src_R15B/lib/hipe/cerl/erl_types.erl" corrects what is probably an > "accidental match" against NewContents: > > 3194,3195c3194,3195 > < ?list(NewContents, NewTermination, _) = t_cons(NewContents, > Other), > < ?list(NewContents, NewTermination, Size) > --- > > ?list(NewContents2, NewTermination, _) = t_cons(NewContents, > Other), > > ?list(NewContents2, NewTermination, Size) > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.winston.101@REDACTED Tue Apr 3 16:19:41 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Tue, 3 Apr 2012 10:19:41 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: References: Message-ID: On Tue, Apr 3, 2012 at 4:25 AM, Gustav Simonsson wrote: > A few ideas which might be of some use: > > Try starting your node with the mnesia "debug" or "trace" level debugging > (http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76624). That might show > at which part of the shutdown the crash occurs. I did try this earlier today, I can see mnesia startup, but as soon as I issue mnesia:stop(), it crashes before *any* further trace output: # erts-5.9/bin/erl -mnesia debug trace Eshell V5.9 (abort with ^G) 1> mnesia:start(). Mnesia(nonode@REDACTED): mnesia_monitor starting: <0.39.0> Mnesia(nonode@REDACTED): Version: "4.6" Mnesia(nonode@REDACTED): Env access_module: mnesia Mnesia(nonode@REDACTED): Env auto_repair: true Mnesia(nonode@REDACTED): Env backup_module: mnesia_backup Mnesia(nonode@REDACTED): Env debug: trace Mnesia(nonode@REDACTED): Env dir: "/home/avr32/mynode/Mnesia.nonode@REDACTED" Mnesia(nonode@REDACTED): Env dump_log_load_regulation: false Mnesia(nonode@REDACTED): Env dump_log_time_threshold: 180000 Mnesia(nonode@REDACTED): Env dump_log_update_in_place: true Mnesia(nonode@REDACTED): Env dump_log_write_threshold: 1000 Mnesia(nonode@REDACTED): Env embedded_mnemosyne: false Mnesia(nonode@REDACTED): Env event_module: mnesia_event Mnesia(nonode@REDACTED): Env extra_db_nodes: [] Mnesia(nonode@REDACTED): Env ignore_fallback_at_startup: false Mnesia(nonode@REDACTED): Env fallback_error_function: {mnesia,lkill} Mnesia(nonode@REDACTED): Env max_wait_for_decision: infinity Mnesia(nonode@REDACTED): Env schema_location: opt_disc Mnesia(nonode@REDACTED): Env core_dir: false Mnesia(nonode@REDACTED): Env pid_sort_order: false Mnesia(nonode@REDACTED): Env no_table_loaders: 2 Mnesia(nonode@REDACTED): Env dc_dump_limit: 4 Mnesia(nonode@REDACTED): Env send_compressed: 0 Mnesia(nonode@REDACTED): Mnesia debug level set to trace Mnesia(nonode@REDACTED): mnesia_subscr starting: <0.40.0> Mnesia(nonode@REDACTED): mnesia_locker starting: <0.41.0> Mnesia(nonode@REDACTED): mnesia_recover starting: <0.42.0> Mnesia(nonode@REDACTED): mnesia_tm starting: <0.43.0> Mnesia(nonode@REDACTED): Schema initiated from: default Mnesia(nonode@REDACTED): mnesia_controller starting: <0.47.0> Mnesia(nonode@REDACTED): mnesia_late_loader starting: <0.48.0> Mnesia(nonode@REDACTED): Intend to load tables: [] Mnesia(nonode@REDACTED): Mnesia started, 2 seconds ok 2> mnesia:stop(). Segmentation fault I also ran strace(1) against the beam process while doing the mnesia:stop(), interestingly, I see a reference to /etc/TZ and a call to gettimeofday() (perhaps to prepare a timestamp for a log?) just before it faults: ... epoll_wait(3, {{EPOLLIN, {u32=0, u64=256}}}, 256, 0) = 1 clock_gettime(CLOCK_MONOTONIC, {6650, 485055333}) = 0 read(0, "mnesia:stop().\n"..., 65536) = 15 clock_gettime(CLOCK_MONOTONIC, {6650, 499541961}) = 0 clock_gettime(CLOCK_MONOTONIC, {6650, 502889961}) = 0 clock_gettime(CLOCK_MONOTONIC, {6650, 506291561}) = 0 time(NULL) = 1333462397 open("/etc/TZ", O_RDONLY) = 6 read(6, "EST5EDT\n"..., 68) = 8 close(6) = 0 time(NULL) = 1333462397 open("/etc/TZ", O_RDONLY) = 6 read(6, "EST5EDT\n"..., 68) = 8 close(6) = 0 epoll_wait(3, {}, 256, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {6650, 526816132}) = 0 gettimeofday({1333462397, 301868}, NULL) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 621 detached NOTE: I'm starting erl here with +K true and +A 5, although omitting them makes no difference. > When you create a table, you can give the compressed option in the storage_properties > tuple, though I don't know of any low-memory options for mnesia itself. > > If you want to look at what the Erlang allocators have allocated you can use > erlang:system_info({allocator, ets_alloc}). and then look at the blocks_size tuple > which is on the format {blocks_size, CurrentSize, MaxSizeSinceLastAllocation, MaxSizeSinceEmulatorStarted}. > The values are in bytes. The system I'm using only has 32MB of RAM and I had thought that this was perhaps a problem with OTP running out of memory. However it seems that my Erlang node fits quite nicely into about 6MB, so I don't actually seem to be running out of system memory (I'm monitoring via the free(1) command). I also added 16MB of swap just to ensure that this wasn't an out-of-memory condition. To summarize, I'm seeing two slightly different behaviors: 1) When I am running my node, upon shutdown I get the TYPE_ASSERTION_FAILED 2) When running just erl and doing an mnesia:start() immediately followed by mnesia:stop(), I get a segfault I'm not sure why there are differences between #1 and #2, I haven't been able to pin that down yet. In the case of #2, I see the following in the system log: beam[539]: segfault at 00c0001c pc 00047aba sp 7fa36424 ecr 24 If I bring back the core file to my build box and fire up the cross compiled gdb, the stack is trashed, but if I look at address 00047aba (pc), I seem to be in the middle of a symbol called cmp: 0x00047ab8 : mov r5,lr 0x00047aba : ld.w r3,lr[0x0] <<<-------- SEGV here 0x00047abc : bfextu r10,r3,0x2,0x4 So it looks like it could be a bad pointer. However, I can't find a symbol called cmp anywhere in beam, or the libraries it is linked with: # ldd erts-5.9/bin/beam libutil.so.0 => /lib/libutil.so.0 (0x2aab2000) libdl.so.0 => /lib/libdl.so.0 (0x2aab4000) libm.so.0 => /lib/libm.so.0 (0x2aab7000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x2aac5000) librt.so.0 => /lib/librt.so.0 (0x2aae5000) libc.so.0 => /lib/libc.so.0 (0x2aae7000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaab000) So I'm not 100% sure where gdb is getting this "cmp" symbol from. Next step is to try to build a debug version of OTP, so hopefully I can get some more useful information from gdb. Thanks! W. From eric.pailleau@REDACTED Tue Apr 3 22:14:45 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 03 Apr 2012 22:14:45 +0200 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: References: Message-ID: <4F7B5A35.5080905@wanadoo.fr> Le 03/04/2012 16:19, Winston Smith a ?crit : > read(6, "EST5EDT\n"..., 68) = 8 Hi, by reading your strace, the /etc/TZ contents looks invalid for me. should not be EST+5EDT or EST-5EDT ??? http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html I can see a patch for uClibc handling correctly invalid formatted TZ and fix a segfault, but I don't know if your lib is uptodate or not... Hope it can help... Regards. From smith.winston.101@REDACTED Wed Apr 4 03:39:16 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Tue, 3 Apr 2012 21:39:16 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: <4F7B5A35.5080905@wanadoo.fr> References: <4F7B5A35.5080905@wanadoo.fr> Message-ID: On Tue, Apr 3, 2012 at 4:14 PM, PAILLEAU Eric wrote: > Le 03/04/2012 16:19, Winston Smith a ?crit : >> read(6, "EST5EDT\n"..., 68) ? ? ? ? ? ? = 8 > > by reading your strace, the /etc/TZ contents looks invalid for me. > > should not be EST+5EDT or EST-5EDT ??? > > http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html > > I can see a patch for uClibc handling correctly invalid formatted TZ and > fix a segfault, but I don't know if your lib is uptodate or not... I did try changing /etc/TZ to EST+5EDT, but it didn't help! It was worth a try though. I appreciate your help anyway! W. From smith.winston.101@REDACTED Wed Apr 4 03:59:50 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Tue, 3 Apr 2012 21:59:50 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: References: Message-ID: On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith wrote: > I have run into the following issue with R15B cross compiled to an > AVR32 (similar to ARM) system (no HiPE). > > > (mynode@REDACTED)6> mnesia:stop(). > TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def: 0x8e422b5c > Aborted > Since R15B was out today, I built it for AVR32 in debug mode and ran it again under the debugger, this time the behavior is a bit different. I'm guessing it's because it's a debug build, it's catching the problem a bit earlier: # ./erts-5.9.1/bin/erl Eshell V5.9.1 (abort with ^G) 1> mnesia:start(). ok 2> mnesia:stop(). TYPE ASSERTION FAILED, file beam/utils.c, line 2380: !is_header(x) Aborted (core dumped) Running under a remote gdb session, I set a breakpoint at beam/utils.c:2380 and when it stopped, I did a bit of poking around and stepped through to the abort: Breakpoint 1, cmp (a=1650811245, b=795177580) at beam/utils.c:2380 2380 if (is_not_list(b)) { (gdb) bt #0 cmp (a=1650811245, b=795177580) at beam/utils.c:2380 #1 0x00000000 in ?? () Backtrace stopped: frame did not save the PC (gdb) print b $1 = 795177580 (gdb) print b & 3 $2 = 0 (gdb) n checked_is_not_list (x=795177580, file=0x78cb8 "beam/utils.c", line=2380) at beam/erl_term.c:130 130 ET_DEFINE_CHECKED(int,is_not_list,Eterm,!is_header); (gdb) n et_abort (expr=0x2f65726c
, file=0x78cb8 "beam/utils.c", line=2380) at beam/erl_term.c:31 31 { I still have no backtrace, but indeed line 2380 of utils.c is in the middle of the function "cmp" that I found previously. I did rebuilding the debug build with -fno-omit-frame-pointer, but it hasn't improved the stack trace. >From looking at the sources for ET_DEFINE_CHECKED(), it's expecting that 'b' is not a list, but there is a precondition that 'b' is NOT a header, which it seems to be (b & TAG_PRIMARY_MASK) == TAG_PRIMARY_HEADER, b & 3 == 0. Does anyone know how to extract the erlang process backtrace/heap so I can figure out where this is originating? Thanks! W. From dave@REDACTED Wed Apr 4 16:44:03 2012 From: dave@REDACTED (Dave Cottlehuber) Date: Wed, 4 Apr 2012 16:44:03 +0200 Subject: [erlang-bugs] bus error & segfaults on OS X Lion 10.7.3 after repeated crypto:md5_init Message-ID: Hi, Using homebrewed Erlang/OTP R15B & R15B01 on Mac OS X Lion 10.7.3 (11D50b) only, I'm seeing bus errors or segfaults after crypto:md5_init() after running this continually https://gist.github.com/2219748 Eshell V5.9.1 (abort with ^G) 1> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] [... many times .... ] Eshell V5.9.1 (abort with ^G) 1> [1] 94307 segmentation fault erl -run erlbork In some cases it takes a couple of hours to trigger the failure. lldb stacktrace for R15B01 http://friendpaste.com/sQklBG4PuaVl4lwwkGu49 lldb stacktrace for R15B http://friendpaste.com/4wmvBSjatl3cemkRgSZlkp The original error is apparent during running CouchDB make check. Thanks to fdmanana, benoitc, davisp for helping with this on #couchdb as always. Let me know if I can help further. A+ Dave From smith.winston.101@REDACTED Wed Apr 4 18:43:35 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Wed, 4 Apr 2012 12:43:35 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: References: Message-ID: On Tue, Apr 3, 2012 at 9:59 PM, Winston Smith wrote: > On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith > wrote: >> I have run into the following issue with R15B cross compiled to an >> AVR32 (similar to ARM) system (no HiPE). >> [snip] > 2> mnesia:stop(). > TYPE ASSERTION FAILED, file beam/utils.c, line 2380: !is_header(x) > Aborted (core dumped) [snip] > I still have no backtrace, but indeed line 2380 of utils.c is in the > middle of the function "cmp" that I found previously. ?I did > rebuilding the debug build with -fno-omit-frame-pointer, but it hasn't > improved the stack trace. Don't know what's up with bt/where not working in gdb, but with -fno-omit-frame-pointer (and a bit of research into the AVR32 ABI), I can trace the stack via the fp register R7; it points to the return address followed by the previous value of R7 (like EBP on x86). So I have been able to recreate the "C" stack manually: 0 - cmp(a,b) -- utils.c:2380 1 - seqeq_2(l) -- erl_bif_op.c:115 2 - db_prog_match() -- erl_db_util.c:1997 3 - db_match_dbterm() -- erl_db_util.c:5051 4 - db_select_chunk_hash() -- erl_db_hash.c:1485 5 - db_select_hash() -- erl_db_hash.c:1404 6 - ets_select2() -- erl_db.c:2376 7 - ets_select2() -- erl_db.c:2350 8 - process_main() -- beam_emu.c:2642 9 - ?? (0x02) Unfortunately, I have not yet figured out how to get to local variables from the AVR32 ABI, I'd really like to see what's going on at frame #2. It's trying to process a matchCall2 where it puts the arguments to seqeq_2 into the stack by accessing esp[-1] and esp[-2]. I have tried to recompile with -DHARDDEBUG to turn on more tracing as described at the bottom of this page: http://carpanta.dc.fi.udc.es/docs/erlang/dbg.html Although it looks like the code -DHARDDEBUG enables doesn't compile in R15B01. I will see if I can fix that ... Thanks W. From fdmanana@REDACTED Thu Apr 5 15:00:23 2012 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 5 Apr 2012 14:00:23 +0100 Subject: [erlang-bugs] bus error & segfaults on OS X Lion 10.7.3 after repeated crypto:md5_init In-Reply-To: References: Message-ID: It affects the R14 series as well. There's a gdb thread backtrace dump at: https://gist.github.com/1199903 which shows a memory access error originating from the crypto NIF (thread 13) On Wed, Apr 4, 2012 at 3:44 PM, Dave Cottlehuber wrote: > Hi, > > Using homebrewed Erlang/OTP R15B & R15B01 on Mac OS X Lion 10.7.3 > (11D50b) only, I'm seeing bus errors or segfaults after > crypto:md5_init() after running this continually > https://gist.github.com/2219748 > > Eshell V5.9.1 ?(abort with ^G) > 1> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] > [async-threads:0] [hipe] [kernel-poll:false] > > [... many times .... ] > > Eshell V5.9.1 ?(abort with ^G) > 1> [1] ? ?94307 segmentation fault ?erl -run erlbork > > In some cases it takes a couple of hours to trigger the failure. > > lldb stacktrace for R15B01 http://friendpaste.com/sQklBG4PuaVl4lwwkGu49 > lldb stacktrace for R15B ? ? http://friendpaste.com/4wmvBSjatl3cemkRgSZlkp > > The original error is apparent during running CouchDB make check. > Thanks to fdmanana, benoitc, davisp for helping with this on #couchdb as always. > > Let me know if I can help further. > > A+ > Dave > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Filipe David Manana, "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From sverker@REDACTED Tue Apr 10 15:38:58 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 10 Apr 2012 15:38:58 +0200 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: References: Message-ID: <4F8437F2.8010905@erix.ericsson.se> Winston Smith wrote: > On Tue, Apr 3, 2012 at 9:59 PM, Winston Smith > wrote: > >> On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith >> wrote: >> >>> I have run into the following issue with R15B cross compiled to an >>> AVR32 (similar to ARM) system (no HiPE). >>> >>> > [snip] > >> 2> mnesia:stop(). >> TYPE ASSERTION FAILED, file beam/utils.c, line 2380: !is_header(x) >> Aborted (core dumped) >> > [snip] > >> I still have no backtrace, but indeed line 2380 of utils.c is in the >> middle of the function "cmp" that I found previously. I did >> rebuilding the debug build with -fno-omit-frame-pointer, but it hasn't >> improved the stack trace. >> > > Don't know what's up with bt/where not working in gdb, but with > -fno-omit-frame-pointer (and a bit of research into the AVR32 ABI), I > can trace the stack via the fp register R7; it points to the return > address followed by the previous value of R7 (like EBP on x86). > > So I have been able to recreate the "C" stack manually: > > 0 - cmp(a,b) -- utils.c:2380 > 1 - seqeq_2(l) -- erl_bif_op.c:115 > 2 - db_prog_match() -- erl_db_util.c:1997 > 3 - db_match_dbterm() -- erl_db_util.c:5051 > 4 - db_select_chunk_hash() -- erl_db_hash.c:1485 > 5 - db_select_hash() -- erl_db_hash.c:1404 > 6 - ets_select2() -- erl_db.c:2376 > 7 - ets_select2() -- erl_db.c:2350 > 8 - process_main() -- beam_emu.c:2642 > 9 - ?? (0x02) > > Unfortunately, I have not yet figured out how to get to local > variables from the AVR32 ABI, I'd really like to see what's going on > at frame #2. It's trying to process a matchCall2 where it puts the > arguments to seqeq_2 into the stack by accessing esp[-1] and esp[-2]. > > I have tried to recompile with -DHARDDEBUG to turn on more tracing as > described at the bottom of this page: > > http://carpanta.dc.fi.udc.es/docs/erlang/dbg.html > > Although it looks like the code -DHARDDEBUG enables doesn't compile in > R15B01. I will see if I can fix that ... > > This is an ETS-bug according to your call trace. ets:select/2 is called and the matchspec seems to contain '==' as the BIF seqeq_2 is called. db_prog_match() is the stack based VM that executes matchspec's. For some reason an invalid term (a "header" with two lowest bits as zero) is read from the stack. I don't have any ARM machine to test on at the moment. Some debugging ideas: 1. Add "#define HARDDEBUG" only to erl_db*.c (the ETS-code). 2. Add "#define DMC_DEBUG" in erl_db_util.c. 3. Add your own erts_printf's. Use %T to print erlang terms (Eterm's). 4. Add a check in db_prog_match to assert that the esp-stack is ok before/after each instruction in the big for-loop. Something like Eterm* esp_start = esp; for (;;) { ASSERT(esp >= esp_start); for (tp = esp_start; tp < esp; tp++) { ASSERT(!is_header(*tp)); } switch (*pc++) { /Sverker, Erlang/OTP Ericsson From smith.winston.101@REDACTED Tue Apr 10 19:24:51 2012 From: smith.winston.101@REDACTED (Winston Smith) Date: Tue, 10 Apr 2012 13:24:51 -0400 Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia) In-Reply-To: <4F8437F2.8010905@erix.ericsson.se> References: <4F8437F2.8010905@erix.ericsson.se> Message-ID: On Tue, Apr 10, 2012 at 9:38 AM, Sverker Eriksson wrote: > This is an ETS-bug according to your call trace. ets:select/2 is called and > the matchspec seems to contain '==' as the BIF seqeq_2 is called. > db_prog_match() is the stack based VM that executes matchspec's. For some > reason an invalid term (a "header" with two lowest bits as zero) is read > from the stack. > > I don't have any ARM machine to test on at the moment. It's actually AVR32 from Atmel, not ARM. > Some debugging ideas: > > 1. Add "#define HARDDEBUG" only to erl_db*.c (the ETS-code). I have actually enabled HARDDEBUG for everything, and had to create some patches as it didn't compile (see other messages I sent to erlang-questions regarding the status of HARDDEBUG). I wil try injecting the HARDDEBUG into the ets only files. > 2. Add "#define DMC_DEBUG" in erl_db_util.c. > 3. Add your own erts_printf's. Use %T to print erlang terms (Eterm's). > 4. Add a check in db_prog_match to assert that the esp-stack is ok > before/after each instruction in the big for-loop. > > Something like > > Eterm* esp_start = esp; > > for (;;) { > > ? ASSERT(esp >= esp_start); > ? for (tp = esp_start; tp < esp; tp++) { > ? ? ? ASSERT(!is_header(*tp)); > ? } > > ? switch (*pc++) { I'll try this! Thanks for the advice! W. From ulf@REDACTED Wed Apr 11 23:25:42 2012 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 11 Apr 2012 23:25:42 +0200 Subject: [erlang-bugs] net_kernel:start/1 going its own way Message-ID: <74489846-319B-4F02-9977-A98BC974B7C2@feuerlabs.com> I just noticed this confusing behavior: uwair: uwiger$ erl -name n1 Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) (n1@REDACTED)1> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution a uwair: uwiger$ erl 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> net_kernel:start([n1, longnames]). {ok,<0.33.0>} (n1@REDACTED)2> When starting erlang the normal way, I get the node name 'n1@REDACTED', but when I start the net_kernel manually, I get 'n1@REDACTED'. I have yet to delve into the code to figure out where the two approaches part ways, but an obvious problem is that rebar's node tool uses the second approach, which on my machine causes nodetool to fail when trying to ping the newly started node. Most likely, something is not quite right in my environment, but why should this matter in the first place? BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ulf@REDACTED Wed Apr 11 23:53:03 2012 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 11 Apr 2012 23:53:03 +0200 Subject: [erlang-bugs] net_kernel:start/1 going its own way In-Reply-To: <74489846-319B-4F02-9977-A98BC974B7C2@feuerlabs.com> References: <74489846-319B-4F02-9977-A98BC974B7C2@feuerlabs.com> Message-ID: <02DB1970-D0FC-4ACC-85A5-1A133406355F@feuerlabs.com> On 11 Apr 2012, at 23:25, Ulf Wiger wrote: > I just noticed this confusing behavior: > > uwair: uwiger$ erl -name n1 > Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > (n1@REDACTED)1> > BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded > (v)ersion (k)ill (D)b-tables (d)istribution > a > uwair: uwiger$ erl > 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> net_kernel:start([n1, longnames]). > {ok,<0.33.0>} > (n1@REDACTED)2> > > When starting erlang the normal way, I get the node name 'n1@REDACTED', but when I start > the net_kernel manually, I get 'n1@REDACTED'. Having experimented a bit, I found the following workaround: Eshell V5.9 (abort with ^G) 1> inet_config:do_load_resolv(os:type(),longnames). ok 2> net_kernel:start([n1,longnames]). {ok,<0.34.0>} (n1@REDACTED)3> Comments? BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From tuncer.ayaz@REDACTED Thu Apr 12 11:03:52 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 12 Apr 2012 11:03:52 +0200 Subject: [erlang-bugs] net_kernel:start/1 going its own way In-Reply-To: <02DB1970-D0FC-4ACC-85A5-1A133406355F@feuerlabs.com> References: <74489846-319B-4F02-9977-A98BC974B7C2@feuerlabs.com> <02DB1970-D0FC-4ACC-85A5-1A133406355F@feuerlabs.com> Message-ID: On Wed, Apr 11, 2012 at 11:53 PM, Ulf Wiger wrote: > > On 11 Apr 2012, at 23:25, Ulf Wiger wrote: > >> I just noticed this confusing behavior: >> >> uwair: uwiger$ erl -name n1 >> Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Eshell V5.9 (abort with ^G) >> (n1@REDACTED)1> >> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded >> (v)ersion (k)ill (D)b-tables (d)istribution >> a >> uwair: uwiger$ erl >> 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> net_kernel:start([n1, longnames]). >> {ok,<0.33.0>} >> (n1@REDACTED)2> >> >> When starting erlang the normal way, I get the node name >> 'n1@REDACTED', but when I start the net_kernel manually, I get >> 'n1@REDACTED'. > > Having experimented a bit, I found the following workaround: > > Eshell V5.9 (abort with ^G) > 1> inet_config:do_load_resolv(os:type(),longnames). > ok > 2> net_kernel:start([n1,longnames]). > {ok,<0.34.0>} > (n1@REDACTED)3> > > Comments? Try this $ sudo scutil --set HostName `hostname -s`.local From ulf@REDACTED Thu Apr 12 11:29:08 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 12 Apr 2012 11:29:08 +0200 Subject: [erlang-bugs] net_kernel:start/1 going its own way In-Reply-To: References: <74489846-319B-4F02-9977-A98BC974B7C2@feuerlabs.com> <02DB1970-D0FC-4ACC-85A5-1A133406355F@feuerlabs.com> Message-ID: <819F7008-0FFF-496D-9B70-9A8933AD9720@feuerlabs.com> On 12 Apr 2012, at 11:03, Tuncer Ayaz wrote: > Try this > $ sudo scutil --set HostName `hostname -s`.local This seems to solve the immediate problem. The question remains: shouldn't inet_config be initialized the same way in both cases? BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From jesper.louis.andersen@REDACTED Thu Apr 12 12:14:32 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 12 Apr 2012 12:14:32 +0200 Subject: [erlang-bugs] Documentation typo in Common Test users guide? Message-ID: <4F86AB08.9070500@erlang-solutions.com> Hi, At the URL http://www.erlang.org/doc/apps/common_test/ct_hooks_chapter.html#id78409 We have the line: -ct_hooks cth_surefix [{path,"/tmp/report.xml"}] Shouldn't that be cth_surefire? -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK -------------- next part -------------- An HTML attachment was scrubbed... URL: From helllamer@REDACTED Fri Apr 13 17:00:46 2012 From: helllamer@REDACTED (Konstantin Nikiforov) Date: Fri, 13 Apr 2012 19:00:46 +0400 Subject: [erlang-bugs] HiPE + -on_load()? Message-ID: <20120413190046.3036a529@avers> Cannot compile helloWorld with -on_load directive and 'native' flag. Issue reproduceable in R14B04, R15B01. Looks like similar problem has been already fixed two years ago: https://github.com/pguyot/otp/tree/pg/hipe_crash_with_on_load a.erl --------------------- -module(a). -on_load(init/0). -export([init/0]). init() -> ok. --------------------- And try to compile it... $> erl Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1> c(a, [native,{hipe,[verbose]}]). Compiling: a Options: [verbose,icode_range,icode_ssa_const_prop, icode_ssa_copy_prop,icode_type,icode_inline_bifs, rtl_lcm,rtl_ssa,rtl_ssa_const_prop,spillmin_color, use_indexing,remove_comments,concurrent_comp, binary_opt,inline_fp,pmatch,peephole,verbose]. EXITED with reason {'trans_fun/2',on_load} @hipe_beam_to_icode:1104 a.erl:none: internal error in native_compile; crash reason: {{badmatch, {'EXIT', {{hipe_beam_to_icode,1104,{'trans_fun/2',on_load}}, [{hipe_beam_to_icode,trans_fun,2, [{file,"hipe_beam_to_icode.erl"},{line,1104}]}, {hipe_beam_to_icode,trans_fun,2, [{file,"hipe_beam_to_icode.erl"},{line,254}]}, {hipe_beam_to_icode,trans_mfa_code,5, [{file,"hipe_beam_to_icode.erl"},{line,125}]}, {hipe_beam_to_icode,trans_beam_function_chunk,2, [{file,"hipe_beam_to_icode.erl"},{line,110}]}, {hipe_beam_to_icode,'-module/2-lc$^1/1-1-',2, [{file,"hipe_beam_to_icode.erl"},{line,106}]}, {hipe,get_beam_icode,4, [{file,"hipe.erl"},{line,602}]}, {hipe,'-run_compiler_1/3-fun-0-',4, [{file,"hipe.erl"},{line,662}]}]}}}, [{hipe,get_beam_icode,4,[{file,"hipe.erl"},{line,601}]}, {hipe,'-run_compiler_1/3-fun-0-',4, [{file,"hipe.erl"},{line,662}]}]} =ERROR REPORT==== 13-Apr-2012::02:07:52 === Error in process <0.43.0> with exit value: {{badmatch,{'EXIT',{{hipe_beam_to_icode,1104,{'trans_fun/2',on_load}},[{hipe_beam_to_icode,trans_fun,2,[{file,"hipe_beam_to_icode.erl"},{line,1104}]},{hipe_beam_to_icode,trans_fun,2,[{file,"hipe_beam_to_icode.erl"},{line,254}]},{hipe_beam_to_icode... error From daniel.goertzen@REDACTED Fri Apr 13 23:28:54 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 13 Apr 2012 16:28:54 -0500 Subject: [erlang-bugs] ssh close() race condition? Message-ID: I am having problems using erlang ssh against an OpenSSH server. I am establishing an ssh connection and then in a freshly spawned process I will do this... command(Conn, Cmd) -> {ok,Chan} = ssh_connection:session_channel(Conn, infinity), success = ssh_connection:exec(Conn, Chan, Cmd, infinity), ... receive data messages until eof... ssh_connection:close(Conn, Chan), ok. I run about 6 of these commands sequentially (new process for each), and most of the time OpenSSH gets angry with me and drops the whole connection. The error given is... channel_by_id: 1: bad id: channel free Disconnecting: Received oclose for nonexistent channel 1. But.... if I add a delay before the close() everything seems to work perfectly: command(Conn, Cmd) -> {ok,Chan} = ssh_connection:session_channel(Conn, infinity), success = ssh_connection:exec(Conn, Chan, Cmd, infinity), ... receive data messages until eof... timer:delay(1000), ssh_connection:close(Conn, Chan), ok. Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Apr 15 19:27:34 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 15 Apr 2012 19:27:34 +0200 Subject: [erlang-bugs] net_adm:ping annoying messages due to /etc/hosts content Message-ID: <4F8B0506.409@wanadoo.fr> Hi, I don't know if it is a bug but I get very annoying SASL error messages as below when I use net_adm:ping() : ---8<---------------------------------------------------- =ERROR REPORT==== 15-Apr-2012::19:07:44 === ** System running to use fully qualified hostnames ** ** Hostname localhost is illegal ** ---8<---------------------------------------------------- because I have in my /etc/hosts ---8<---------------------------------------------------- 127.0.0.1 localhost ---8<---------------------------------------------------- I understand that hostnames known by Erlang should be fully qualified when node is starting with -name but I wonder why it cares about shortnames and especially to localhost because : the strange thing is that when I change to : ---8<---------------------------------------------------- 127.0.0.1 mylocalhost ---8<---------------------------------------------------- I do not have the messages, even if it is not fully qualified too ... Regards From daniel.goertzen@REDACTED Mon Apr 16 03:40:52 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sun, 15 Apr 2012 20:40:52 -0500 Subject: [erlang-bugs] ssh close() race condition? In-Reply-To: References: Message-ID: After reviewing RFC 4254 I can see that there is definitely a bug in ssh_connection:close(). Looking at the code I see that close() will cause a SSH_MSG_CHANNEL_CLOSE to be sent, but no state is changed to record that it happened. When the peer responds with a CLOSE, erlang incorrectly responds with another CLOSE. In record "channel" there is a field called "sent_close" that appears to be intended for recording a locally initiated close(). I suspect this needs to be set to true in ssh_connection_manager:handle_call({close,...}). For my application I will work around this by just not calling close(). Dan. On Fri, Apr 13, 2012 at 4:28 PM, Daniel Goertzen wrote: > I am having problems using erlang ssh against an OpenSSH server. I am > establishing an ssh connection and then in a freshly spawned process I will > do this... > > > command(Conn, Cmd) -> > {ok,Chan} = ssh_connection:session_channel(Conn, infinity), > success = ssh_connection:exec(Conn, Chan, Cmd, infinity), > ... receive data messages until eof... > ssh_connection:close(Conn, Chan), > ok. > > > > I run about 6 of these commands sequentially (new process for each), and > most of the time OpenSSH gets angry with me and drops the whole connection. > The error given is... > > > channel_by_id: 1: bad id: channel free > Disconnecting: Received oclose for nonexistent channel 1. > > > > But.... if I add a delay before the close() everything seems to work > perfectly: > > command(Conn, Cmd) -> > {ok,Chan} = ssh_connection:session_channel(Conn, infinity), > success = ssh_connection:exec(Conn, Chan, Cmd, infinity), > ... receive data messages until eof... > timer:delay(1000), > ssh_connection:close(Conn, Chan), > ok. > > > Dan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile@REDACTED Wed Apr 18 16:16:36 2012 From: emile@REDACTED (Emile Joubert) Date: Wed, 18 Apr 2012 15:16:36 +0100 Subject: [erlang-bugs] 64bit windows installer Message-ID: <4F8ECCC4.1030008@rabbitmq.com> 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. -- Emile Joubert RabbitMQ SpringSource, a division of VMware VMware From pan@REDACTED Thu Apr 19 12:29:57 2012 From: pan@REDACTED (pan@REDACTED) Date: Thu, 19 Apr 2012 12:29:57 +0200 Subject: [erlang-bugs] 64bit windows installer In-Reply-To: <4F8ECCC4.1030008@rabbitmq.com> References: <4F8ECCC4.1030008@rabbitmq.com> Message-ID: Hi! That sure sounds like a bug to me :) I'll have a look at it - thanks for reporting! Cheers, /Patrik On Wed, 18 Apr 2012, 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. > > > > -- > Emile Joubert > > RabbitMQ > SpringSource, a division of VMware > VMware > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ufm@REDACTED Sun Apr 22 10:58:08 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Sun, 22 Apr 2012 11:58:08 +0300 Subject: [erlang-bugs] ssh2_msg_channel_failure Message-ID: <4F93C820.2080103@ufm.su> 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. From videlalvaro@REDACTED Sun Apr 22 11:56:37 2012 From: videlalvaro@REDACTED (Alvaro Videla) Date: Sun, 22 Apr 2012 11:56:37 +0200 Subject: [erlang-bugs] epmd fails to start Message-ID: <36FAA97FB521470B8668928069340FF7@gmail.com> 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 (http://www.sparrowmailapp.com/?sig) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dang@REDACTED Tue Apr 24 02:28:33 2012 From: dang@REDACTED (Daniel Goertzen) Date: Mon, 23 Apr 2012 19:28:33 -0500 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F93C820.2080103@ufm.su> References: <4F93C820.2080103@ufm.su> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Tue Apr 24 10:21:44 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 24 Apr 2012 10:21:44 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: References: <4F93C820.2080103@ufm.su> Message-ID: <4F966298.4040706@erix.ericsson.se> 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 > From attila.r.nohl@REDACTED Tue Apr 24 12:27:02 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 24 Apr 2012 12:27:02 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F966298.4040706@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> Message-ID: Hello! Am I correct that this patch is not in R15B01? 2012/4/24 Ingela Anderton Andin : > 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 From ingela@REDACTED Tue Apr 24 14:52:24 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 24 Apr 2012 14:52:24 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> Message-ID: <4F96A208.4030608@erix.ericsson.se> Hi! Attila Rajmund Nohl wrote: > Hello! > > Am I correct that this patch is not in R15B01? > > No this patch is not in R15B01, it will be in R15B02 I merged it today actually. Regards Ingela Erlang/OTP team - Ericsson AB > 2012/4/24 Ingela Anderton Andin : > >> 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 >> > > From ufm@REDACTED Tue Apr 24 18:22:06 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Tue, 24 Apr 2012 19:22:06 +0300 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F966298.4040706@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> Message-ID: <4F96D32E.7040302@ufm.su> 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 > From dang@REDACTED Tue Apr 24 20:16:28 2012 From: dang@REDACTED (Daniel Goertzen) Date: Tue, 24 Apr 2012 13:16:28 -0500 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F96D32E.7040302@ufm.su> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> Message-ID: 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. 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. 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 >> ufm@REDACTED>> 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 >>> **com >> networkintegritysystems.com > >>> *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 < >>> http://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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Wed Apr 25 10:34:49 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 25 Apr 2012 10:34:49 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> Message-ID: <4F97B729.8020004@erix.ericsson.se> 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 carlsson.richard@REDACTED Wed Apr 25 10:43:55 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 25 Apr 2012 10:43:55 +0200 Subject: [erlang-bugs] handling of uncaught exceptions in behavour callbacks Message-ID: <4F97B94B.8080307@gmail.com> When gen_server, gen_fsm, etc., make a call to one of the behaviour callback functions, these calls are protected by a construct on the following form (simplified): case catch Mod:some_callback(...) of ... {'EXIT',Reason} -> exit(Reason); Other -> exit({bad_return_value, Other}) end When a callback terminates with an exception of type 'error' or 'exit', this sort of does the expected thing (although it converts error exceptions to exit exceptions, which might or might not be intended). But if the callback terminates due to an uncaught throw(Term), it is treated as if the callback had returned Term. At best, this is an undocumented and horrible way of letting you write callback functions that can do things like throw({reply, Reply, NewState}) for nonlocal return out of a deep recursion and back to the gen_server code. But I'd like to think that it's simply unintended behaviour. (Nothing I could see in the OTP documentation describes what the gen_server is supposed to do with exceptions thrown from a callback.) The annoyance this causes is that if you use throw(X) for anything within the callback (or in library code called by the callback) and you don't make sure to wrap your callback in something that catches all throws, any such uncaught exception will result in the gen_server process terminating with the confusing reason {bad_return_value, X} (and no stack trace to indicate where X was thrown from). If it can be agreed that this is a bug that should be fixed (and how), we could submit a patch. /Richard Carlsson and Samuel Rivas From daniel@REDACTED Wed Apr 25 15:21:25 2012 From: daniel@REDACTED (Daniel Luna) Date: Wed, 25 Apr 2012 09:21:25 -0400 Subject: [erlang-bugs] handling of uncaught exceptions in behavour callbacks In-Reply-To: <4F97B94B.8080307@gmail.com> References: <4F97B94B.8080307@gmail.com> Message-ID: Hi Richard and list, I personally fully agree that it's a bug, but more importantly a fix of this would hopefully finally allow me to have stacktraces when gen_servers die. It also explains why you sometimes get strange behavior such as (paraphrasing) "gen_server died due to {bad_return_value, something_thrown_by_third_party_library}", often without the crash telling you the type of the gen_server or any information whatsoever about the stacktrace. A rewrite of this would be sweet. Cheers, Daniel On 25 April 2012 04:43, Richard Carlsson wrote: > When gen_server, gen_fsm, etc., make a call to one of the behaviour callback > functions, these calls are protected by a construct on the following form > (simplified): > > ? ?case catch Mod:some_callback(...) of > ? ? ? ?... > ? ? ? ?{'EXIT',Reason} -> exit(Reason); > ? ? ? ?Other -> exit({bad_return_value, Other}) > ? ?end > > When a callback terminates with an exception of type 'error' or 'exit', this > sort of does the expected thing (although it converts error exceptions to > exit exceptions, which might or might not be intended). But if the callback > terminates due to an uncaught throw(Term), it is treated as if the callback > had returned Term. At best, this is an undocumented and horrible way of > letting you write callback functions that can do things like throw({reply, > Reply, NewState}) for nonlocal return out of a deep recursion and back to > the gen_server code. But I'd like to think that it's simply unintended > behaviour. (Nothing I could see in the OTP documentation describes what the > gen_server is supposed to do with exceptions thrown from a callback.) > > The annoyance this causes is that if you use throw(X) for anything within > the callback (or in library code called by the callback) and you don't make > sure to wrap your callback in something that catches all throws, any such > uncaught exception will result in the gen_server process terminating with > the confusing reason {bad_return_value, X} (and no stack trace to indicate > where X was thrown from). > > If it can be agreed that this is a bug that should be fixed (and how), we > could submit a patch. > > ? ?/Richard Carlsson and Samuel Rivas > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From mononcqc@REDACTED Wed Apr 25 17:33:25 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 25 Apr 2012 11:33:25 -0400 Subject: [erlang-bugs] handling of uncaught exceptions in behavour callbacks In-Reply-To: <4F97B94B.8080307@gmail.com> References: <4F97B94B.8080307@gmail.com> Message-ID: <4F981945.3040806@ferd.ca> I would also agree to see this as a bug. Regarding the fix, wouldn't rewriting it to use a try ... of ... catch negate the problem entirely by being able to make the distinction between a throw and a returned value? try Mod:some_callback(...) of ... Other -> exit({bad_return_value, Other} catch _:Reason -> exit(Reason) end or something similar, as long as we keep similar error/exit semantics? I figure the throw could be seen as the standard bubbling thing where throw becomes an error, which becomes an error before the process dies. On 12-04-25 4:43 AM, Richard Carlsson wrote: > When gen_server, gen_fsm, etc., make a call to one of the behaviour > callback functions, these calls are protected by a construct on the > following form (simplified): > > case catch Mod:some_callback(...) of > ... > {'EXIT',Reason} -> exit(Reason); > Other -> exit({bad_return_value, Other}) > end > > When a callback terminates with an exception of type 'error' or > 'exit', this sort of does the expected thing (although it converts > error exceptions to exit exceptions, which might or might not be > intended). But if the callback terminates due to an uncaught > throw(Term), it is treated as if the callback had returned Term. At > best, this is an undocumented and horrible way of letting you write > callback functions that can do things like throw({reply, Reply, > NewState}) for nonlocal return out of a deep recursion and back to the > gen_server code. But I'd like to think that it's simply unintended > behaviour. (Nothing I could see in the OTP documentation describes > what the gen_server is supposed to do with exceptions thrown from a > callback.) > > The annoyance this causes is that if you use throw(X) for anything > within the callback (or in library code called by the callback) and > you don't make sure to wrap your callback in something that catches > all throws, any such uncaught exception will result in the gen_server > process terminating with the confusing reason {bad_return_value, X} > (and no stack trace to indicate where X was thrown from). > > If it can be agreed that this is a bug that should be fixed (and how), > we could submit a patch. > > /Richard Carlsson and Samuel Rivas > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From ufm@REDACTED Wed Apr 25 19:10:29 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Wed, 25 Apr 2012 20:10:29 +0300 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F97B729.8020004@erix.ericsson.se> References: <4F93C820.2080103@ufm.su> <4F966298.4040706@erix.ericsson.se> <4F96D32E.7040302@ufm.su> <4F97B729.8020004@erix.ericsson.se> Message-ID: <4F983005.9080803@ufm.su> Hi! putty say "Server send disconnect message type 11 (by application): "Internal error" Erlang say: =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 carlsson.richard@REDACTED Wed Apr 25 20:20:08 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 25 Apr 2012 20:20:08 +0200 Subject: [erlang-bugs] handling of uncaught exceptions in behavour callbacks In-Reply-To: <4F981945.3040806@ferd.ca> References: <4F97B94B.8080307@gmail.com> <4F981945.3040806@ferd.ca> Message-ID: <4F984058.5090105@gmail.com> On 2012-04-25 17:33, Fred Hebert wrote: > I would also agree to see this as a bug. > > Regarding the fix, wouldn't rewriting it to use a try ... of ... catch > negate the problem entirely by being able to make the distinction > between a throw and a returned value? > > try Mod:some_callback(...) of > ... > Other -> exit({bad_return_value, Other} > catch > _:Reason -> exit(Reason) > end > > or something similar, as long as we keep similar error/exit semantics? It's the "similar" that's the issue here. What can we change without breaking too much existing code? That's why I would like a clear statement from the OTP team before I try to create a patch. > I figure the throw could be seen as the standard bubbling thing where > throw becomes an error, which becomes an error before the process dies. Yes, I think that an uncaught throw should turn into error({nocatch, Term}), but there's also the question of whether 'error' exceptions should be turned into exits as it is done now in gen_server. It would probably be nicest if the gen_server framework didn't affect the exit signal sent by a process when it dies: if spawn(M,F,[...]) sends out signal X in a particular situation, then if you wrap M:F(...) using the gen_server library, the process should still send out X in the same situation. That's not the case today however, and the question is, can we make it so without upsetting too much old code? /Richard From kostis@REDACTED Wed Apr 25 23:33:57 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 25 Apr 2012 23:33:57 +0200 Subject: [erlang-bugs] erlc +S crashes Message-ID: <4F986DC5.5030703@cs.ntua.gr> erlc does not recognize the option that sets the number of schedulers (+S N or +S N:M or +SN). Actually, it crashes badly in this case. .../SomePath/R15B01/bin/erlc +S1 foo.erl bad term: S1 Runtime error: {{nocatch,error}, [{erl_compile,make_term,1, [{file,"erl_compile.erl"},{line,219}]}, {erl_compile,compile1,3, [{file,"erl_compile.erl"},{line,129}]}, {erl_compile,compiler_runner,1, [{file,"erl_compile.erl"},{line,82}]}]} It would be nice to fix this. Kostis From ingela@REDACTED Fri Apr 27 10:54:58 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 27 Apr 2012 10:54:58 +0200 Subject: [erlang-bugs] ssh2_msg_channel_failure In-Reply-To: <4F983005.9080803@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> Message-ID: <4F9A5EE2.2080106@erix.ericsson.se> 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. >>> >>> >> > From ufm@REDACTED Fri Apr 27 19:37:55 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Fri, 27 Apr 2012 20:37:55 +0300 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: <4F9AD973.7010808@ufm.su> 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. >>>> >>>> >>> >> >