From raimo+erlang-bugs@REDACTED Wed Jul 1 12:20:02 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 12:20:02 +0200 Subject: [erlang-bugs] gen_server:start hangs In-Reply-To: References: Message-ID: <20090701102002.GC17444@erix.ericsson.se> On Wed, Jun 24, 2009 at 01:32:01PM -0500, Brentley Jones wrote: > Hello, > > I came across a weird hang when using gen_server:start. When inside > Module:init/1 and it returns the wrong value, erlang:error's, > erlang:exit's, or erlang:throw's, this gets passed onto the caller. > But when you spawn_link a process and it dies before Module:init/1 > returns, gen_server:start hangs. This seems to be a bug, indeed. Thankfully the most common way to start a gen_server is start_link, and then there is no problem. The caller hangs in proc_lib:sync_wait/2 since gen_server:init_it/6 fails to call proc_lib:init_ack/2 when killed by a process link. In case you use gen_server:start_link and process_flag(trap_exit, true) in your test program, it is caught by proc_lib:sync_wait/2, so the code tries to handle this but fails when there is no process link, hence it must be a bug now when we can use monitors. The solution would probably be to use a monitor in proc_lib. We will fix this in a future release. > > Here is the output and code to demonstrate it: > > Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async- > threads:0] [kernel-poll:false] > > Eshell V5.7.2 (abort with ^G) > 1> gen_server_bug:test(throw). > {error,{bad_return_value,throw_fail}} > 2> gen_server_bug:test(error). > {error,{error_fail,[{gen_server_bug,init,1}, > {gen_server,init_it,6}, > {proc_lib,init_p_do_apply,3}]}} > 3> gen_server_bug:test(exit). > {error,exit_fail} > 4> gen_server_bug:test(spawn_bug). > % hangs here... > > > %% gen_server_bug.erl > -module(gen_server_bug). > > -export([init/1]). > -export([test/1]). > > test(Type) -> > gen_server:start(?MODULE, Type, []). > > init(throw) -> > erlang:throw(throw_fail), > {ok, ok}; > init(error) -> > erlang:error(error_fail), > {ok, ok}; > init(exit) -> > erlang:exit(exit_fail), > {ok, ok}; > init(spawn_bug) -> > spawn_link(fun() -> erlang:exit(spawn_exit) end), > %% Wait so this process dies from the linked process dieing > receive > after 1000 -> ok > end, > {ok, ok}. > > > > Also, no response on the Dialyzer bugs? ( > http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1347:200906:lgkhjjcjokhpllgmkinj > and > http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1350:200906:nmcjgdfnlcnjelpijacl > ) > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From siganos@REDACTED Wed Jul 1 17:25:14 2009 From: siganos@REDACTED (Georgos Siganos) Date: Wed, 1 Jul 2009 17:25:14 +0200 Subject: Segmentation Fault R13B01 Message-ID: Hi All,I am having problems with R13B01 and segmentation faults, as the following one (in the bottom). Unfortunately, i am not sure which part of the code triggers the segmentation fault. I am running Centos 5.3 ( 2.6.18-128.1.16.el5 #1 SMP x86_64 ) on a quad core intel processor. The program quits with segfault both when compiled with and without hipe. Please let me know if there is anything else i can report to fix this problem. This segmentation fault is quite consistent and is a show stopper for my code. Thanks, Georgos ----------------------- gdb output -------------------------- Program terminated with signal 11, Segmentation fault. [New process 12531] [New process 12533] [New process 12532] [New process 12530] [New process 12526] [New process 12517] [New process 12516] [New process 12514] #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 (gdb) bt #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 #1 0x0000000000486849 in driver_deliver_term (port=, to=4816451, data=, len=) at beam/io.c:2994 #2 0x00000000005513cf in tcp_deliver (desc=0x2aab17c17548, len=3) at drivers/common/inet_drv.c:2980 #3 0x0000000000551891 in tcp_recv (desc=0x2aab17c17548, request_len=0) at drivers/common/inet_drv.c:8043 #4 0x0000000000551afc in tcp_inet_drv_input (data=0x2aaae21a9fc4, event=) at drivers/common/inet_drv.c:8381 #5 0x00000000004a3d78 in erts_port_task_execute (runq=0x2add1fc19340, curr_port_pp=0x2aaaaaacb1e8) at beam/erl_port_task.c:853 #6 0x000000000049ebc5 in schedule (p=0x349, calls=) at beam/erl_process.c:6116 #7 0x0000000000505afd in process_main () at beam/beam_emu.c:1126 #8 0x0000000000499126 in sched_thread_func (vesdp=) at beam/erl_process.c:3015 #9 0x000000000057a0f4 in thr_wrapper (vtwd=) at common/ethread.c:475 #10 0x00002add1f31b367 in start_thread () from /lib64/libpthread.so.0 #11 0x00002add1f80cf7d in clone () from /lib64/libc.so.6 --------------------------------------------------------------------------- From raimo+erlang-bugs@REDACTED Wed Jul 1 18:06:54 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 18:06:54 +0200 Subject: [erlang-bugs] Segmentation Fault R13B01 In-Reply-To: References: Message-ID: <20090701160654.GA19778@erix.ericsson.se> On Wed, Jul 01, 2009 at 05:25:14PM +0200, Georgos Siganos wrote: > Hi All,I am having problems with R13B01 and segmentation faults, as the > following one (in the bottom). > Unfortunately, i am not sure which part of the code triggers the > segmentation fault. > > I am running Centos 5.3 ( 2.6.18-128.1.16.el5 #1 SMP x86_64 ) on a quad core > intel processor. > The program quits with segfault both when compiled with and without hipe. > > Please let me know if there is anything else i can report to fix this > problem. This > segmentation > fault is quite consistent and is a show stopper for my code. > Thanks, > Georgos How did you build the Erlang emulator, how did you start it (arguments), how did you provoke the segfault? Can you post the code that provokes this to see if it is reproducable on other OS:es? Can you post the core dump for the Erlang/OTP team to dissect? Can you build and run a debug emulator and see if you get an earlier fault detection? (gmake smp TYPE=debug in the emulator directory) > > > ----------------------- gdb output -------------------------- > Program terminated with signal 11, Segmentation fault. > [New process 12531] > [New process 12533] > [New process 12532] > [New process 12530] > [New process 12526] > [New process 12517] > [New process 12516] > [New process 12514] > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > (gdb) bt > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > #1 0x0000000000486849 in driver_deliver_term (port=, > to=4816451, data=, > len=) at beam/io.c:2994 > #2 0x00000000005513cf in tcp_deliver (desc=0x2aab17c17548, len=3) at > drivers/common/inet_drv.c:2980 > #3 0x0000000000551891 in tcp_recv (desc=0x2aab17c17548, request_len=0) at > drivers/common/inet_drv.c:8043 > #4 0x0000000000551afc in tcp_inet_drv_input (data=0x2aaae21a9fc4, > event=) at drivers/common/inet_drv.c:8381 > #5 0x00000000004a3d78 in erts_port_task_execute (runq=0x2add1fc19340, > curr_port_pp=0x2aaaaaacb1e8) at beam/erl_port_task.c:853 > #6 0x000000000049ebc5 in schedule (p=0x349, calls=) at > beam/erl_process.c:6116 > #7 0x0000000000505afd in process_main () at beam/beam_emu.c:1126 > #8 0x0000000000499126 in sched_thread_func (vesdp=) at > beam/erl_process.c:3015 > #9 0x000000000057a0f4 in thr_wrapper (vtwd=) at > common/ethread.c:475 > #10 0x00002add1f31b367 in start_thread () from /lib64/libpthread.so.0 > #11 0x00002add1f80cf7d in clone () from /lib64/libc.so.6 > --------------------------------------------------------------------------- -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From siganos@REDACTED Wed Jul 1 18:33:30 2009 From: siganos@REDACTED (Georgos Siganos) Date: Wed, 1 Jul 2009 18:33:30 +0200 Subject: [erlang-bugs] Segmentation Fault R13B01 In-Reply-To: <20090701160654.GA19778@erix.ericsson.se> References: <20090701160654.GA19778@erix.ericsson.se> Message-ID: Hi,I build erlang using gcc 4.1.2 (the default for centos) I started erl using -env ERL_MAX_PORTS 110000 +K true +P 110000 +S4 -smp -detached You can download 3 core dumps http://94.75.214.130/core.12514.gz http://94.75.214.130/core.939.gz http://94.75.214.130/core.28223.gz Unfortunately, i have no clue which part of the code triggers the segfault, other than it happens constantly, and i can not redistribute the whole program. The program though uses heavily tcp connections, typically i have over 10k established tcp connections. I would try to build the debug emulator tonight and let you know if i find something. Thanks, Georgos 2009/7/1 Raimo Niskanen > > On Wed, Jul 01, 2009 at 05:25:14PM +0200, Georgos Siganos wrote: > > Hi All,I am having problems with R13B01 and segmentation faults, as the > > following one (in the bottom). > > Unfortunately, i am not sure which part of the code triggers the > > segmentation fault. > > > > I am running Centos 5.3 ( 2.6.18-128.1.16.el5 #1 SMP x86_64 ) on a quad > core > > intel processor. > > The program quits with segfault both when compiled with and without hipe. > > > > Please let me know if there is anything else i can report to fix this > > problem. This > > segmentation > > fault is quite consistent and is a show stopper for my code. > > Thanks, > > Georgos > > How did you build the Erlang emulator, how did you start it > (arguments), how did you provoke the segfault? > > Can you post the code that provokes this to see > if it is reproducable on other OS:es? > > Can you post the core dump for the Erlang/OTP team to dissect? > > Can you build and run a debug emulator and see if you get an earlier > fault detection? (gmake smp TYPE=debug in the emulator directory) > > > > > > > ----------------------- gdb output -------------------------- > > Program terminated with signal 11, Segmentation fault. > > [New process 12531] > > [New process 12533] > > [New process 12532] > > [New process 12530] > > [New process 12526] > > [New process 12517] > > [New process 12516] > > [New process 12514] > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > (gdb) bt > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > #1 0x0000000000486849 in driver_deliver_term (port= out>, > > to=4816451, data=, > > len=) at beam/io.c:2994 > > #2 0x00000000005513cf in tcp_deliver (desc=0x2aab17c17548, len=3) at > > drivers/common/inet_drv.c:2980 > > #3 0x0000000000551891 in tcp_recv (desc=0x2aab17c17548, request_len=0) > at > > drivers/common/inet_drv.c:8043 > > #4 0x0000000000551afc in tcp_inet_drv_input (data=0x2aaae21a9fc4, > > event=) at drivers/common/inet_drv.c:8381 > > #5 0x00000000004a3d78 in erts_port_task_execute (runq=0x2add1fc19340, > > curr_port_pp=0x2aaaaaacb1e8) at beam/erl_port_task.c:853 > > #6 0x000000000049ebc5 in schedule (p=0x349, calls=) > at > > beam/erl_process.c:6116 > > #7 0x0000000000505afd in process_main () at beam/beam_emu.c:1126 > > #8 0x0000000000499126 in sched_thread_func (vesdp=) > at > > beam/erl_process.c:3015 > > #9 0x000000000057a0f4 in thr_wrapper (vtwd=) at > > common/ethread.c:475 > > #10 0x00002add1f31b367 in start_thread () from /lib64/libpthread.so.0 > > #11 0x00002add1f80cf7d in clone () from /lib64/libc.so.6 > > > --------------------------------------------------------------------------- > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > From mjtruog@REDACTED Fri Jul 3 02:16:51 2009 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 02 Jul 2009 17:16:51 -0700 Subject: node type in documentation or API? Message-ID: <4A4D4DF3.9060202@gmail.com> The documentation is a little ambiguous when it mentions the node type since it uses "node()" instead of "atom()", and this may be on purpose. If this is on purpose it would be really nice to have a function "erlang:is_node(Node)" for guard tests. Otherwise, if I put "erlang:is_atom(Node)" in the guard tests, I am making the assumption that node types are always atoms. I don't know if that is always suppose to be the case since the documentation uses a separate type. Thanks, Michael Truog From oscar@REDACTED Fri Jul 3 16:39:48 2009 From: oscar@REDACTED (=?ISO-8859-1?Q?Oscar_Hellstr=F6m?=) Date: Fri, 03 Jul 2009 15:39:48 +0100 Subject: Packet type http and httph in {inet,ssl}:setopts/2 Message-ID: <4A4E1834.1080402@erlang-consulting.com> Hi All, In the documentation in the inet module the last line reads: "Note that the packet type httph is not needed when reading from a socket." This isn't quite true if you want to read HTTP Trailers which can be found after an entity body using the chunked transfer coding. Setting the option {packet, http} and then reading the following data: "Trailer-1: 1\r\n\r\n" Will return {http_error, "Trailer-1: 1\r\n"} instead of {ok, {http_header, ...}}. I guess that's because the http parser is keeping a state of some sort. Using the option {packet, httph} however works well for reading trailer both for the ssl module and gen_tcp / inet. Is there any possibility to document the use of packet type httph as a valid option for {inet,ssl}:setopts/2 as well? Best regards -- Oscar Hellstr?m, oscar@REDACTED Office: +44 20 7655 0337 Mobile: +44 798 45 44 773 Erlang Training and Consulting Ltd http://www.erlang-consulting.com/ From sverker@REDACTED Fri Jul 3 17:06:16 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 03 Jul 2009 17:06:16 +0200 Subject: [erlang-bugs] Packet type http and httph in {inet,ssl}:setopts/2 In-Reply-To: <4A4E1834.1080402@erlang-consulting.com> References: <4A4E1834.1080402@erlang-consulting.com> Message-ID: <4A4E1E68.1020401@erix.ericsson.se> Oscar Hellstr?m wrote: > Hi All, > > In the documentation in the inet module the last line reads: > "Note that the packet type httph is not needed when reading from a socket." > > This isn't quite true if you want to read HTTP Trailers which can be > found after an entity body using the chunked transfer coding. Setting > the option {packet, http} and then reading the following data: > "Trailer-1: 1\r\n\r\n" > Will return {http_error, "Trailer-1: 1\r\n"} instead of {ok, > {http_header, ...}}. I guess that's because the http parser is keeping a > state of some sort. Yes, the socket holds a state and automatically switches from http to httph after a request or response has been received. When the parser is called via erlang:decode_packet/3, no such state exist. > Using the option {packet, httph} however works well > for reading trailer both for the ssl module and gen_tcp / inet. Is there > any possibility to document the use of packet type httph as a valid > option for {inet,ssl}:setopts/2 as well? > > Yes, I will make that more clear. I guess "httph is not needed" was to over-simplify things. /Sverker, Erlang/OTP From ulf.wiger@REDACTED Fri Jul 3 17:32:39 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 03 Jul 2009 17:32:39 +0200 Subject: bug in erl_eval Message-ID: <4A4E2497.5030400@erlang-consulting.com> The following shell dialogue didn't work out as expected: 1> E = fun(N) -> if is_integer(N) -> <>; true -> throw(foo) end end. #Fun 2> << << (E(V))/binary >> || V <- [1,2,3] >>. <<1,2,3>> 3> catch << << (E(V))/binary >> || V <- [1,2,3,a] >>. {'EXIT',{{case_clause,foo}, [{erl_eval,expr,5}, {erl_eval,eval_bc1,6}, {erl_eval,eval_generate,7}, {erl_eval,eval_bc,6}, {erl_eval,expr,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]}} List comprehensions work as expected, though. 4> [ E(V) || V <- [1,2,3]]. [<<1>>,<<2>>,<<3>>] 5> catch [ E(V) || V <- [1,2,3,a]]. foo BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From wglozer@REDACTED Sat Jul 4 20:01:22 2009 From: wglozer@REDACTED (Will) Date: Sat, 4 Jul 2009 11:01:22 -0700 Subject: PATCH - public_key should handle unknown attribute types Message-ID: Hi, SSL handshaking with new_ssl will fail when a certificate contains attributes unknown to the public_key module. Here is a patch that leaves the attribute value encoded when its type is unknown. -Will From wglozer@REDACTED Sat Jul 4 21:46:39 2009 From: wglozer@REDACTED (Will) Date: Sat, 4 Jul 2009 12:46:39 -0700 Subject: PATCH - public_key should handle unknown attribute types In-Reply-To: References: Message-ID: Odd, gmail clearly shows the diff attached, but it doesn't seem to have made it through the mailing list processing. Here's an inline copy... On Sat, Jul 4, 2009 at 11:01 AM, Will wrote: > Hi, > > SSL handshaking with new_ssl will fail when a certificate contains > attributes unknown to the public_key module. Here is a patch that > leaves the attribute value encoded when its type is unknown. > > -Will > diff -r 80795205fd0a src/pubkey_cert_records.erl --- a/src/pubkey_cert_records.erl Sat Jul 04 10:44:41 2009 -0700 +++ b/src/pubkey_cert_records.erl Sat Jul 04 10:51:40 2009 -0700 @@ -187,8 +187,11 @@ end, Exts). transform(#'AttributeTypeAndValue'{type=Id,value=Value0} = ATAV, Func) -> - Type = attribute_type(Id), - {ok, Value} = 'OTP-PUB-KEY':Func(Type, Value0), + {ok, Value} = + case attribute_type(Id) of + Type when is_atom(Type) -> 'OTP-PUB-KEY':Func(Type, Value0); + _UnknownType -> {ok, Value0} + end, ATAV#'AttributeTypeAndValue'{value=Value}; transform(AKI = #'AuthorityKeyIdentifier'{authorityCertIssuer=ACI},Func) -> AKI#'AuthorityKeyIdentifier'{authorityCertIssuer=transform(ACI,Func)}; @@ -231,7 +234,8 @@ attribute_type(?'id-at-serialNumber') -> 'X520SerialNumber'; attribute_type(?'id-at-pseudonym') -> 'X520Pseudonym'; attribute_type(?'id-domainComponent') -> 'DomainComponent'; -attribute_type(?'id-emailAddress') -> 'EmailAddress'. +attribute_type(?'id-emailAddress') -> 'EmailAddress'; +attribute_type(Type) -> Type. %%% Old code transforms From dgud@REDACTED Mon Jul 6 11:05:49 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 06 Jul 2009 11:05:49 +0200 Subject: [erlang-bugs] Re: PATCH - public_key should handle unknown attribute types In-Reply-To: References: Message-ID: <4A51BE6D.1090705@erix.ericsson.se> Thanks applied. /Dan Will wrote: > Odd, gmail clearly shows the diff attached, but it doesn't seem to > have made it through the mailing list processing. Here's an inline > copy... > > On Sat, Jul 4, 2009 at 11:01 AM, Will wrote: >> Hi, >> >> SSL handshaking with new_ssl will fail when a certificate contains >> attributes unknown to the public_key module. Here is a patch that >> leaves the attribute value encoded when its type is unknown. >> >> -Will >> > > diff -r 80795205fd0a src/pubkey_cert_records.erl > --- a/src/pubkey_cert_records.erl Sat Jul 04 10:44:41 2009 -0700 > +++ b/src/pubkey_cert_records.erl Sat Jul 04 10:51:40 2009 -0700 > @@ -187,8 +187,11 @@ > end, Exts). > > transform(#'AttributeTypeAndValue'{type=Id,value=Value0} = ATAV, Func) -> > - Type = attribute_type(Id), > - {ok, Value} = 'OTP-PUB-KEY':Func(Type, Value0), > + {ok, Value} = > + case attribute_type(Id) of > + Type when is_atom(Type) -> 'OTP-PUB-KEY':Func(Type, Value0); > + _UnknownType -> {ok, Value0} > + end, > ATAV#'AttributeTypeAndValue'{value=Value}; > transform(AKI = #'AuthorityKeyIdentifier'{authorityCertIssuer=ACI},Func) -> > AKI#'AuthorityKeyIdentifier'{authorityCertIssuer=transform(ACI,Func)}; > @@ -231,7 +234,8 @@ > attribute_type(?'id-at-serialNumber') -> 'X520SerialNumber'; > attribute_type(?'id-at-pseudonym') -> 'X520Pseudonym'; > attribute_type(?'id-domainComponent') -> 'DomainComponent'; > -attribute_type(?'id-emailAddress') -> 'EmailAddress'. > +attribute_type(?'id-emailAddress') -> 'EmailAddress'; > +attribute_type(Type) -> Type. > > %%% Old code transforms > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From raimo+erlang-bugs@REDACTED Mon Jul 6 12:02:34 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 6 Jul 2009 12:02:34 +0200 Subject: [erlang-bugs] node type in documentation or API? In-Reply-To: <4A4D4DF3.9060202@gmail.com> References: <4A4D4DF3.9060202@gmail.com> Message-ID: <20090706100234.GB4401@erix.ericsson.se> On Thu, Jul 02, 2009 at 05:16:51PM -0700, Michael Truog wrote: > The documentation is a little ambiguous when it mentions the node type > since it uses "node()" instead of "atom()", and this may be on purpose. > If this is on purpose it would be really nice to have a function > "erlang:is_node(Node)" for guard tests. Otherwise, if I put > "erlang:is_atom(Node)" in the guard tests, I am making the assumption > that node types are always atoms. I don't know if that is always > suppose to be the case since the documentation uses a separate type. > > Thanks, > Michael Truog That is a beautiful thought, but very hard to do. The documentation uses node() for clairty. We could introduce is_node/1, but making a node a separate type in the emulator would break lots of existing code. So we would have to warn several release before, and those customers that have large (millions of lines of code) applications in maintenance would most probably refuse such an update, forcing us into two release tracks for the lifetime of their products. The semantics of is_node/1 must also be decided. Will it return true for existing nodes, existing and old nodes, or existing and old and possible future nodes. It is very unlikely this will ever happen. > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From vychodil.hynek@REDACTED Mon Jul 6 12:48:13 2009 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Mon, 6 Jul 2009 12:48:13 +0200 Subject: Bad argument when open_port with spawn_executable Message-ID: <4d08db370907060348m266463f0hb79cf65a80a4b184@mail.gmail.com> Hello, according to documentation I'm trying use spawn_executable argument to open_port/2. It seems there is a bug or I missed something? 13> open_port({spawn_executable, os:find_executable("perl")}, []). ** exception error: bad argument in function open_port/2 called as open_port({spawn_executable,"/usr/bin/perl"},[]) I obtain same result for wide variety of PortSettings which seems not affecting it. Best regards -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try Good Data now for free: www.gooddata.com From kenneth.lundin@REDACTED Mon Jul 6 13:25:43 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 6 Jul 2009 13:25:43 +0200 Subject: [erlang-bugs] Bad argument when open_port with spawn_executable In-Reply-To: <4d08db370907060348m266463f0hb79cf65a80a4b184@mail.gmail.com> References: <4d08db370907060348m266463f0hb79cf65a80a4b184@mail.gmail.com> Message-ID: The spawn_executable variant of erlang:open_port was introduced in R13B01. The error you get indicates that you are running on an older version of Erlang/OTP. The bad argument refers to {spawn_exectable,_} which is not supported before R13B01. /Kenneth Erlang/OTP, Ericsson On Mon, Jul 6, 2009 at 12:48 PM, Hynek Vychodil wrote: > Hello, > according to documentation I'm trying use spawn_executable argument to > open_port/2. It seems there is a bug or I missed something? > > 13> open_port({spawn_executable, os:find_executable("perl")}, []). > ** exception error: bad argument > ? ? in function ?open_port/2 > ? ? ? ?called as open_port({spawn_executable,"/usr/bin/perl"},[]) > > I obtain same result for wide variety of PortSettings which seems not > affecting it. > > Best regards > > -- > --Hynek (Pichi) Vychodil > > Analyze your data in minutes. Share your insights instantly. Thrill your > boss. ?Be a data hero! > Try Good Data now for free: www.gooddata.com > From huntermorris@REDACTED Mon Jul 6 14:01:45 2009 From: huntermorris@REDACTED (Hunter Morris) Date: Mon, 6 Jul 2009 13:01:45 +0100 Subject: inets httpd incorrectly returns 501 Not Implemented for 'PUT' and 'DELETE' methods Message-ID: <2a58867d0907060501w40f7039dxbe424f5bdecc8ce9@mail.gmail.com> Hello, httpd_request:validate/3 does not allow applications to use the 'PUT' and 'DELETE' methods which are common in many server applications. The patch included inline would allow the two additional methods: --- lib/inets/src/http_server/httpd_request.erl | 6 +++++- lib/inets/src/http_server/mod_cgi.erl | 2 ++ lib/inets/src/http_server/mod_esi.erl | 24 ++++++++++++++++++++++++ 3 files changed, 31 insertions(+), 1 deletions(-) diff --git a/lib/inets/src/http_server/httpd_request.erl b/lib/inets/src/http_server/httpd_request.erl index ad2cc4b..5a2f0d4 100644 --- a/lib/inets/src/http_server/httpd_request.erl +++ b/lib/inets/src/http_server/httpd_request.erl @@ -71,7 +71,7 @@ body_data(Headers, Body) -> %%------------------------------------------------------------------------- %% validate(Method, Uri, Version) -> ok | {error, {bad_request, Reason} | %% {error, {not_supported, {Method, Uri, Version}} -%% Method = "HEAD" | "GET" | "POST" | "TRACE" +%% Method = "HEAD" | "GET" | "POST" | "TRACE" | "PUT" | "DELETE" %% Uri = uri() %% Version = "HTTP/N.M" %% Description: Checks that HTTP-request-line is valid. @@ -86,6 +86,10 @@ validate("GET", Uri, "HTTP/1." ++ _N) -> validate_uri(Uri); validate("POST", Uri, "HTTP/1." ++ _N) -> validate_uri(Uri); +validate("PUT", Uri, "HTTP/1." ++ _N) -> + validate_uri(Uri); +validate("DELETE", Uri, "HTTP/1." ++ _N) -> + validate_uri(Uri); validate("TRACE", Uri, "HTTP/1." ++ N) when hd(N) >= $1 -> validate_uri(Uri); validate(Method, Uri, Version) -> diff --git a/lib/inets/src/http_server/mod_cgi.erl b/lib/inets/src/http_server/mod_cgi.erl index ab12a3b..a0206bd 100644 --- a/lib/inets/src/http_server/mod_cgi.erl +++ b/lib/inets/src/http_server/mod_cgi.erl @@ -335,6 +335,8 @@ script_elements(#mod{method = "GET"}, {PathInfo, QueryString}) -> [{query_string, QueryString}, {path_info, PathInfo}]; script_elements(#mod{method = "POST", entity_body = Body}, _) -> [{entity_body, Body}]; +script_elements(#mod{method = "PUT", entity_body = Body}, _) -> + [{entity_body, Body}]; script_elements(_, _) -> []. diff --git a/lib/inets/src/http_server/mod_esi.erl b/lib/inets/src/http_server/mod_esi.erl index dd6f62a..ec9de66 100644 --- a/lib/inets/src/http_server/mod_esi.erl +++ b/lib/inets/src/http_server/mod_esi.erl @@ -249,6 +249,18 @@ erl(#mod{method = Method} = ModData, ESIBody, Modules) {proceed, [{status,{400, none, BadRequest}} | ModData#mod.data]} end; +erl(#mod{request_uri = ReqUri, method = "PUT", + http_version = Version, data = Data}, _ESIBody, _Modules) -> + {proceed,[{status,{501,{"PUT", ReqUri, Version}, + ?NICE("Erl mechanism doesn't support method PUT")}}| + Data]}; + +erl(#mod{request_uri = ReqUri, method = "DELETE", + http_version = Version, data = Data}, _ESIBody, _Modules) -> + {proceed,[{status,{501,{"DELETE", ReqUri, Version}, + ?NICE("Erl mechanism doesn't support method DELETE")}}| + Data]}; + erl(#mod{method = "POST", entity_body = Body} = ModData, ESIBody, Modules) -> case httpd_util:split(ESIBody,":|%3A|/",2) of {ok,[ModuleName, Function]} -> @@ -450,6 +462,18 @@ eval(#mod{request_uri = ReqUri, method = "POST", ?NICE("Eval mechanism doesn't support method POST")}}| Data]}; +eval(#mod{request_uri = ReqUri, method = "PUT", + http_version = Version, data = Data}, _ESIBody, _Modules) -> + {proceed,[{status,{501,{"PUT", ReqUri, Version}, + ?NICE("Eval mechanism doesn't support method PUT")}}| + Data]}; + +eval(#mod{request_uri = ReqUri, method = "DELETE", + http_version = Version, data = Data}, _ESIBody, _Modules) -> + {proceed,[{status,{501,{"DELETE", ReqUri, Version}, + ?NICE("Eval mechanism doesn't support method DELETE")}}| + Data]}; + eval(#mod{method = Method} = ModData, ESIBody, Modules) when Method == "GET"; Method == "HEAD" -> case is_authorized(ESIBody, Modules) of -- From vychodil.hynek@REDACTED Mon Jul 6 14:46:52 2009 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Mon, 6 Jul 2009 14:46:52 +0200 Subject: [erlang-bugs] Bad argument when open_port with spawn_executable In-Reply-To: References: <4d08db370907060348m266463f0hb79cf65a80a4b184@mail.gmail.com> Message-ID: <4d08db370907060546x255766e4u5856066c5804b4d2@mail.gmail.com> Yes, it is reason: Erlang R13B (erts-5.7.1) I did not checked mine local documentation and did not suspect change in minor release. Sorry for inconvenience. On Mon, Jul 6, 2009 at 1:25 PM, Kenneth Lundin wrote: > The spawn_executable variant of erlang:open_port was introduced in R13B01. > The error you get indicates that you are running on an older version > of Erlang/OTP. > The bad argument refers to {spawn_exectable,_} which is not supported > before R13B01. > > /Kenneth Erlang/OTP, Ericsson > > On Mon, Jul 6, 2009 at 12:48 PM, Hynek Vychodil > wrote: > > Hello, > > according to documentation I'm trying use spawn_executable argument to > > open_port/2. It seems there is a bug or I missed something? > > > > 13> open_port({spawn_executable, os:find_executable("perl")}, []). > > ** exception error: bad argument > > in function open_port/2 > > called as open_port({spawn_executable,"/usr/bin/perl"},[]) > > > > I obtain same result for wide variety of PortSettings which seems not > > affecting it. > > > > Best regards > > > > -- > > --Hynek (Pichi) Vychodil > > > > Analyze your data in minutes. Share your insights instantly. Thrill your > > boss. Be a data hero! > > Try Good Data now for free: www.gooddata.com > > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try Good Data now for free: www.gooddata.com From mjtruog@REDACTED Tue Jul 7 05:28:26 2009 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 06 Jul 2009 20:28:26 -0700 Subject: [erlang-bugs] node type in documentation or API? In-Reply-To: <20090706100234.GB4401@erix.ericsson.se> References: <4A4D4DF3.9060202@gmail.com> <20090706100234.GB4401@erix.ericsson.se> Message-ID: <4A52C0DA.60302@gmail.com> Raimo Niskanen wrote: > On Thu, Jul 02, 2009 at 05:16:51PM -0700, Michael Truog wrote: > >> The documentation is a little ambiguous when it mentions the node type >> since it uses "node()" instead of "atom()", and this may be on purpose. >> If this is on purpose it would be really nice to have a function >> "erlang:is_node(Node)" for guard tests. Otherwise, if I put >> "erlang:is_atom(Node)" in the guard tests, I am making the assumption >> that node types are always atoms. I don't know if that is always >> suppose to be the case since the documentation uses a separate type. >> >> Thanks, >> Michael Truog >> > > That is a beautiful thought, but very hard to do. > > The documentation uses node() for clairty. > > We could introduce is_node/1, but making a node a separate > type in the emulator would break lots of existing code. > So we would have to warn several release before, and those > customers that have large (millions of lines of code) > applications in maintenance would most probably refuse > such an update, forcing us into two release tracks > for the lifetime of their products. > > The semantics of is_node/1 must also be decided. > Will it return true for existing nodes, existing > and old nodes, or existing and old and possible > future nodes. > > It is very unlikely this will ever happen. > I was hoping for something less drastic. As I understand it, it is good coding practice to use guards for all types in the function, so errors are easier to catch and code is easier to optimize (excluding something like length which could be considered a performance drain). So, it seems like it would be nice to have is_node/1 which could just be an alias for is_atom/1 now, if that is always valid. I can totally understand how checking a node's state is complex and having a separate type is complex. It just seems like all Erlang native types should have associated guards for consistencies sake. I understand why guards for things like dict or ordict might not make sense (being separate modules in the stdlib). Thanks for considering this, Michael From bgustavsson@REDACTED Wed Jul 8 15:31:52 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 8 Jul 2009 15:31:52 +0200 Subject: [erlang-bugs] Core Erlang compilation problem In-Reply-To: <4A1662A2.90203@fi.upm.es> References: <4A156983.6050604@fi.upm.es> <4A1662A2.90203@fi.upm.es> Message-ID: <6672d0160907080631m37b85e78ha355df22323f4c76@mail.gmail.com> On Fri, May 22, 2009 at 10:30 AM, Lars-?ke Fredlund wrote: > Lars-?ke Fredlund wrote: >> >> The attached Core Erlang module causes the compiler to crash: >> [...] >> >> but core_lint also complains: >> >> 2> compile:file("test.core",[return_errors, from_core, clint]). >> {error,[{test,[{core_lint,{illegal_guard,{stop_mp,2}}}]}], >> [{"no_file",[{none,sys_core_fold,result_ignored}]}]} >> >> Probably it is just a stupid oversight on my part, but I cannot see why >> the code is not ok. Simply removing the second case clause, for instance, >> causes the compilation to work? It is far from obvious, but the problem is the following case statement case <> of <> when call 'erlang':'is_record'(S,'t',14) -> let <_cor6> = call 'erlang':'element'(7, S) in 'true' end which is illegal Core Erlang code, because there *must* always be a clause that will be executed (a case statement in Core Erlang is not allowed to fall through). The Core Erlang optimizer (sys_core_fold) assumes that it is passed correct code, and it knows that if a case only has one clause, it *must* match, and therefore the entire case can be reduced to let <_cor6> = call 'erlang':'element'(7, S) in 'true' That is further optimized to do call 'erlang':'element'(7, S) 'true' This sequence is inside a guard, and currently the code generator correctly does not handle a call to BIF when the return value is ignored in a guard. It's low priority for me to fix that problem, since it cannot happen (AFAIK) when compiling an Erlang module. I suggest that you add a default clause to the end of the case to take care of the case that S is not a record of the correct type. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Thu Jul 9 08:29:57 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 9 Jul 2009 08:29:57 +0200 Subject: sctp tsn In-Reply-To: <20090611095316.GA2195@erix.ericsson.se> References: <20090611095316.GA2195@erix.ericsson.se> Message-ID: <20090709062957.GA31175@erix.ericsson.se> It seems the answer missed the list the first time... On Thu, Jun 11, 2009 at 11:53:17AM +0200, Raimo Niskanen wrote: > On Thu, Jun 04, 2009 at 10:44:58PM -0500, Anders Nygren wrote: > > Hi > > In the sctp_sndrcvinfo record when receiving data with SCTP the tsn is signed. > > But RFC 2960 ch. 1.5 says that TSN is unsigned. > > > > Thank you. It was fixed in R13B01, just in time... > > > /Anders > > > > ________________________________________________________________ > > erlang-bugs mailing list. See http://www.erlang.org/faq.html > > erlang-bugs (at) erlang.org > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From lfredlund@REDACTED Thu Jul 9 14:21:50 2009 From: lfredlund@REDACTED (=?ISO-8859-1?Q?Lars-=C5ke_Fredlund?=) Date: Thu, 09 Jul 2009 14:21:50 +0200 Subject: [erlang-bugs] Core Erlang compilation problem In-Reply-To: <6672d0160907080631m37b85e78ha355df22323f4c76@mail.gmail.com> References: <4A156983.6050604@fi.upm.es> <4A1662A2.90203@fi.upm.es> <6672d0160907080631m37b85e78ha355df22323f4c76@mail.gmail.com> Message-ID: <4A55E0DE.5070803@fi.upm.es> Bjorn Gustavsson wrote: > On Fri, May 22, 2009 at 10:30 AM, Lars-?ke Fredlund wrote: > >> Lars-?ke Fredlund wrote: >> >>> The attached Core Erlang module causes the compiler to crash: >>> >>> > [...] > >>> but core_lint also complains: >>> >>> 2> compile:file("test.core",[return_errors, from_core, clint]). >>> {error,[{test,[{core_lint,{illegal_guard,{stop_mp,2}}}]}], >>> [{"no_file",[{none,sys_core_fold,result_ignored}]}]} >>> >>> Probably it is just a stupid oversight on my part, but I cannot see why >>> the code is not ok. Simply removing the second case clause, for instance, >>> causes the compilation to work? >>> > > It is far from obvious, but the problem is the following case statement > > case <> of > <> when > call 'erlang':'is_record'(S,'t',14) -> > let <_cor6> = call 'erlang':'element'(7, S) in 'true' > end > > which is illegal Core Erlang code, because there *must* always be a > clause that will be executed (a case statement in Core Erlang is not > allowed to fall through). The Core Erlang optimizer (sys_core_fold) > assumes that it is passed correct code, and it knows that if a case > only has one clause, it *must* match, and therefore the entire case > can be reduced to > > let <_cor6> = call 'erlang':'element'(7, S) in 'true' > > That is further optimized to > > do call 'erlang':'element'(7, S) > 'true' > > This sequence is inside a guard, and currently the code generator > correctly does not handle a call to BIF when the return value is > ignored in a guard. It's low priority for me to fix that problem, > since it cannot happen (AFAIK) when compiling an Erlang module. > > I suggest that you add a default clause to the end of the case to take > care of the case that S is not a record of the correct type. > > /Bjorn > > Ahh. I had forgot that cases must always have matching clauses. Nice problem analysis too. I will change the way the code is generated following your suggestion. Thanks, Lars-Ake From jon@REDACTED Thu Jul 9 22:53:01 2009 From: jon@REDACTED (Jon Meredith) Date: Thu, 9 Jul 2009 14:53:01 -0600 Subject: Possible bug in HiPE pattern matching Message-ID: <877FEB4B-A358-4C41-B831-21B61D5CE101@jonmeredith.com> Hi all, I think I've discovered an issue with pattern matching under HiPE going back on at least 5.6.3 under Debian/lenny and 5.7.2 under OS X Here is a module that demonstrates the issue -module(bug). -export([f/1,g/1]). f(0) -> zero; f(-10) -> one; f(-20) -> two; f(-30) -> three; f(-40) -> four; f(-50) -> five; f(-60) -> six; f(-70) -> seven; f(-80) -> eight; %% Uncomment this line to make it work with HiPE f(X) -> {error, X}. g(X) -> case X of 0 -> zero; -10 -> one; -20 -> two; -30 -> three; -40 -> four; -50 -> five; -60 -> six; -70 -> seven; -80 -> eight; %% Uncomment this line to make it work with HiPE X -> {error, X} end. Running normally without HiPE it does what I expect jmeredith@REDACTED:~$ /usr/bin/erlc bug.erl jmeredith@REDACTED:~$ /usr/bin/erl Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.3 (abort with ^G) 1> bug:f(0). zero 2> bug:g(0). zero If I compile with +native, the pattern doesn't match the first case as it should jmeredith@REDACTED:~$ /usr/bin/erlc +native bug.erl jmeredith@REDACTED:~$ /usr/bin/erl Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.3 (abort with ^G) 1> bug:f(0). {error,0} 2> bug:g(0). {error,0} If I remove the commented lines above it works correctly. Is there something I don't understand about HiPE? Many thanks, Jon From mikpe@REDACTED Fri Jul 10 01:44:59 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 10 Jul 2009 01:44:59 +0200 Subject: [erlang-bugs] Possible bug in HiPE pattern matching In-Reply-To: <877FEB4B-A358-4C41-B831-21B61D5CE101@jonmeredith.com> References: <877FEB4B-A358-4C41-B831-21B61D5CE101@jonmeredith.com> Message-ID: <19030.33019.386108.973565@pilspetsen.it.uu.se> Jon Meredith writes: > Hi all, > > I think I've discovered an issue with pattern matching under HiPE > going back on at least 5.6.3 under Debian/lenny and 5.7.2 under OS X > > Here is a module that demonstrates the issue > > -module(bug). > -export([f/1,g/1]). > f(0) -> zero; > f(-10) -> one; > f(-20) -> two; > f(-30) -> three; > f(-40) -> four; > f(-50) -> five; > f(-60) -> six; > f(-70) -> seven; > f(-80) -> eight; %% Uncomment this line to make it work with HiPE > f(X) -> {error, X}. > > g(X) -> > case X of > 0 -> zero; > -10 -> one; > -20 -> two; > -30 -> three; > -40 -> four; > -50 -> five; > -60 -> six; > -70 -> seven; > -80 -> eight; %% Uncomment this line to make it work with HiPE > X -> {error, X} > end. > > Running normally without HiPE it does what I expect > > jmeredith@REDACTED:~$ /usr/bin/erlc bug.erl > jmeredith@REDACTED:~$ /usr/bin/erl > Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.3 (abort with ^G) > 1> bug:f(0). > zero > 2> bug:g(0). > zero > > If I compile with +native, the pattern doesn't match the first case as > it should > > jmeredith@REDACTED:~$ /usr/bin/erlc +native bug.erl > jmeredith@REDACTED:~$ /usr/bin/erl > Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.3 (abort with ^G) > 1> bug:f(0). > {error,0} > 2> bug:g(0). > {error,0} Confirmed on i686, x86-64, and powerpc, so it looks like a middle-end (Icode or RTL) rather than a backend bug. Someone, likely me or Kostis, will take a look at it. > Is there > something I don't understand about HiPE? Bugs happen, that's all. Thanks for reporting this problem. /Mikael From zerthurd@REDACTED Fri Jul 10 09:33:18 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 10 Jul 2009 14:33:18 +0700 Subject: [erlang-bugs] ASN.1 encoder does not check constraint Message-ID: Hello I found situation when ASN.1 runtime encoder does not check constraint: The Number defined in StructA.asn as: Number ::= OCTET STRING (SIZE(minNumberLength..maxNumberLength)) minNumberLength INTEGER ::= 1 maxNumberLength INTEGER ::= 5 Then in StructB.asn Number is imported, and used as: Data ::= SEQUENCE { version [0] INTEGER, number [1] Number } So, after compilation of this two asn-files we have encoder module for StructB, but this encoder does not check Number size constraint: 1> 'StructB':encode('Data', {'Data', 1, "34"}). {ok,[48,7,128,1,1,129,2,51,52]} 2> 'StructB':encode('Data', {'Data', 1, ""}). {ok,[48,5,128,1,1,129,0]} 3> 'StructB':encode('Data', {'Data', 1, "3444455555554"}). {ok,[48,18,128,1,1,129,13,51,52,52,52,52,53,53,53,53,53,53, 53,52]} Thank you -- Maxim Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StructA.asn Type: chemical/x-ncbi-asn1 Size: 179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StructB.asn Type: chemical/x-ncbi-asn1 Size: 156 bytes Desc: not available URL: From mikpe@REDACTED Fri Jul 10 23:02:48 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 10 Jul 2009 23:02:48 +0200 Subject: [erlang-bugs] Possible bug in HiPE pattern matching In-Reply-To: <877FEB4B-A358-4C41-B831-21B61D5CE101@jonmeredith.com> References: <877FEB4B-A358-4C41-B831-21B61D5CE101@jonmeredith.com> Message-ID: <19031.44152.794781.272170@pilspetsen.it.uu.se> Jon Meredith writes: > Hi all, > > I think I've discovered an issue with pattern matching under HiPE > going back on at least 5.6.3 under Debian/lenny and 5.7.2 under OS X > > Here is a module that demonstrates the issue > > -module(bug). > -export([f/1,g/1]). > f(0) -> zero; > f(-10) -> one; > f(-20) -> two; > f(-30) -> three; > f(-40) -> four; > f(-50) -> five; > f(-60) -> six; > f(-70) -> seven; > f(-80) -> eight; %% Uncomment this line to make it work with HiPE > f(X) -> {error, X}. > > g(X) -> > case X of > 0 -> zero; > -10 -> one; > -20 -> two; > -30 -> three; > -40 -> four; > -50 -> five; > -60 -> six; > -70 -> seven; > -80 -> eight; %% Uncomment this line to make it work with HiPE > X -> {error, X} > end. > > Running normally without HiPE it does what I expect > > jmeredith@REDACTED:~$ /usr/bin/erlc bug.erl > jmeredith@REDACTED:~$ /usr/bin/erl > Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.3 (abort with ^G) > 1> bug:f(0). > zero > 2> bug:g(0). > zero > > If I compile with +native, the pattern doesn't match the first case as > it should > > jmeredith@REDACTED:~$ /usr/bin/erlc +native bug.erl > jmeredith@REDACTED:~$ /usr/bin/erl > Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.3 (abort with ^G) > 1> bug:f(0). > {error,0} > 2> bug:g(0). > {error,0} This turned out to be a long-standing bug that only triggers for largish but sparse cases on negative small integers, where the generated search code did not account for key table transformations done at load-time (to facilitate binary searches on atoms). The fix is included below. Thanks for reporting the problem and for providing such a good (small) test case. /Mikael --- otp-0710/lib/hipe/rtl/hipe_rtl_mk_switch.erl.~1~ 2009-03-18 21:56:34.000000000 +0100 +++ otp-0710/lib/hipe/rtl/hipe_rtl_mk_switch.erl 2009-07-10 13:49:11.000000000 +0200 @@ -880,7 +880,7 @@ tab(KeyList, LabelList, KeyReg, TablePnt [ hipe_rtl:mk_move(IndexReg,hipe_rtl:mk_imm(0)), hipe_rtl:mk_load(Temp,TablePntrReg,hipe_rtl:mk_imm(Init)), - hipe_rtl:mk_branch(Temp, ge, KeyReg, + hipe_rtl:mk_branch(Temp, geu, KeyReg, hipe_rtl:label_name(Lab2), hipe_rtl:label_name(Lab1), 0.5), Lab1, @@ -911,7 +911,7 @@ step(I,TablePntrReg,IndexReg,KeyReg) -> Lab2 = hipe_rtl:mk_new_label(), [hipe_rtl:mk_alu(TempIndex, IndexReg, add, hipe_rtl:mk_imm(I)), hipe_rtl:mk_load(Temp,TablePntrReg,TempIndex), - hipe_rtl:mk_branch(Temp, gt, KeyReg, + hipe_rtl:mk_branch(Temp, gtu, KeyReg, hipe_rtl:label_name(Lab2), hipe_rtl:label_name(Lab1) , 0.5), Lab1] ++ From kenji.rikitake@REDACTED Sun Jul 12 04:56:46 2009 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 12 Jul 2009 11:56:46 +0900 Subject: Erlang R13B01 ssh-1.1.3 cipher key matching bug and documentation errors Message-ID: <20090712025646.GA44385@k2r.org> Here's a list of bugs/documentation errors of ssh-1.1.3 for R13B01 which I experienced yesterday. * [bug] ssh:shell/3 and ssh:connect/3 do not crash immediately even if they fail to negotiate the cipher to use, and hang forever How to reproduce: set NOT to accept 3des-cbc as a cipher on the server (in OpenSSH, set Ciphers directive at sshd_config, *excluding* 3des-cbc) Possible reason: failure of finding a matching cipher does not throw an exception immediately (I haven't tested yet). FYI: on Portable OpenSSH 5.1 for FreeBSD slogin client, it will turn out to be something like the following: -- quote -- debug1: match: OpenSSH_5.1p1 FreeBSD-20080901 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received no matching cipher found: client 3des-cbc server aes128-ctr,blowfish-cbc,aes128-cbc,aes192-cbc,aes256-cbc -- unquote -- * [documentation error] ssh manual should include that the current ssh module only supports the following crypto parameters of SSH Version 2 protocol: (my opinion follows later in this message) cipher: 3des-cbc only MACs: hmac-sha1 only * [documentation error] ssh manual should include that only an *unencrypted* private key is supported for ssh_rsa public key authentication. The manual should also note that private keys for public key authentication used for interactive logins are mostly encrypted so cannot be used for the time being. * [documentation error] ssh:connect/1 and ssh:connect/2 no longer exist, but still documented. Description for those old functions should be eliminated, and requirement to use ssh:connect/3 instead should be described. * [my opinion] I personally think only supporting 3des-cbc is *archaic* and insufficient; implementing at least stronger ciphers such as aes128-cbc and aes256-cbc, or even blowfish-cbc, should be considered ASAP, regarding the strength of the ciphers. Regards, Kenji Rikitake From nick@REDACTED Tue Jul 14 11:12:57 2009 From: nick@REDACTED (Niclas Eklund) Date: Tue, 14 Jul 2009 11:12:57 +0200 (CEST) Subject: [erlang-bugs] ASN.1 encoder does not check constraint In-Reply-To: References: Message-ID: Hello! Thanks for reporting this! /Niclas @ Erlang/OTP On Fri, 10 Jul 2009, Maxim Treskin wrote: > Hello > I found situation when ASN.1 runtime encoder does not check constraint: > > The Number defined in StructA.asn as: > > Number ::= OCTET STRING (SIZE(minNumberLength..maxNumberLength)) > minNumberLength INTEGER ::= 1 > maxNumberLength INTEGER ::= 5 > > > Then in StructB.asn Number is imported, and used as: > > Data ::= SEQUENCE > { > version [0] INTEGER, > number [1] Number > } > > So, after compilation of this two asn-files we have encoder module for > StructB, but this encoder does not check Number size constraint: > > 1> 'StructB':encode('Data', {'Data', 1, "34"}). > {ok,[48,7,128,1,1,129,2,51,52]} > 2> 'StructB':encode('Data', {'Data', 1, ""}). > {ok,[48,5,128,1,1,129,0]} > 3> 'StructB':encode('Data', {'Data', 1, "3444455555554"}). > {ok,[48,18,128,1,1,129,13,51,52,52,52,52,53,53,53,53,53,53, 53,52]} > > > Thank you > > -- > Maxim Treskin > From kenji.rikitake@REDACTED Wed Jul 15 03:47:54 2009 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 15 Jul 2009 10:47:54 +0900 Subject: [erlang-bugs] Erlang R13B01 ssh-1.1.3 cipher key matching bug and documentation errors In-Reply-To: <20090712025646.GA44385@k2r.org> References: <20090712025646.GA44385@k2r.org> Message-ID: <20090715014754.GA9277@k2r.org> Justin Sheehy told me on Twitter that Erlang crypto module already supports AES, and I confirmed related functions in crypto.erl, so I guess it's a matter of ssh module implementation. FYI Kenji Rikitake In the message <20090712025646.GA44385@REDACTED> dated Sun, Jul 12, 2009 at 11:56:22AM +0900, Kenji Rikitake writes: > * [my opinion] I personally think only supporting 3des-cbc is *archaic* > and insufficient; implementing at least stronger ciphers such as > aes128-cbc and aes256-cbc, or even blowfish-cbc, should be considered > ASAP, regarding the strength of the ciphers. From paul-trapexit@REDACTED Fri Jul 17 21:37:18 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Fri, 17 Jul 2009 12:37:18 -0700 (PDT) Subject: re type spec problem (not recognizing { capture, none }) Message-ID: the module documentation doesn't list { capture, none } as a possibility in the types section (but refers to it in the function description), so i perhaps this is not dialyzer's fault (GIGO?). easy workaround: specify { capture, [] } instead of { capture, none }. cheers, -- p ------- -module (diabug). -export ([f/0]). f () -> re:run ("yo", "yo", [ { capture, none } ]). ------- % erl Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [kernel-poll:false] Eshell V5.6.5 (abort with ^G) 1> c (diabug), diabug:f (). match 2> User switch command --> q % dialyzer --src -c diabug.erl Checking whether the PLT /home/pmineiro/.dialyzer_plt is up-to-date... yes Proceeding with analysis... diabug.erl:4: Function f/0 has no local return diabug.erl:5: The call re:run("yo","yo",[{'capture','none'},...]) will never return since it differs in argument position 3 from the success typing arguments: (binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []),binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []) | {'re_pattern',integer(),integer(),binary()},[atom() | {'capture','all' | 'all_but_first' | 'first' | [atom() | string() | integer()]} | {'newline','anycrlf' | 'cr' | 'crlf' | 'lf'} | {'offset',integer()} | {'capture','all' | 'all_but_first' | 'first' | [atom() | string() | integer()],'binary' | 'index' | 'list'}]) done in 0m0.22s done (warnings were emitted) From stonecypher@REDACTED Mon Jul 20 02:41:13 2009 From: stonecypher@REDACTED (John Haugeland) Date: Sun, 19 Jul 2009 18:41:13 -0600 Subject: Possible documentation error? Message-ID: <8f24f4b10907191741o712eb05eoecc734e173691043@mail.gmail.com> >From the lists module documentation for ukeysort/2: "Returns a list containing the sorted elements of the list TupleList1 where all but the first tuple of the tuples comparing equal have been deleted." Actual behavior is to make unique on key equality, not on tuple equality. 243> lists:ukeysort(2, [ {1,1}, {2,1}, {2,2} ]). [{1,1},{2,2}] Am I missing something obvious? From sverker@REDACTED Mon Jul 20 11:02:05 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 20 Jul 2009 11:02:05 +0200 Subject: [erlang-bugs] re type spec problem (not recognizing { capture, none }) In-Reply-To: References: Message-ID: <4A64328D.4060204@erix.ericsson.se> Looks like a simple omission. Will be fixed in R13B02. Thanks. /Sverker, Erlang/OTP Paul Mineiro wrote: > the module documentation doesn't list { capture, none } as a possibility > in the types section (but refers to it in the function description), > so i perhaps this is not dialyzer's fault (GIGO?). > > easy workaround: specify { capture, [] } instead of { capture, none }. > > cheers, > > -- p > > ------- > -module (diabug). > -export ([f/0]). > > f () -> > re:run ("yo", "yo", [ { capture, none } ]). > ------- > > % erl > Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [kernel-poll:false] > > Eshell V5.6.5 (abort with ^G) > 1> c (diabug), diabug:f (). > match > 2> > User switch command > --> q > % dialyzer --src -c diabug.erl > Checking whether the PLT /home/pmineiro/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > diabug.erl:4: Function f/0 has no local return > diabug.erl:5: The call re:run("yo","yo",[{'capture','none'},...]) will never return since it differs in argument position 3 from the success typing arguments: (binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []),binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []) | {'re_pattern',integer(),integer(),binary()},[atom() | {'capture','all' | 'all_but_first' | 'first' | [atom() | string() | integer()]} | {'newline','anycrlf' | 'cr' | 'crlf' | 'lf'} | {'offset',integer()} | {'capture','all' | 'all_but_first' | 'first' | [atom() | string() | integer()],'binary' | 'index' | 'list'}]) > done in 0m0.22s > done (warnings were emitted) > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From sverker@REDACTED Tue Jul 21 10:53:43 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 21 Jul 2009 10:53:43 +0200 Subject: [erlang-bugs] re type spec problem (not recognizing { capture, none }) In-Reply-To: <4A64328D.4060204@erix.ericsson.se> References: <4A64328D.4060204@erix.ericsson.se> Message-ID: <4A658217.5070104@erix.ericsson.se> Correction: Option {capture,none} was added to the dialyzer spec in R13A. I will update the documentation for R13B02. /Sverker, Erlang/OTP Sverker Eriksson wrote: > Looks like a simple omission. Will be fixed in R13B02. > > Thanks. > /Sverker, Erlang/OTP > > Paul Mineiro wrote: >> the module documentation doesn't list { capture, none } as a possibility >> in the types section (but refers to it in the function description), >> so i perhaps this is not dialyzer's fault (GIGO?). >> >> easy workaround: specify { capture, [] } instead of { capture, none }. >> >> cheers, >> >> -- p >> >> ------- >> -module (diabug). >> -export ([f/0]). >> >> f () -> >> re:run ("yo", "yo", [ { capture, none } ]). >> ------- >> >> % erl >> Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] >> [kernel-poll:false] >> >> Eshell V5.6.5 (abort with ^G) >> 1> c (diabug), diabug:f (). >> match >> 2> >> User switch command >> --> q >> % dialyzer --src -c diabug.erl >> Checking whether the PLT /home/pmineiro/.dialyzer_plt is >> up-to-date... yes >> Proceeding with analysis... >> diabug.erl:4: Function f/0 has no local return >> diabug.erl:5: The call re:run("yo","yo",[{'capture','none'},...]) >> will never return since it differs in argument position 3 from the >> success typing arguments: (binary() | maybe_improper_list(binary() | >> maybe_improper_list(any(),binary() | []) | byte(),binary() | >> []),binary() | maybe_improper_list(binary() | >> maybe_improper_list(any(),binary() | []) | byte(),binary() | []) | >> {'re_pattern',integer(),integer(),binary()},[atom() | >> {'capture','all' | 'all_but_first' | 'first' | [atom() | string() | >> integer()]} | {'newline','anycrlf' | 'cr' | 'crlf' | 'lf'} | >> {'offset',integer()} | {'capture','all' | 'all_but_first' | 'first' | >> [atom() | string() | integer()],'binary' | 'index' | 'list'}]) >> done in 0m0.22s >> done (warnings were emitted) >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From whongo@REDACTED Tue Jul 21 13:16:26 2009 From: whongo@REDACTED (=?ISO-8859-1?Q?Martin_Engstr=F6m?=) Date: Tue, 21 Jul 2009 13:16:26 +0200 Subject: R13B01 internal error in v3_codegen Message-ID: <28423d490907210416j7e328a98h6a3f9bba935a856@mail.gmail.com> Hi! This small list comprehension works fine in R12B-5, but not in R13B01 -module(alphanum). -export([orgno_alphanum/1]). orgno_alphanum(OrgNo) -> [C || C <- OrgNo, ((C >= $0) andalso (C =< $9)) orelse ((C >= $a) andalso (C =< $z)) orelse ((C >= $A) andalso (C =< $Z))]. Trying to compile: mrtin@REDACTED:~$erlc alphanum.erl Function: '-orgno_alphanum/1-lc$^0/1-0-'/1 ./alphanum.erl:none: internal error in v3_codegen; crash reason: {{case_clause, {'EXIT', {function_clause, [{v3_codegen,longest, [[{0,cor3},{1,ker4},{2,ker3},{3,gbreakvar}], [free,{1,ker4},{2,ker3},{3,gbreakvar}]]}, {v3_codegen,sr_merge,2}, {v3_codegen,match_cg,5}, {v3_codegen,guard_match_cg,6}, {v3_codegen,'-cg_list/5-anonymous-0-',3}, {v3_codegen,flatmapfoldl,3}, {v3_codegen,cg_list,5}, {v3_codegen,cg_block,5}]}}}, [{compile,'-select_passes/2-anonymous-2-',2}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} Erlang version: mrtin@REDACTED:~$erl Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] /Martin Engstr?m From nick@REDACTED Tue Jul 21 13:49:42 2009 From: nick@REDACTED (Niclas Eklund) Date: Tue, 21 Jul 2009 13:49:42 +0200 (CEST) Subject: [erlang-bugs] R13B01 internal error in v3_codegen In-Reply-To: <28423d490907210416j7e328a98h6a3f9bba935a856@mail.gmail.com> References: <28423d490907210416j7e328a98h6a3f9bba935a856@mail.gmail.com> Message-ID: Hello! Thank you for reporting this. We'll have a look at it as soon as possible. Best regards, Niclas @ Erlang/OTP On Tue, 21 Jul 2009, Martin Engstr?m wrote: > Hi! This small list comprehension works fine in R12B-5, but not in R13B01 > > -module(alphanum). > -export([orgno_alphanum/1]). > orgno_alphanum(OrgNo) -> > [C || C <- OrgNo, ((C >= $0) andalso (C =< $9)) > orelse ((C >= $a) andalso (C =< $z)) > orelse ((C >= $A) andalso (C =< $Z))]. > > Trying to compile: > > mrtin@REDACTED:~$erlc alphanum.erl > Function: '-orgno_alphanum/1-lc$^0/1-0-'/1 > ./alphanum.erl:none: internal error in v3_codegen; > crash reason: {{case_clause, > {'EXIT', > {function_clause, > [{v3_codegen,longest, > [[{0,cor3},{1,ker4},{2,ker3},{3,gbreakvar}], > [free,{1,ker4},{2,ker3},{3,gbreakvar}]]}, > {v3_codegen,sr_merge,2}, > {v3_codegen,match_cg,5}, > {v3_codegen,guard_match_cg,6}, > {v3_codegen,'-cg_list/5-anonymous-0-',3}, > {v3_codegen,flatmapfoldl,3}, > {v3_codegen,cg_list,5}, > {v3_codegen,cg_block,5}]}}}, > [{compile,'-select_passes/2-anonymous-2-',2}, > {compile,'-internal_comp/4-anonymous-1-',2}, > {compile,fold_comp,3}, > {compile,internal_comp,4}, > {compile,internal,3}]} > > Erlang version: > > mrtin@REDACTED:~$erl > Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [hipe] [kernel-poll:false] > > /Martin Engstr?m > From prikrutil@REDACTED Tue Jul 21 21:43:51 2009 From: prikrutil@REDACTED (Sergey Samokhin) Date: Tue, 21 Jul 2009 12:43:51 -0700 Subject: Arguments passed to escript's emulator by %%! affect os:cmd/1 Message-ID: Hello. Some weeks ago I sent a bug report describing the problem with passing arguments to escript's emulator by using %%! and os:cmd/1. I used R13B to test it. Today I've tested this with R13B01 - the problem is still here. I reproduced it on Archlinux and FreeBSD. So I decided to write this letter. The easiest way reproduce the problem is by starting this script: %----------------------- #!/usr/bin/env escript %%! -smp disable main(_) -> os:cmd("erl -detached -sname test"). %----------------------- Although there is no "-smp disable" within the argument to os:cmd/1, the newly started node will have smp disabled too. It's impossible to use "%%! " syntax (for example to make an escript's node hidden) because all arguments I specify are passed to a node started by os:cmd/1. Here is the original bug-report with all the details on how to reproduce the bug: http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1296:200905:finpkpaeoenpofkcegce -- Sergey Samokhin From erik@REDACTED Wed Jul 22 18:24:09 2009 From: erik@REDACTED (Erik Rigtorp) Date: Wed, 22 Jul 2009 18:24:09 +0200 Subject: Segmentation fault in the runtime. Message-ID: Hi! I encountered a segfault in the runtime when communicating with it using erl_interface. I suspect what I am sending is malformed, but the runtime shouldn't segfault becasue of that. Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.7.1 Stacktrace: #0 0x080e0a91 in dec_term (dep=0x92294a8, hpp=0xb6355dd4, ep=0xb5548dd6 " N h\005a\004a.d", off_heap=0xb54118cc, objp=0xb6355bec) at beam/external.c:1061 #1 0x080e1fca in erts_from_external_format (dep=0x92294a8, hpp=0xb6355dd4, ext=0xb6355dd8, off_heap=0xb54118cc) at beam/external.c:1036 #2 0x080e4b6c in erts_net_message (prt=0xb7cc3398, dep=0x92294a8, hbuf=0x0, hlen=0, buf=0xb5548cdc "p\203h\003a\002d", len=212) at beam/dist.c:1086 #3 0x080bd444 in driver_output2 (ix=713, hbuf=0xb5548cdc "p\203h\003a\002d", hlen=250, buf=0x0, len=0) at beam/io.c:3262 #4 0x0816f835 in tcp_deliver (desc=0x928bf28, len=254) at drivers/common/inet_drv.c:1915 #5 0x08171f2a in tcp_recv (desc=0x928bf28, request_len=0) at drivers/common/inet_drv.c:8037 #6 0x08172281 in tcp_inet_drv_input (data=0x928bf28, event=0xf) at drivers/common/inet_drv.c:8375 #7 0x080d817b in erts_port_task_execute (runq=0xb7c530e0, curr_port_pp=0xb7c5c628) at beam/erl_port_task.c:852 #8 0x080d10ed in schedule (p=0xb541167c, calls=7) at beam/erl_process.c:5429 #9 0x08132fce in process_main () at beam/beam_emu.c:1155 #10 0x080c68d8 in sched_thread_func (vesdp=0xb7c595f8) at beam/erl_process.c:2933 #11 0x0819a702 in thr_wrapper (vtwd=0xbfb58aac) at common/ethread.c:475 #12 0xb7fb44ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xb7f2649e in clone () from /lib/tls/i686/cmov/libc.so.6 The data at the pointer buf=0xb5548cdc, len=212 for stackframe #2: 00000000 70 83 68 03 61 02 64 00 00 67 64 00 10 78 78 78 |p.h.a.d..gd..xxx| 00000010 78 78 78 40 6c 6f 63 61 6c 68 6f 73 74 00 00 00 |xxx@REDACTED| 00000020 d5 00 00 00 00 03 83 68 03 64 00 16 78 78 78 78 |.......h.d..xxxx| 00000030 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 |xxxxxxxxxxxxxxxx| 00000040 78 78 6c ff ff ff ff 68 02 64 00 0f 78 78 78 78 |xxl....h.d..xxxx| 00000050 78 78 78 78 78 78 78 78 78 78 78 68 03 62 00 00 |xxxxxxxxxxxh.b..| 00000060 04 e0 62 00 04 30 4c 62 00 04 5d 49 68 03 62 00 |..b..0Lb..]Ih.b.| 00000070 00 04 e0 62 00 04 30 4c 62 00 04 5d 20 6c 00 00 |...b..0Lb..] l..| 00000080 00 02 68 03 6c 00 00 00 01 68 05 61 05 61 2d 64 |..h.l....h.a.a-d| 00000090 00 04 73 65 6c 6c 63 39 2e 35 35 30 30 30 30 30 |..sellc9.5500000| 000000a0 30 30 30 30 30 30 30 30 30 30 30 30 30 65 2b 30 |0000000000000e+0| 000000b0 31 00 00 00 00 00 62 00 00 10 68 6a 6a 6a 68 03 |1.....b...hjjjh.| 000000c0 6c 00 00 00 01 68 05 61 06 61 2e 64 00 03 62 75 |l....h.a.a.d..bu| 000000d0 79 63 38 2e |yc8.| 000000d4 Sorry I can't provide code or core dumps. I can provide more memory dumps if needed. Erik Rigtorp From sverker@REDACTED Wed Jul 22 20:16:21 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 22 Jul 2009 20:16:21 +0200 Subject: [erlang-bugs] Segmentation fault in the runtime. In-Reply-To: References: Message-ID: <4A675775.3040207@erix.ericsson.se> Could be a symptom of OTP-7898, fixed in R13B01. OTP-7898 Fixed a bug that caused error logging from driver_select sometimes with additional symptoms such as failing IP communications or even an emulator crash. You could try to print the value of variable "drv_ev_state_len". If it is smaller than 256 then it can not be OTP-7898. There are however two variables called "drv_ev_state_len". One should be 0 and the other have a value larger than 128. For me, gdb picks the right one (>128) when I run without kernel-poll (erl +K false). /Sverker, Erlang/OTP Erik Rigtorp wrote: > Hi! > > I encountered a segfault in the runtime when communicating with it > using erl_interface. I suspect what I am sending is malformed, but the > runtime shouldn't segfault becasue of that. > > Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.7.1 > > Stacktrace: > #0 0x080e0a91 in dec_term (dep=0x92294a8, hpp=0xb6355dd4, > ep=0xb5548dd6 " N h\005a\004a.d", off_heap=0xb54118cc, > objp=0xb6355bec) at beam/external.c:1061 > #1 0x080e1fca in erts_from_external_format (dep=0x92294a8, > hpp=0xb6355dd4, ext=0xb6355dd8, off_heap=0xb54118cc) > at beam/external.c:1036 > #2 0x080e4b6c in erts_net_message (prt=0xb7cc3398, dep=0x92294a8, > hbuf=0x0, hlen=0, > buf=0xb5548cdc "p\203h\003a\002d", len=212) at beam/dist.c:1086 > #3 0x080bd444 in driver_output2 (ix=713, hbuf=0xb5548cdc > "p\203h\003a\002d", hlen=250, buf=0x0, len=0) > at beam/io.c:3262 > #4 0x0816f835 in tcp_deliver (desc=0x928bf28, len=254) at > drivers/common/inet_drv.c:1915 > #5 0x08171f2a in tcp_recv (desc=0x928bf28, request_len=0) at > drivers/common/inet_drv.c:8037 > #6 0x08172281 in tcp_inet_drv_input (data=0x928bf28, event=0xf) at > drivers/common/inet_drv.c:8375 > #7 0x080d817b in erts_port_task_execute (runq=0xb7c530e0, > curr_port_pp=0xb7c5c628) at beam/erl_port_task.c:852 > #8 0x080d10ed in schedule (p=0xb541167c, calls=7) at beam/erl_process.c:5429 > #9 0x08132fce in process_main () at beam/beam_emu.c:1155 > #10 0x080c68d8 in sched_thread_func (vesdp=0xb7c595f8) at > beam/erl_process.c:2933 > #11 0x0819a702 in thr_wrapper (vtwd=0xbfb58aac) at common/ethread.c:475 > #12 0xb7fb44ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #13 0xb7f2649e in clone () from /lib/tls/i686/cmov/libc.so.6 > > The data at the pointer buf=0xb5548cdc, len=212 for stackframe #2: > 00000000 70 83 68 03 61 02 64 00 00 67 64 00 10 78 78 78 |p.h.a.d..gd..xxx| > 00000010 78 78 78 40 6c 6f 63 61 6c 68 6f 73 74 00 00 00 |xxx@REDACTED| > 00000020 d5 00 00 00 00 03 83 68 03 64 00 16 78 78 78 78 |.......h.d..xxxx| > 00000030 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 |xxxxxxxxxxxxxxxx| > 00000040 78 78 6c ff ff ff ff 68 02 64 00 0f 78 78 78 78 |xxl....h.d..xxxx| > 00000050 78 78 78 78 78 78 78 78 78 78 78 68 03 62 00 00 |xxxxxxxxxxxh.b..| > 00000060 04 e0 62 00 04 30 4c 62 00 04 5d 49 68 03 62 00 |..b..0Lb..]Ih.b.| > 00000070 00 04 e0 62 00 04 30 4c 62 00 04 5d 20 6c 00 00 |...b..0Lb..] l..| > 00000080 00 02 68 03 6c 00 00 00 01 68 05 61 05 61 2d 64 |..h.l....h.a.a-d| > 00000090 00 04 73 65 6c 6c 63 39 2e 35 35 30 30 30 30 30 |..sellc9.5500000| > 000000a0 30 30 30 30 30 30 30 30 30 30 30 30 30 65 2b 30 |0000000000000e+0| > 000000b0 31 00 00 00 00 00 62 00 00 10 68 6a 6a 6a 68 03 |1.....b...hjjjh.| > 000000c0 6c 00 00 00 01 68 05 61 06 61 2e 64 00 03 62 75 |l....h.a.a.d..bu| > 000000d0 79 63 38 2e |yc8.| > 000000d4 > > > Sorry I can't provide code or core dumps. I can provide more memory > dumps if needed. > > Erik Rigtorp > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From erik@REDACTED Thu Jul 23 11:20:06 2009 From: erik@REDACTED (Erik Rigtorp) Date: Thu, 23 Jul 2009 11:20:06 +0200 Subject: [erlang-bugs] Segmentation fault in the runtime. In-Reply-To: <4A675775.3040207@erix.ericsson.se> References: <4A675775.3040207@erix.ericsson.se> Message-ID: I can confirm that this bug exists also in R13B01. On Wed, Jul 22, 2009 at 20:16, Sverker Eriksson wrote: > Could be a symptom of OTP-7898, fixed in R13B01. > > OTP-7898 ?Fixed a bug that caused error logging from driver_select > ? ? ? ? ? ? ?sometimes with additional symptoms such as failing IP > ? ? ? ? ? ? ?communications or even an emulator crash. > > You could try to print the value of variable "drv_ev_state_len". If it is > smaller than 256 then it can not be OTP-7898. There are however two > variables called "drv_ev_state_len". One should be 0 and the other have a > value larger than 128. For me, gdb picks the right one (>128) when I run > without kernel-poll (erl +K false). > > /Sverker, Erlang/OTP > > > Erik Rigtorp wrote: >> >> Hi! >> >> I encountered a segfault in the runtime when communicating with it >> using erl_interface. I suspect what I am sending is malformed, but the >> runtime shouldn't segfault becasue of that. >> >> Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.7.1 >> >> Stacktrace: >> #0 ?0x080e0a91 in dec_term (dep=0x92294a8, hpp=0xb6355dd4, >> ep=0xb5548dd6 " N h\005a\004a.d", off_heap=0xb54118cc, >> ? ?objp=0xb6355bec) at beam/external.c:1061 >> #1 ?0x080e1fca in erts_from_external_format (dep=0x92294a8, >> hpp=0xb6355dd4, ext=0xb6355dd8, off_heap=0xb54118cc) >> ? ?at beam/external.c:1036 >> #2 ?0x080e4b6c in erts_net_message (prt=0xb7cc3398, dep=0x92294a8, >> hbuf=0x0, hlen=0, >> ? ?buf=0xb5548cdc "p\203h\003a\002d", len=212) at beam/dist.c:1086 >> #3 ?0x080bd444 in driver_output2 (ix=713, hbuf=0xb5548cdc >> "p\203h\003a\002d", hlen=250, buf=0x0, len=0) >> ? ?at beam/io.c:3262 >> #4 ?0x0816f835 in tcp_deliver (desc=0x928bf28, len=254) at >> drivers/common/inet_drv.c:1915 >> #5 ?0x08171f2a in tcp_recv (desc=0x928bf28, request_len=0) at >> drivers/common/inet_drv.c:8037 >> #6 ?0x08172281 in tcp_inet_drv_input (data=0x928bf28, event=0xf) at >> drivers/common/inet_drv.c:8375 >> #7 ?0x080d817b in erts_port_task_execute (runq=0xb7c530e0, >> curr_port_pp=0xb7c5c628) at beam/erl_port_task.c:852 >> #8 ?0x080d10ed in schedule (p=0xb541167c, calls=7) at >> beam/erl_process.c:5429 >> #9 ?0x08132fce in process_main () at beam/beam_emu.c:1155 >> #10 0x080c68d8 in sched_thread_func (vesdp=0xb7c595f8) at >> beam/erl_process.c:2933 >> #11 0x0819a702 in thr_wrapper (vtwd=0xbfb58aac) at common/ethread.c:475 >> #12 0xb7fb44ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 >> #13 0xb7f2649e in clone () from /lib/tls/i686/cmov/libc.so.6 >> >> The data at the pointer buf=0xb5548cdc, len=212 for stackframe #2: >> 00000000 ?70 83 68 03 61 02 64 00 ?00 67 64 00 10 78 78 78 >> ?|p.h.a.d..gd..xxx| >> 00000010 ?78 78 78 40 6c 6f 63 61 ?6c 68 6f 73 74 00 00 00 >> ?|xxx@REDACTED| >> 00000020 ?d5 00 00 00 00 03 83 68 ?03 64 00 16 78 78 78 78 >> ?|.......h.d..xxxx| >> 00000030 ?78 78 78 78 78 78 78 78 ?78 78 78 78 78 78 78 78 >> ?|xxxxxxxxxxxxxxxx| >> 00000040 ?78 78 6c ff ff ff ff 68 ?02 64 00 0f 78 78 78 78 >> ?|xxl....h.d..xxxx| >> 00000050 ?78 78 78 78 78 78 78 78 ?78 78 78 68 03 62 00 00 >> ?|xxxxxxxxxxxh.b..| >> 00000060 ?04 e0 62 00 04 30 4c 62 ?00 04 5d 49 68 03 62 00 >> ?|..b..0Lb..]Ih.b.| >> 00000070 ?00 04 e0 62 00 04 30 4c ?62 00 04 5d 20 6c 00 00 ?|...b..0Lb..] >> l..| >> 00000080 ?00 02 68 03 6c 00 00 00 ?01 68 05 61 05 61 2d 64 >> ?|..h.l....h.a.a-d| >> 00000090 ?00 04 73 65 6c 6c 63 39 ?2e 35 35 30 30 30 30 30 >> ?|..sellc9.5500000| >> 000000a0 ?30 30 30 30 30 30 30 30 ?30 30 30 30 30 65 2b 30 >> ?|0000000000000e+0| >> 000000b0 ?31 00 00 00 00 00 62 00 ?00 10 68 6a 6a 6a 68 03 >> ?|1.....b...hjjjh.| >> 000000c0 ?6c 00 00 00 01 68 05 61 ?06 61 2e 64 00 03 62 75 >> ?|l....h.a.a.d..bu| >> 000000d0 ?79 63 38 2e ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |yc8.| >> 000000d4 >> >> >> Sorry I can't provide code or core dumps. I can provide more memory >> dumps if needed. >> >> Erik Rigtorp >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From bengt.kleberg@REDACTED Thu Jul 23 15:26:27 2009 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 23 Jul 2009 15:26:27 +0200 Subject: [erlang-bugs] init:get_arguments() lacks -env assignments In-Reply-To: <4A4525C4.9080302@gmail.com> References: <4A4525C4.9080302@gmail.com> Message-ID: <1248355587.4817.31.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, I would like to add that the documentation (http://erlang.org/doc/man/erl.html) states: "In the following list, init flags are marked (init flag). Unless otherwise specified, all other flags are user flags, for which the values can be retrieved by calling init:get_argument/1." Since -env is not marked (init flag) it should be available. bengt On Fri, 2009-06-26 at 12:47 -0700, Michael Truog wrote: > It would be nice if the -env flags would be passed onto the higher > layers so they are accessible in the init module. That way, programs > that use the slave module can pass on the same environment to other > machines, assuming they are all setup the same. I do not know of other > command line flags that are inaccessible within the Erlang VM by the > init module, the documentation doesn't mention any. All the init > functions are affected, not just get_arguments(). An example is below: > > $ erl -env A_SHELL_VARIABLE 1 > Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [kernel-poll:false] > > Eshell V5.7.2 (abort with ^G) > 1> init:get_arguments(). > [{root,["/home/user/installed/lib/erlang"]}, > {progname,["erl"]}, > {home,["/home/user"]}] > 2> > > > Thanks, > Michael Truog > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From anders.nygren@REDACTED Thu Jul 23 20:36:42 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Thu, 23 Jul 2009 13:36:42 -0500 Subject: Dialyzer crashing Message-ID: Hi I am getting dialyzer to crash using R13B01 on Linux. I have a function like this -spec enc_app_cnxt/1 :: (undefined) -> (undefined); (app_cnxt()) -> (binary()). enc_app_cnxt(undefined) -> undefined; enc_app_cnxt({Name,Version}) when is_binary(Name), is_integer(Version) -> <<6,7,Name/binary,Version>>. And dialyzer gives me this warning "Type specification dial_map_params:enc_app_cnxt('undefined') -> ('undefined'); (app_cnxt()) -> (<<_:72>>) is a subtype of the success typing: dial_map_params:enc_app_cnxt('undefined' | {binary(),integer()}) -> 'undefined' | <<_:24,_:_*8>> " So I changed my spec to %-spec enc_app_cnxt/1 :: (undefined) -> (undefined); (app_cnxt()) -> (<<_:24,_:_*8>>). And then dialyzer crashes with dialyzer: Analysis failed with error: {{case_clause,8}, [{erl_types,t_form_to_string,1}, {erl_types,t_form_to_string,1}, {erl_types,t_form_to_string,1}, {dialyzer_utils,get_abstract_code_from_beam,1}, {dialyzer_succ_typings,get_warnings,6}, {dialyzer_analysis_callgraph,analyze_callgraph,2}, {dialyzer_analysis_callgraph,analysis_start,...}, {dialyzer_utils,...}]} Last messages in the log cache: Typesig analysis for SCC: [{yaws_soap_lib,write_hrl,3}] Typesig analysis for SCC: [{yaws_soap_srv,setup,2}] Typesig analysis for SCC: [{yaws_soap_srv,setup,3}] Dataflow of one SCC: [erlsom_pass2] Dataflow of one SCC: [erlsom_compile] Dataflow of one SCC: [erlsom_writeHrl,erlsom_add,erlsom] Dataflow of one SCC: [yaws_soap_lib] Dataflow of one SCC: [yaws_html] Dataflow of one SCC: [yaws_soap_srv] Dataflow of one SCC: [yaws_rpc] Check output file `../artifacts/glr.dialyzer' for details /Anders From mjtruog@REDACTED Fri Jul 24 06:28:13 2009 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 23 Jul 2009 21:28:13 -0700 Subject: lists:all/2 documentation omission Message-ID: <4A69385D.8030608@gmail.com> The implementation of lists:all/2 seems to contradict the documentation: "Returns true if Pred(Elem) returns true for all elements Elem in List, otherwise false." (from http://erlang.org/doc/man/lists.html) because of line 938 in lib/erlang/lib/stdlib-1.16.2/src/lists.erl all(Pred, []) when is_function(Pred, 1) -> true. The implementation is probably what a user normally wants but the documentation might need a slight addition to cover the empty list case. - Michael From vladdu55@REDACTED Fri Jul 24 08:29:04 2009 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 24 Jul 2009 08:29:04 +0200 Subject: online compiler docs not available Message-ID: <95be1d3b0907232329q39730ff0tf4107ec7f5d9cb13@mail.gmail.com> Hi, the link http://erlang.org/doc/apps/compiler/index.html is dead regards, Vlad From vincent.dephily@REDACTED Fri Jul 24 11:30:21 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 24 Jul 2009 11:30:21 +0200 Subject: ets table becomes unusable after a failed insert Message-ID: <200907241130.22465.vincent.dephily@mobile-devices.fr> Hi list, here's a quick demo: Erlang R13B01 (erts-5.7.2) [source] [rq:1] [async-threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> Table = ets:new(foobar, [set, public]). 16397 2> ets:tab2list(Table). [] 3> ets:insert(Table, {1}). true 4> ets:insert(Table, {2}). true 5> ets:tab2list(Table). [{1},{2}] 6> ets:insert(Table, 3). ** exception error: bad argument in function ets:insert/2 called as ets:insert(16397,3) 7> ets:insert(Table, {3}). ** exception error: bad argument in function ets:insert/2 called as ets:insert(16397,{3}) 8> ets:tab2list(Table). ** exception error: bad argument in function ets:match_object/2 called as ets:match_object(16397,'_') in call from ets:tab2list/1 The failure at 6> is expected since I didn't insert a tuple. But I expected 7> and 8> to work : one failed insert shouldn't make all subsequent operations fail. Unless there's some very good argument I'm missing ? -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. From zerthurd@REDACTED Fri Jul 24 11:42:29 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 24 Jul 2009 16:42:29 +0700 Subject: [erlang-bugs] ets table becomes unusable after a failed insert In-Reply-To: <200907241130.22465.vincent.dephily@mobile-devices.fr> References: <200907241130.22465.vincent.dephily@mobile-devices.fr> Message-ID: It is not a bug. It is shell-specific behaviour. Your ETS-table owned by one shell-process, and when you have exception error shell process have stopped and new one started. So, this new shell process have not access to ETS-table, because it owned by dead process. -- Maxim Treskin From vincent.dephily@REDACTED Fri Jul 24 12:17:55 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 24 Jul 2009 12:17:55 +0200 Subject: [erlang-bugs] ets table becomes unusable after a failed insert In-Reply-To: References: <200907241130.22465.vincent.dephily@mobile-devices.fr> Message-ID: <200907241217.55295.vincent.dephily@mobile-devices.fr> On Friday 24 July 2009 11:42:29 Maxim Treskin wrote: > It is not a bug. It is shell-specific behaviour. > Your ETS-table owned by one shell-process, and when you have exception > error shell process have stopped and new one started. So, this new shell > process have not access to ETS-table, because it owned by dead process. Fair enough, it doesn't happen in an escript. I thought that making the table public protected me from this, but have corrected my understaning. Thanks. -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. From zerthurd@REDACTED Fri Jul 24 12:26:21 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 24 Jul 2009 17:26:21 +0700 Subject: [erlang-bugs] ets table becomes unusable after a failed insert In-Reply-To: <200907241217.55295.vincent.dephily@mobile-devices.fr> References: <200907241130.22465.vincent.dephily@mobile-devices.fr> <200907241217.55295.vincent.dephily@mobile-devices.fr> Message-ID: ETS destroyed if owner process is dead. After your first exception error there is no more foobar table. -- Maxim Treskin From masse@REDACTED Fri Jul 24 12:32:35 2009 From: masse@REDACTED (mats cronqvist) Date: Fri, 24 Jul 2009 12:32:35 +0200 Subject: ets table becomes unusable after a failed insert In-Reply-To: (Maxim Treskin's message of "Fri\, 24 Jul 2009 16\:42\:29 +0700") References: <200907241130.22465.vincent.dephily@mobile-devices.fr> Message-ID: <8763dibccc.fsf@sterlett.hq.kred> Maxim Treskin writes: > It is not a bug. It is shell-specific behaviour. > Your ETS-table owned by one shell-process, and when you have exception error > shell process have stopped and new one started. Correct. > So, this new shell process have not access to ETS-table, because it > owned by dead process. Actually, the table no longer exists. Tables are linked to the creating process. When that died, the table disappeared. mats From vladdu55@REDACTED Mon Jul 27 10:15:50 2009 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 27 Jul 2009 10:15:50 +0200 Subject: file module doesn't support utf-8 file names Message-ID: <95be1d3b0907270115k5e0b6ba9uae476634bf27c04f@mail.gmail.com> Hi, with the recent addition of utf-8 support, there are high expectations about where utf-8 values are allowed. One of those is in file paths, where the file name is types as a string(), but the file:file_name/1 utility function only allows characters between 0 and 255. I think that just allowing integers up to 65535 should fix this. Similar issues seem to be present in epp.erl, erl_comment_scan.erl, erl_tidy.erl and igor.erl. best regards, Vlad From leap@REDACTED Wed Jul 29 10:34:46 2009 From: leap@REDACTED (Michael Turner) Date: Wed, 29 Jul 2009 08:34:46 +0000 Subject: R12B01 erl_misc_utils.c stack-trashing bug, + a patch In-Reply-To: <20090729080135.34C962D6014@idiom.com> Message-ID: Was trying to build on a i386_unknown_freebsd4.10, with a gcc about 10 years old. The build died in /lib/parsetools/src. gdb revealed revealed a trashed stack. The source of the problem became clear after narrowing it down to a function in erl_misc_utils.c. There are assignments to mib[0] and mib[1], with mib declared size zero. (Yes. sizeof (mib) == 0. The first time I've ever seen that. And the last, I hope.) Dimension of 2 for mib[] seemed appropriate in context. The build continued after that fix. ========== --- otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c.~1~ Wed Jul 29 00:53:30 2009 +++ otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c Tue Jul 28 22:17:45 2009 @@ -172,7 +172,7 @@ erts_cpu_info_update(erts_cpu_info_t *cp #elif defined(HAVE_SYS_SYSCTL_H) && defined(CTL_HW) && (defined(HW_NCPU) \ || defined(HW_AVAILCPU)) { - int mib[0]; + int mib[2]; size_t len; #ifdef HW_NCPU From mikpe@REDACTED Wed Jul 29 13:22:35 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 29 Jul 2009 13:22:35 +0200 Subject: [erlang-bugs] R12B01 erl_misc_utils.c stack-trashing bug, + a patch In-Reply-To: References: <20090729080135.34C962D6014@idiom.com> Message-ID: <19056.12539.710440.783419@pilspetsen.it.uu.se> Michael Turner writes: > > Was trying to build on a i386_unknown_freebsd4.10, with a gcc about 10 > years old. The build died in /lib/parsetools/src. gdb revealed > revealed a trashed stack. > > The source of the problem became clear after narrowing it down to a > function in erl_misc_utils.c. There are assignments to mib[0] and > mib[1], with mib declared size zero. (Yes. sizeof (mib) == 0. The > first time I've ever seen that. And the last, I hope.) > > Dimension of 2 for mib[] seemed appropriate in context. The build > continued after that fix. > > ========== > > --- otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c.~1~ Wed Jul 29 > 00:53:30 2009 > +++ otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c Tue Jul 28 > 22:17:45 2009 > @@ -172,7 +172,7 @@ erts_cpu_info_update(erts_cpu_info_t *cp > #elif defined(HAVE_SYS_SYSCTL_H) && defined(CTL_HW) && (defined(HW_NCPU) > \ > || defined(HW_AVAILCPU)) Two nits: 1. Subject doesn't match contents (different Erlang versions). 2. The patch is broken due to line-wrapping in three lines. When sending patches, you must ensure that the text isn't mangled in any way. (Many MUAs appear to be broken in this regard.) From leap@REDACTED Wed Jul 29 14:14:10 2009 From: leap@REDACTED (Michael Turner) Date: Wed, 29 Jul 2009 12:14:10 +0000 Subject: [erlang-bugs] R12B01 erl_misc_utils.c stack-trashing bug, + a patch In-Reply-To: <19056.12539.710440.783419@pilspetsen.it.uu.se> Message-ID: On 7/29/2009, "Mikael Pettersson" wrote: >Michael Turner writes: > > [snip] > >Two nits: >1. Subject doesn't match contents (different Erlang versions). >2. The patch is broken due to line-wrapping in three lines. When sending > patches, you must ensure that the text isn't mangled in any way. > (Many MUAs appear to be broken in this regard.) I'll fix and resubmit (the first was a typo, I just typed the subject line instead of copy-pasting the elements). But instead of learning by trial and error, how about some guide to submitting patches? Is the following http://www.linuxchix.org/content/courses/kernel_hacking/lesson9 a good guideline? I know there's this http://www.kegel.com/academy/opensource.html#patches.making in a source recommended from www.erlang.org. But it's not very specific. Where the www.erlang.org FAQ gets specific, it looks like it might be wrong "If your code is a modification to an existing part of OTP, attach a patch to your post to the erlang-patches mailing list." Attachments are OK? I've noticed people contributing patches on the patches list as attachments, but the attachments don't seem to show up in the mailing list archives. For example. http://www.erlang.org/cgi-bin/ezmlm-cgi?:mss:439:200907:pbcapfejlooponffmmen How do you get your hands on a patch if you didn't get it as an attachment, and only because you weren't subscribed to the patches mailing list at the time? Where do these end up? Did this guy just forget to attach (maybe twice)? If so, why did nobody comment? Or are you just not supposed to send patches as attachments? If so, well ... why did nobody comment to that effect? The "Help" link at http://www.erlang.org/cgi-bin/ezmlm-cgi/3 just goes to the www.erlang.org FAQ. The "FAQ" link there is even more opaque: it's a mail-to link with address erlang-patches-faq@REDACTED Some formal guidance on patch submission would be appreciated. -michael turner From bgustavsson@REDACTED Wed Jul 29 16:40:51 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 29 Jul 2009 16:40:51 +0200 Subject: [erlang-bugs] R12B01 erl_misc_utils.c stack-trashing bug, + a patch In-Reply-To: References: <20090729080135.34C962D6014@idiom.com> Message-ID: <6672d0160907290740t1bc00958la7bec09f9a32160b@mail.gmail.com> On Wed, Jul 29, 2009 at 10:34 AM, Michael Turner wrote: > > Was trying to build on a i386_unknown_freebsd4.10, with a gcc about 10 > years old. ?The build died in /lib/parsetools/src. ?gdb revealed > revealed a trashed stack. > > The source of the problem became clear after narrowing it down to a > function in erl_misc_utils.c. ?There are assignments to mib[0] and > mib[1], with mib declared size zero. (Yes. ?sizeof (mib) == 0. ?The > first time I've ever seen that. ?And the last, I hope.) Thanks for the bug report and patch. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fritchie@REDACTED Fri Jul 31 06:18:30 2009 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 30 Jul 2009 23:18:30 -0500 Subject: R13B01 bug in file:pwrite()? Message-ID: <58692.1249013910@snookles.snookles.com> Hi, all. This sounds really weird, but I have a test case that can irregularly trigger this bug within 5-10 minutes. I can't post all the code, in part because it's driven by Quviq's QuickCheck. :-) I'll try to cobble together as much info as I can gather, for such an intermittent problem. 100% of the time, I see crashes after the "Use Scribble..." message. The error could be happening perhaps after the func has returned, but 100% of the time there isn't any output following "Use Scribble...", and the surrounding code is fairly verbose. scribbles(ArgsList, PathT) -> io:format("Num scribbles = ~p\n", [length(ArgsList)]), lists:map( fun([SeqNum, Offset, NewBlob]) -> Path = element((SeqNum rem size(PathT)) + 1, PathT), {ok, FI} = file:read_file_info(Path), Pos = Offset rem (FI#file_info.size + 1), % in case size = 0. {ok, FH} = file:open(Path, [binary, read, write]), io:format("Pread ~p at Pos ~p for ~p bytes\n", [Path, Pos, size(NewBlob)]), OldBlob = case (catch file:pread(FH, Pos, size(NewBlob))) of {ok, BLB} -> BLB; _ -> cant_match_any_binary_ha_ha end, io:format("Use Scribble ~p at ~p Pos ~p\n", [NewBlob, Path, Pos]), ok = file:pwrite(FH, Pos, NewBlob), file:close(FH), OldBlob == NewBlob end, ArgsList). I'm using R13B01 on a 32-bit install of a Linux Fedora 11 distro, 2.6.27.25-170.2.72.fc10.i686 kernel. I've seen this happen with SMP support enabled or disabled, with the +A worker pool enabled or disabled, with +K true or false. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND fritchie 12106 77.8 45.8 1716800 1661460 pts/22 Sl+ 22:22 6:10 /tmp/R13B01-debug/lib/erlang/erts-5.7.2/bin/beam.smp -K true -- -root /tmp/R13B01-debug/lib/erlang -progname erl -- -home /home/fritchie -smp enable -sname foo_dev -boot foo -pz ... [many more -pz flags...] (I had "ps u" running in a loop 4x per second. The above was taken during the ERTS_HOLE_MARKER output below. The reading 0.25 seconds earlier was VSZ of about 70MB.) The above is a debug build, as best as I've been able to do. (It isn't one-command easy, alas.) Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:true] [type-assertions] [debug-compiled] [lock-checking] Sample output after the crash looks like this. Some messages are lacking the "Num scribbles..." output because I'd added that one a bit later. Use Scribble <<"ff">> at "./zzz-hlog-qc/2/6/-000000000061.HLOG" Pos 10172 Pread "./zzz-hlog-qc/2/2/-000000000085.HLOG" at Pos 64 for 27 bytes Use Scribble <<"RRRRRRRRRRRRRRRRRRRRRRRRRRR">> at "./zzz-hlog-qc/2/2/-000000000085.HLOG" Pos 64 Pread "./zzz-hlog-qc/2/6/-000000000061.HLOG" at Pos 1162 for 3 bytes Use Scribble <<"??????">> at "./zzz-hlog-qc/2/6/-000000000061.HLOG" Pos 1162 Pread "./zzz-hlog-qc/000000000084.HLOG" at Pos 652 for 22 bytes Use Scribble <<"NNNNNNNNNNNNNNNNNNNNNN">> at "./zzz-hlog-qc/000000000084.HLOG" Pos 652 Pread "./zzz-hlog-qc/000000000046.HLOG" at Pos 653 for 8 bytes Use Scribble <<"????????????????">> at "./zzz-hlog-qc/000000000046.HLOG" Pos 653 make: *** [run-app1-interactive] Segmentation fault .....Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 216 for 1 bytes Use Scribble <<"Z">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 216 Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 330 for 1 bytes Use Scribble <<"??">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 330 Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 83 for 1 bytes Use Scribble <<"??">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 83 Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 176 for 1 bytes Use Scribble <<"?">> at "./zzz-hlog-qc/000000000001.HLOG" Pos 176 Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 2147483700 bytes of memory (of type "heap_frag"). make: *** [run-app1-interactive] Aborted ---- Pread "./zzz-hlog-qc/000000000001.HLOG" at Pos 443 for 0 bytes Use Scribble <<>> at "./zzz-hlog-qc/000000000001.HLOG" Pos 443 Pread "./zzz-hlog-qc/000000000065.HLOG" at Pos 2496 for 21 bytes Use Scribble <<"ooooooooooooooooooooo">> at "./zzz-hlog-qc/000000000065.HLOG" Pos 2496 Pread "./zzz-hlog-qc/2/2/-000000000064.HLOG" at Pos 70 for 16 bytes Use Scribble <<"????????????????????????????????">> at "./zzz-hlog-qc/2/2/-000000000064.HLOG" Pos 70 Pread "./zzz-hlog-qc/3/6/-000000000047.HLOG" at Pos 6226 for 4 bytes Use Scribble <<"????????">> at "./zzz-hlog-qc/3/6/-000000000047.HLOG" Pos 6226 make: *** [run-app1-interactive] Segmentation fault ---- . =GMT ERR REPORT==== 30-Jul-2009::21:05:45 === fold_a_file: seq -2 offset 0: {error,unknown_file_header, {ok,<<"LogVersion1L">>}} .Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 115 for 1 bytes Use Scribble <<"??">> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos 115 Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 127 for 1 bytes Use Scribble <<"0">> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos 127 Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 3087007804 bytes of memory (of type "heap_frag"). make: *** [run-app1-interactive] Aborted ---- ..nnNum scribbles = 2 Pread "./zzz-hlog-qc/000000000023.HLOG" at Pos 183 for 6 bytes Use Scribble <<21,21,21,21,21,21>> at "./zzz-hlog-qc/000000000023.HLOG" Pos 183 Pread "./zzz-hlog-qc/1/4/-000000000003.HLOG" at Pos 966 for 13 bytes Use Scribble <<"xxxxxxxxxxxxx">> at "./zzz-hlog-qc/1/4/-000000000003.HLOG" Pos 9 66 ErrList1 ErrList2 [{seq,23,err,badarg}] [{seq,-3,err,{badmatch,false}}] .Num scribbles = 1 Pread "./zzz-hlog-qc/3/3/-000000000002.HLOG" at Pos 32 for 18 bytes Use Scribble <<140,140,140,140,140,140,140,140,140,140,140,140,140,140,140,140, 140,140>> at "./zzz-hlog-qc/3/3/-000000000002.HLOG" Pos 32 beam/erl_debug.c, line 361: ERTS_HOLE_MARKER found at 0x531ca148 | | Range: 0x4e391038 - 0xb29d74a4 | | Address | Contents | |------------|---------------------------------------------| | 0x4e391038 | 0x000000c0 0x4e391049 0x4e391044 0x00000000 | | 0x4e391048 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e391058 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e391068 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e391078 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e391088 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e391098 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x4e3910a8 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | [... 7 gazillions of nearly identical lines omitted...] | 0x531ca0f8 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca108 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca118 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca128 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca138 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca148 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca158 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca168 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca178 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca188 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | | 0x531ca198 | 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc 0xaf5e78cc | [... I didn't have enough disk space to record output to 0xb29d74a4...] Attaching GDB to the process while QC is running doesn't work very well. After "attach" and "continue", the VM freezes. Pressing C-c and C-g (running GDB within Emacs in gdb-mode) can't interrupt GDB to get a prompt back. I can only kill the GDB process externally. :-( So catching a SIGSEGV in-the-act hasn't been possible. Is there some trick to doing that? Or perhaps FC11's GDB is braindamaged somehow? Or Linux? % gdb --version GNU gdb Fedora (6.8-32.fc10) [...] This GDB was configured as "i386-redhat-linux-gnu". However, while all the ERTS_HOLE_MARKER stuff was dumping, I attached GDB and got this info on all threads. (gdb) thread apply all info stack Thread 6 (Thread 0xb7d27b90 (LWP 12113)): #0 0xb8028416 in __kernel_vsyscall () #1 0x0054f19b in read () from /lib/libpthread.so.0 #2 0x081cb5ec in signal_dispatcher_thread_func (unused=0x0) at sys/unix/sys.c:2913 #3 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae2bc) at common/ethread.c:475 #4 0x0054851f in start_thread () from /lib/libpthread.so.0 #5 0x0047e04e in clone () from /lib/libc.so.6 Thread 5 (Thread 0xb7326b90 (LWP 12114)): #0 0xb8028416 in __kernel_vsyscall () #1 0x0054c105 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0823cf29 in ethr_cond_wait (cnd=0x82affe0, mtx=0x82aff40) at common/ethread.c:1018 #3 0x080c170e in erts_cnd_wait (cnd=0x82affe0, mtx=0x82aff40) at beam/erl_threads.h:634 #4 0x080c26f8 in erts_smp_cnd_wait (cnd=0x82affe0, mtx=0x82aff40) at beam/erl_smp.h:417 #5 0x080bf963 in sys_msg_dispatcher_func (unused=0x0) at beam/erl_trace.c:3078 #6 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae32c) at common/ethread.c:475 #7 0x0054851f in start_thread () from /lib/libpthread.so.0 #8 0x0047e04e in clone () from /lib/libc.so.6 Thread 4 (Thread 0xb8026b90 (LWP 12115)): #0 0xb8028416 in __kernel_vsyscall () #1 0x0054c105 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0823cf29 in ethr_cond_wait (cnd=0x82d8c00, mtx=0x82d8bc0) at common/ethread.c:1018 #3 0x080c170e in erts_cnd_wait (cnd=0x82d8c00, mtx=0x82d8bc0) at beam/erl_threads.h:634 #4 0x081cb4a9 in child_waiter (unused=0x0) at sys/unix/sys.c:2842 #5 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae2cc) at common/ethread.c:475 #6 0x0054851f in start_thread () from /lib/libpthread.so.0 #7 0x0047e04e in clone () from /lib/libc.so.6 Thread 3 (Thread 0xb6925b90 (LWP 12116)): #0 0xb8028416 in __kernel_vsyscall () #1 0x0046db3b in write () from /lib/libc.so.6 #2 0x00404a7c in _IO_new_file_write () from /lib/libc.so.6 #3 0x00405bf7 in _IO_new_do_write () from /lib/libc.so.6 #4 0x004055a5 in _IO_new_file_overflow () from /lib/libc.so.6 #5 0x00408423 in __overflow () from /lib/libc.so.6 #6 0x082410f7 in write_f_add_cr (vfp=0x50a4c0, buf=0x8250ffe "|\n", len=2) at common/erl_printf.c:108 #7 0x08240c97 in erts_printf_format (fn=0x8241070 , arg=0x50a4c0, fmt=0x8250ffe "|\n", ap=0xb6924174 "\b") at common/erl_printf_format.c:832 #8 0x08241576 in erts_printf (format=0x8250ffe "|\n") at common/erl_printf.c:218 #9 0x080ebf5e in print_untagged_memory (pos=0x641e0338, end=0xb29d74a8) at beam/erl_debug.c:518 #10 0x080eba1c in check_memory (start=0x4e391038, end=0xb29d74a8) at beam/erl_debug.c:362 #11 0x080eb987 in erts_check_for_holes (p=0xb4e32d94) at beam/erl_debug.c:347 #12 0x08199ed4 in process_main () at beam/beam_emu.c:2049 #13 0x080f6f67 in sched_thread_func (vesdp=0xb7e0bc00) at beam/erl_process.c:3015 #14 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae38c) at common/ethread.c:475 #15 0x0054851f in start_thread () from /lib/libpthread.so.0 #16 0x0047e04e in clone () from /lib/libc.so.6 Thread 2 (Thread 0xb5f24b90 (LWP 12117)): #0 0xb8028416 in __kernel_vsyscall () #1 0x0047e836 in epoll_wait () from /lib/libc.so.6 #2 0x081d07e5 in check_fd_events (ps=0xb7daa400, tv=0xb5f2291c, max_res=256, ps_locked=0xb5f228d4) at sys/common/erl_poll.c:1906 #3 0x081d093b in erts_poll_wait_kp (ps=0xb7daa400, pr=0xb5f22928, len=0xb5f22924, utvp=0xb5f2291c) at sys/common/erl_poll.c:2042 #4 0x081d2f18 in erts_check_io_kp (do_wait=1) at sys/common/erl_check_io.c:1156 #5 0x081cb4e1 in erl_sys_schedule (runnable=0) at sys/unix/sys.c:2860 #6 0x080f0f3f in sched_sys_wait (no=2, rq=0xb7e0b758) at beam/erl_process.c:774 #7 0x080fdcb9 in schedule (p=0xb4f4bd1c, calls=15) at beam/erl_process.c:6023 #8 0x081887eb in process_main () at beam/beam_emu.c:1126 #9 0x080f6f67 in sched_thread_func (vesdp=0xb7e1dcd0) at beam/erl_process.c:3015 #10 0x0823c0b6 in thr_wrapper (vtwd=0xbfaae38c) at common/ethread.c:475 #11 0x0054851f in start_thread () from /lib/libpthread.so.0 #12 0x0047e04e in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb800e6c0 (LWP 12106)): #0 0xb8028416 in __kernel_vsyscall () #1 0x004763d1 in select () from /lib/libc.so.6 #2 0x081cb7d1 in erts_sys_main_thread () at sys/unix/sys.c:3021 #3 0x080918b1 in erl_start (argc=62, argv=0xbfaae684) at beam/erl_init.c:1231 #4 0x08072e66 in main (argc=Cannot access memory at address 0x0 ) at sys/unix/erl_main.c:29 (gdb) The ERTS_HOLE_MARKER thing happens much less frequently than the simple SIGSEGV or out-of-memory thing, perhaps once every 20 minutes or so of constant trying. I've got a copy of the core image via "gcore", if it'd help. I'm at a bit of a loss of what other info I can provide, so please let me know if I can send something else. -Scott From baryluk@REDACTED Fri Jul 31 12:48:27 2009 From: baryluk@REDACTED (Witold Baryluk) Date: Fri, 31 Jul 2009 12:48:27 +0200 Subject: inets: HTTP client race condition Message-ID: <1249037307.13468.50.camel@sredniczarny> Hi, Today I have encountered strange problem in simple scenario with inets. when I'm doing concurrent requests to the same server which responds slowly. go() -> inets:start(), lists:foldl(fun(_, _) -> spawn(fun() -> {ok, {A,B,C}}=http:request("http://www.wp.pl/"), io:format("ok ~p~n", [A]) end), receive after 1334 -> ok end end, 0, lists:seq(1, 5) ). It is quite indeterministic, just try many times or change parameters. Some of the request will crash: ** Reason for termination == ** {bad_return_value,{error,{invalid_version,">Zwiastuny
  • Erlang Training & Consulting Ltd -------------- next part -------------- =ERROR REPORT==== 31-Jul-2009::11:56:11 === ** Generic server <0.1455.0> terminating ** Last message in was {tcp,#Port<0.8412>, <<">Zwiastuny
  • Multikino

    • wi?cej »

  • Kobieta
  • Motoryzacja