From nesrait@REDACTED Tue May 5 03:04:10 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Tue, 5 May 2009 02:04:10 +0100 Subject: [erlang-bugs] erl_interface: badarg on specific inputs Message-ID: <523869a70905041804h9cb83dfk83ef5edacb14a2dd@mail.gmail.com> Hi all, I hope I'm not abusing this mailing list with this email. I posted the problem earlier today on erlang-questions: http://www.erlang.org/pipermail/erlang-questions/2009-May/043577.html but I'm guessing there aren't many erl_interface [on windows] users. Since this might be a bug here goes... Under certain inputs my basic port programs are simply breaking: 4> echo:echo("aaa aaaaaa"). sending to port: {echo,{"aaa aaaaaa"}} =ERROR REPORT==== 4-May-2009::16:11:15 === catch: error:badarg This might be simply due to bad coding on my part but I've tried to keep it simple to rule that out. I was able to replicate the problem with erl_interface-3.6.1 (.lib that come with the binary windows distribution; a MSVC build; and a MinGW build) and erl_interface-3.5.9 (MinGW build only). The [failing] code is available here: http://github.com/davide/erl_interface-examples/tree/master A sure way to get the echo program to fail is: echo:echo("New Folder"). I'm welcoming any feedback! Even if it's just to point out that I'm doing something really dumb (I can live with that). :) On a side note, on the docs folder I documented my experience of trying (and failing) to build erlang on Windows (using Visual C++ 2008 Express Edition). As the details might be revelant to other users please consider updating README.WIN32 to get it into a step-by-step/How-To style . Cheers, :Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.melin@REDACTED Sat May 9 21:32:53 2009 From: per.melin@REDACTED (Per Melin) Date: Sat, 9 May 2009 21:32:53 +0200 Subject: [erlang-bugs] Crashing bug in inets http client in R13B. Message-ID: PROBLEM 1: The documentation for http:set_options/1,2 describes the option {max_keep_alive_length, MaxKeepAlive} as "Maximum number of outstanding requests on the same connection to a host. Default is 2." 1> http:set_options([{max_keep_alive_length, 10}]). {error,{not_an_option,{max_keep_alive_length,10}}} http:validate_options/1 is missing a check for max_keep_alive_length. Instead it has two identical checks for max_pipeline_length. PROBLEM 2: The documentation says the default for max_keep_alive_length is 2, but it's actually 5. PROBLEM 3: Looking at the code, I see that it checks that #tcp_session{queue_length} never exceeds max_keep_alive_length. But when pipelining is disabled queue_length is always just either 0 or 1. When pipelining is disabled requests will still be unwittingly pipelined, which can cause requests to be lost and if the server actually supports pipelining the handler will crash. SCENARIO 1: Eshell V5.7.1 (abort with ^G) 1> inets:start(). ok 2> URL = "http://www.erlang.org/". "http://www.erlang.org/" 3> http:request(get, {URL, []}, [], []), 3> http:request(get, {URL, []}, [], [{sync, false}]), 3> http:request(get, {URL, []}, [], [{sync, false}]), 3> http:request(get, {URL, []}, [], [{sync, false}]), 3> ok. ok 4> =ERROR REPORT==== 9-May-2009::20:50:49 === ** Generic server <0.48.0> terminating ** Last message in was {tcp,#Port<0.955>, ... 4> process_info(self(), message_queue_len). {message_queue_len,1} SCENARIO 2: Eshell V5.7.1 (abort with ^G) 1> inets:start(). ok 2> URL = "http://www.erlang.org/". "http://www.erlang.org/" 3> F = fun() -> http:request(get, {URL, []}, [], []) end, 3> F(), 3> spawn(F), 3> spawn(F), 3> spawn(F), 3> ok. ok 4> =ERROR REPORT==== 9-May-2009::20:52:52 === ** Generic server <0.48.0> terminating ** Last message in was {tcp,#Port<0.955>, ... In both cases the first request will create a handler and a keep-alive session. The second request will reuse the connection. But so will the third and fourth request, before the second has finished. The handler doesn't think it's pipelining and when the response from the third request comes back it doesn't know what to do with it and crashes. I'm probably wrong, but from reading the code it seems to me that the implementation of keep-alive requests without pipelining is only halfway done. From egil@REDACTED Mon May 11 12:23:38 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 11 May 2009 12:23:38 +0200 Subject: [erlang-bugs] erl_interface: badarg on specific inputs In-Reply-To: <523869a70905041804h9cb83dfk83ef5edacb14a2dd@mail.gmail.com> References: <523869a70905041804h9cb83dfk83ef5edacb14a2dd@mail.gmail.com> Message-ID: <4A07FCAA.6040509@erix.ericsson.se> Hi Davide, I want to thank you for taking your time to point out some problems with erl_interface and say that I agree with you that its Howto/Tutorial needs some sort of overhaul and additions. I will take a look at your repo and your suggestions. Regards, Bj?rn-Egil Erlang/OTP Davide Marqu?s wrote: > Hi all, > > I hope I'm not abusing this mailing list with this email. I posted the > problem > earlier today on erlang-questions: > http://www.erlang.org/pipermail/erlang-questions/2009-May/043577.html > but I'm guessing there aren't many erl_interface [on windows] users. > Since this might be a bug here goes... > > Under certain inputs my basic port programs are simply breaking: > > 4> echo:echo("aaa aaaaaa"). > > sending to port: {echo,{"aaa aaaaaa"}} > > =ERROR REPORT==== 4-May-2009::16:11:15 === > catch: error:badarg > > This might be simply due to bad coding on my part but I've tried to keep it > simple to rule that out. I was able to replicate the problem with > erl_interface-3.6.1 > (.lib that come with the binary windows distribution; a MSVC build; and > a MinGW build) > and erl_interface-3.5.9 (MinGW build only). > > The [failing] code is available here: > http://github.com/davide/erl_interface-examples/tree/master > A sure way to get the echo program to fail is: echo:echo("New Folder"). > > I'm welcoming any feedback! Even if it's just to point out that I'm > doing something > really dumb (I can live with that). :) > > On a side note, on the docs folder I documented my experience of trying > (and failing) to build erlang on Windows (using Visual C++ 2008 Express > Edition). > As the details might be revelant to other users please consider updating > README.WIN32 to get it into a step-by-step/How-To style > . > > Cheers, > :Davide > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From nesrait@REDACTED Mon May 11 13:29:47 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Mon, 11 May 2009 12:29:47 +0100 Subject: [erlang-bugs] erl_interface: badarg on specific inputs In-Reply-To: <4A07FCAA.6040509@erix.ericsson.se> References: <523869a70905041804h9cb83dfk83ef5edacb14a2dd@mail.gmail.com> <4A07FCAA.6040509@erix.ericsson.se> Message-ID: <523869a70905110429u678bcbf3t36ee56df073e8c9f@mail.gmail.com> Hi all, Just wanted to let you know that I found out what was preventing erl_interface from working on windows! :) The solution had already been shared on the mailing lists: http://erlang.org/pipermail/erlang-questions/2004-April/012097.html http://www.erlang.org/ml-archive/erlang-questions/200305/msg00259.html It's just a matter of setting stdin/out to binary mode and voil?: working code! We have Serge Aleynikov to thank for figuring out the solution to this problem and for a great tutorial on using ei: http://www.trapexit.org/How_to_use_ei_to_marshal_binary_terms_in_port_programs Thanks wherever you are! :) The erl_interface examples complex/echo (http://github.com/davide/erl_interface-examples/tree/master) are now working. :) Cheers, :Davide 2009/5/11 Bj?rn-Egil Dahlberg : > Hi Davide, > > I want to thank you for taking your time to point out some problems with > erl_interface and say that I agree with you that its Howto/Tutorial needs > some sort of overhaul and additions. > > I will take a look at your repo and your suggestions. > > Regards, > Bj?rn-Egil > Erlang/OTP > > > > Davide Marqu?s wrote: >> >> Hi all, >> >> I hope I'm not abusing this mailing list with this email. I posted the >> problem >> earlier today on erlang-questions: >> http://www.erlang.org/pipermail/erlang-questions/2009-May/043577.html >> but I'm guessing there aren't many erl_interface [on windows] users. >> Since this might be a bug here goes... >> >> Under certain inputs my basic port programs are simply breaking: >> >> 4> echo:echo("aaa aaaaaa"). >> >> sending to port: {echo,{"aaa aaaaaa"}} >> >> =ERROR REPORT==== 4-May-2009::16:11:15 === >> catch: error:badarg >> >> This might be simply due to bad coding on my part but I've tried to keep >> it >> simple to rule that out. I was able to replicate the problem with >> erl_interface-3.6.1 >> (.lib that come with the binary windows distribution; a MSVC build; and a >> MinGW build) >> and erl_interface-3.5.9 (MinGW build only). >> >> The [failing] code is available here: >> http://github.com/davide/erl_interface-examples/tree/master >> A sure way to get the echo program to fail is: echo:echo("New Folder"). >> >> I'm welcoming any feedback! Even if it's just to point out that I'm doing >> something >> really dumb (I can live with that). :) >> >> On a side note, on the docs folder I documented my experience of trying >> (and failing) to build erlang on Windows (using Visual C++ 2008 Express >> Edition). >> As the details might be revelant to other users please consider updating >> README.WIN32 to get it into a step-by-step/How-To style >> . >> >> Cheers, >> :Davide >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > > From michael.santos@REDACTED Tue May 12 03:01:51 2009 From: michael.santos@REDACTED (Michael Santos) Date: Mon, 11 May 2009 21:01:51 -0400 Subject: [erlang-bugs] crash in re:compile Message-ID: <20090512010151.GB23856@ecn.lan> Compiling a regexp crashes the vm. --cut -module(xx). -export([start/0,start/1]). start() -> start(1000). start(N) -> re:compile(lists:flatten([lists:duplicate(N, $(), lists:duplicate(N, $))])). --cut $ uname -a Linux nul 2.6.24-24-generic #1 SMP Wed Apr 15 15:54:25 UTC 2009 i686 GNU/Linux $ erl -s xx start Erlang R13B (erts-5.7.1) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] *** stack smashing detected ***: /media/opt/local/lib/erlang/erts-5.7.1/bin/beam terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7e90138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7e900f0] /media/opt/local/lib/erlang/erts-5.7.1/bin/beam(erts_pcre_compile2+0x5d7)[0x8182337] /media/opt/local/lib/erlang/erts-5.7.1/bin/beam(re_compile_2+0x189)[0x811afd9] $ uname -a Darwin ack 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 $ erl -s xx start Erlang R13B (erts-5.7.1) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Bus error From michael.santos@REDACTED Tue May 12 03:11:14 2009 From: michael.santos@REDACTED (Michael Santos) Date: Mon, 11 May 2009 21:11:14 -0400 Subject: [erlang-bugs] XSS in inets Message-ID: <20090512011114.GC23856@ecn.lan> The inets httpd server does not perform output encoding on user input. $ nc localhost 8080 GET /blah HTTP/1.0 HTTP/1.0 404 Object Not Found Server: inets/5.0.13 Date: Tue, 12 May 2009 00:57:16 GMT Content-Type: text/html Content-Length: 206 Object Not Found

Object Not Found

The requested URL /blah was not found on this server. The supplied markup in the entity body may be interpreted by the browser, with the possibility of XSS, phishing, etc. Fix: For the error page, maybe return "text/plain". A proper fix is to perform HTML or URI encoding on any user supplied input that is subsequently outputted. From joe@REDACTED Thu May 14 18:53:38 2009 From: joe@REDACTED (Joe Williams) Date: Thu, 14 May 2009 09:53:38 -0700 Subject: [erlang-bugs] clock_gettime stability check locked out for linux Message-ID: <4A0C4C92.60207@joetify.com> The check for clock_gettime ignores the configure test result for stability. Discussed in the following thread: http://groups.google.com/group/erlang-programming/browse_thread/thread/4f4f5a03fd5c8c6b I am interested in whether this is a legitimate issue on linux systems or an artifact to lock this setting out on older kernels. According to the libc docs on newer kernels the appropriate clock ids are supported. If the latter is it possible the check could be adjusted to lock out old kernels and actually honor the stability test result on newer? Any information you have on this is helpful. -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ From oscar@REDACTED Fri May 15 01:11:40 2009 From: oscar@REDACTED (=?ISO-8859-1?Q?Oscar_Hellstr=F6m?=) Date: Fri, 15 May 2009 00:11:40 +0100 Subject: [erlang-bugs] Issues with the inets http client Message-ID: <4A0CA52C.5030409@erlang-consulting.com> Hi All, I have some experience of trying to use the inets HTTP client in production code that heavily relies on XML over HTTP APIs to external systems. Among other client libraries we've tried to use the inets HTTP client and have found some issues with this. 1) Synchronous requests between the httpc_manager and httpc_handler When a new connection needs to be spawned, the httpc_manager calls start_handler/2, which in turn either calls httpc_handler_sup:start_child/1 or httpc_handler:start_link/3. httpc_handler is a gen_server, which will do way too much work in its init function. It will call send_first_request/3 (unless it returns a https_through_proxy_is_not_currently_supported error), which will try to establish a connection to a remote server, and send the request. This might sound like the sane thing to do, but establishing a connection can take a very long time, and it will actually use the timeout for the complete request in the call to http_transport:connect/4. Now, it has been pointed out that the TCP stack might time out earlier, but this is still potentially a very long time. The problem here is that the process that called start_link on a gen_server will be blocked until the call to init/1 has returned. So, the manager, responsible for relaying requests and responses for every request in the system is blocked while some request is trying to connect and send its data. On a congested network this can be even worse, since the call httpc_request:send/3, thit will eventually call gen_tcp:send/2 or ssl:send/2, might also block, this time for an unspecified time. During this time, no other requests or responses can't be handled by the manager. In our case this caused the manager to have several thousands of http requests queued up in its message queue, using quite a lot of memory, and making issue number 2 even worse. 2) Timeout handling The http:request/X function will call http_handler:request/2, which will return a request id. It will then call handle_answer/2. If the request is a synchronous request it will wait (without a timeout) for a response from the manager. The manager in question can (as pointed out above) be busy with any other request and this request will be somewhere in its message queue. When the manager however manages to deal with the request it can either spawn a new httpc_handler, or reuse one. In the first case, as pointed out above, the timeout is used to connect (with ssl this gets even worse, since the same timeout is reused in several calls without subtracting the time used, and in some cases, an infinite timeout is used to resolve the host name). In the second case, httpc_handler:send/2 is called. This is a gen_server call which would time out in 5 seconds (card coded). Again, this calls httpc_request:send, which might block forever. After (possibly connecting and) sending the request, which might or might not have taken a long time, activate_request_timeout/1 is called, with the originally specified timeout. This starts a timer, using erlang:send_after/3. (Just as a side note, this does a call back to httpc_manager, to add a session in some ets table...) which is the request timeout. In our case, we use SSL. We did get hit by the infinite timeout for DNS looups when out network wasn't performing as it should, and we had lots of hanging processes. This means that combined with the first case, you can hang the httpc_manager forever. When processes didn't hang, the requests would time out long after they "should have" according to what I would expect from passing a timeout to an API call. 3) Copying of data between processes The http module will send the request to the httpc_manager, which will either dispatch it to an existing httpc_handler process, or will spawn a new one and send it to that. This mean that all data in the request will be copied form requesting process to the manager and the httpc_handler process. The result of the request is copied from the httpc_handler process to the httpc_manager and then to the requesting process. The httpc_handler process will hang around until a timeout is reached or the socket is closed remotely. Before that, a gc has hopefully taken place. The manager will never exit, but will hopefully also gc at some point. The requesting process is the only one that needs to keep the data, whatever it does is outside of inets. 4) Reading of requests The httpc_handler module will read HTTP responses solely relying on {active once}, using some kind of continuation style parser. This parser generally reads one octet at the time from the binary received from the socket, storing it in an accumulator and continuing with the next. Some experiments have shown that collecting large bodies with {active, once} is quite expensive (CPU wise) (http://code.hellstrom.st/hg.cgi/gen_httpd/file/tip/test/micro_benchmark.erl). But of course, if this process is supposed to answer to other pipelined requests, it can't use passive receive from the socket. I remember there being other issues with the client, such as not persisting connections in case of POST requests, since the concepts of pipelining and persistent connections was mixed up. I don't know if this has been fixed, and I'm too lazy to look in the source for this. Other ppl. have also complained about session_remotely_closed errors (http://www.erlang.org/pipermail/erlang-bugs/2009-April/001269.html) I hope this is useful feedback, as the OTP team asked for feedback on the inets http client earlier (http://erlang.org/pipermail/erlang-bugs/2009-March/001227.html, http://erlang.org/pipermail/erlang-questions/2009-February/041813.html). 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 npolizotis@REDACTED Fri May 15 10:08:40 2009 From: npolizotis@REDACTED (Nikos Polizotis) Date: Fri, 15 May 2009 11:08:40 +0300 Subject: [erlang-bugs] Erlang exits with -detached In-Reply-To: References: Message-ID: Hi, On Windows with version R13-B (binary for Windows installation) starting erl -detached starts the epmd process but exits immediately. Starting werl in the same manner displays an error message. "Failed to execute c:\erl57~1.1\erts-5~1.1\bin\beam.dll: The system cannot find the file specified" Starting up erl without "-detached" works fine. Am I missing something? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From korgulec@REDACTED Mon May 18 16:39:50 2009 From: korgulec@REDACTED (Michal) Date: Mon, 18 May 2009 14:39:50 +0000 Subject: [erlang-bugs] small bug in line numbering. Message-ID: Hi, compiling : -module(tmp). -export([a/1]). a(b) -> gives ./tmp.erl:999999: syntax error before: Michal. From hans.bolinder@REDACTED Mon May 18 16:54:27 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 18 May 2009 16:54:27 +0200 Subject: [erlang-bugs] small bug in line numbering. In-Reply-To: References: Message-ID: <18961.30371.985902.353766@ornendil.du.uab.ericsson.se> Hi, [Michal:] > compiling : > > -module(tmp). > -export([a/1]). > > a(b) -> > > gives > > ./tmp.erl:999999: syntax error before: The error line will be improved upon in the upcoming R13B01 release. Thanks for the report. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From prikrutil@REDACTED Tue May 19 00:24:46 2009 From: prikrutil@REDACTED (Sergey Samokhin) Date: Mon, 18 May 2009 15:24:46 -0700 Subject: [erlang-bugs] [escript] Arguments passed to emulator by "%%!" affect the os:cmd/1 Message-ID: Hello. I find escript awesome when it comes to writing CLI-interfaces. Thanks for it! I tried to use one of new features which R13 (or R12B5?) had introduced and found a bug. Short description: a node started by os:cmd/1 from escript with some "%%!"-arguments passed can't be accessed in the usual manner (net_adm:ping/1, rpc:call/4 etc). I've attached to this letter two almost the same escript's: One of them (start_faulty_node.erl) uses "%%! -smp enable -sname cli" string to give the node short name while other (start_working_node.erl) calls net_kernel:start/1 for that. Both of them are also available at http://gist.github.com/113740 Steps to reproduce: 1. Start start_faulty_node.erl. You will see the following: [prikrutil@REDACTED tmp]$ ./start_faulty_node.erl # I don't see the node. test@REDACTED # But it's still running. You should stop the faulty node by smth like "killall beam.smp" In fact, the child node has been started, but for some reason can't be accessed. Stop it using kill or killall. 2. After stopping node started at Step 1 run start_working_node.erl to make sure that replacing "%%! ..." with net_kenrel:start/1 makes the problem go away: [prikrutil@REDACTED tmp]$ ./start_working_node.erl # Node test@REDACTED has been successfully started, I'll stop it for you. Now it works as it should. Using htop I've found that these two escripts lead to slightly different start commands. start_faulty_node.erl: /usr/lib/erlang/erts-5.7.1/bin/beam.smp -- -root /usr/lib/erlang -progname erl -- -home /home/prikrutil -noshell -noinput -sname test@REDACTED ! -smp enable -sname cli start_working_node.erl: usr/lib/erlang/erts-5.7.1/bin/beam.smp -- -root /usr/lib/erlang -progname erl -- -home /home/prikrutil -noshell -noinput -sname test@REDACTED Take a look at the end of the start_faulty_node.erl's command. "! -smp enable -sname cli" is what differs first command from second one. It must be the key to this problem. It looks like this tail is taken into account by newly started node. For example, if your escript has "%%! -smp disable", then all the nodes started from it by using os:cmd/1 will have smp disabled. Erlang: R13B: Erlang R13B (erts-5.7.1) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] OS: Archlinux current (Linux myhost 2.6.29-ARCH #1 SMP PREEMPT Sat May 9 12:47:43 UTC 2009 i686 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux) -- Sergey Samokhin -------------- next part -------------- A non-text attachment was scrubbed... Name: start_faulty_node.erl Type: application/octet-stream Size: 650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: start_working_node.erl Type: application/octet-stream Size: 665 bytes Desc: not available URL: From geoff.cant@REDACTED Tue May 19 20:17:14 2009 From: geoff.cant@REDACTED (Geoff Cant) Date: Tue, 19 May 2009 20:17:14 +0200 Subject: [erlang-bugs] R13B-0, R12B-5 bug in erlang:memory/1 Message-ID: It appears that erlang:memory(processes_used) incorrectly return 0 instead of the value it returns when included in the erlang:memory() result. This behaviour occurs in R13B: > {erlang:memory(), erlang:memory(processes_used), erlang:memory(processes), erlang:system_info(version)}. {[{total,4354480}, {processes,1104752}, {processes_used,1100128}, {system,3249728}, {atom,308005}, {atom_used,281638}, {binary,18800}, {code,2010109}, {ets,136224}], 0, % <--- incorrect 1104752, % <--- correct "5.7.1"} This behaviour also happens in R12B-5 as far as I can tell. As near as I can tell the problem is here, http://github.com/mfoemmel/erlang-otp/blob/master/erts/emulator/beam/erl_alloc.c#L1768 -- want.processes is not set and/or want.processes_used is not tested. Cheers, -- Geoff Cant From psa@REDACTED Tue May 19 23:43:54 2009 From: psa@REDACTED (=?ISO-8859-1?Q?Paulo_S=E9rgio_Almeida?=) Date: Tue, 19 May 2009 22:43:54 +0100 Subject: [erlang-bugs] Compiler bug Message-ID: <4A13281A.6080103@di.uminho.pt> Hi, when compiling a file under R13B I got a compiler error. I isolated the problem to the file attached below. The compiler crashes as: Function loop/2 refers to undefined label 4 ./bug.erl:none: internal error in beam_peep; crash reason: {{case_clause,{'EXIT',{undefined_label,4}}}, [{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}]} The error goes away if I replace the "case" with the "andalso" or if I replace the invocaton of collect/3 with collect/2. Regards, Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.erl Type: text/x-erlang Size: 426 bytes Desc: not available URL: From rickard.s.green@REDACTED Wed May 20 11:26:57 2009 From: rickard.s.green@REDACTED (Rickard Green) Date: Wed, 20 May 2009 11:26:57 +0200 Subject: [erlang-bugs] R13B-0, R12B-5 bug in erlang:memory/1 Message-ID: <4A13CCE1.70404@ericsson.com> > It appears that erlang:memory(processes_used) incorrectly return 0 > instead of the value it returns when included in the erlang:memory() > result. > > This behaviour occurs in R13B: > >> {erlang:memory(), erlang:memory(processes_used), erlang:memory(processes), erlang:system_info(version)}. > {[{total,4354480}, > {processes,1104752}, > {processes_used,1100128}, > {system,3249728}, > {atom,308005}, > {atom_used,281638}, > {binary,18800}, > {code,2010109}, > {ets,136224}], > 0, % <--- incorrect > 1104752, % <--- correct > "5.7.1"} > > This behaviour also happens in R12B-5 as far as I can tell. > > As near as I can tell the problem is here, > http://github.com/mfoemmel/erlang-otp/blob/master/erts/emulator/beam/erl_alloc.c#L1768 > -- want.processes is not set and/or want.processes_used is not tested. > > Cheers, > -- > Geoff Cant Thanks for the bug report. It will be fixed in R13B01. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From joe@REDACTED Wed May 20 22:57:22 2009 From: joe@REDACTED (Joe Williams) Date: Wed, 20 May 2009 13:57:22 -0700 Subject: [erlang-bugs] clock_gettime stability check locked out for linux In-Reply-To: <4A0C4C92.60207@joetify.com> References: <4A0C4C92.60207@joetify.com> Message-ID: <4A146EB2.7080201@joetify.com> Can anyone give me any insight on this? Thanks. -Joe Joe Williams wrote: > The check for clock_gettime ignores the configure test result for > stability. Discussed in the following thread: > > http://groups.google.com/group/erlang-programming/browse_thread/thread/4f4f5a03fd5c8c6b > > I am interested in whether this is a legitimate issue on linux systems > or an artifact to lock this setting out on older kernels. According to > the libc docs on newer kernels the appropriate clock ids are supported. > If the latter is it possible the check could be adjusted to lock out old > kernels and actually honor the stability test result on newer? > > Any information you have on this is helpful. > > -Joe > > -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ From lfredlund@REDACTED Thu May 21 16:47:31 2009 From: lfredlund@REDACTED (=?ISO-8859-1?Q?Lars-=C5ke_Fredlund?=) Date: Thu, 21 May 2009 16:47:31 +0200 Subject: [erlang-bugs] Core Erlang compilation problem Message-ID: <4A156983.6050604@fi.upm.es> The attached Core Erlang module causes the compiler to crash: 1> compile:file("test.core",[return_errors, from_core]). Function: stop_mp/2 {error, [{"./test.core", [{none,compile, {crash,v3_codegen, {{case_clause, {'EXIT', {function_clause, [{v3_codegen,bif_cg, [element, [{integer,7},{var,'_cor0'}], [], {l,{...},...}, [{...}], {...}|...]}, {v3_codegen,guard_cg,5}, {v3_codegen,'-guard_cg_list/6-anonymous-0-',4}, {v3_codegen,flatmapfoldl,3}, {v3_codegen,guard_cg_list,6}, {v3_codegen,protected_cg,7}, {v3_codegen,guard_clause_cg,4}, {v3_codegen,match_cg,...}]}}}, [{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}]}}}]}], [{"no_file",[{none,sys_core_fold,result_ignored}]}]} 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? /Lars-Ake Fredlund -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.core URL: From tom.mcnulty@REDACTED Fri May 22 01:23:46 2009 From: tom.mcnulty@REDACTED (Tom McNulty) Date: Thu, 21 May 2009 17:23:46 -0600 Subject: [erlang-bugs] gen.erl type error Message-ID: <56A0A61C-1D3E-4562-9E49-36FD11F5EAA3@cetiforge.com> Hi, I am getting dialyzer errors using a GlobalName in gen_server, other than an atom. I tracked the problem to gen.erl:37 -type emgr_name() :: {'local', atom()} | {'global', atom()}. should be: -type emgr_name() :: {'local', atom()} | {'global', term()}. Regards, - Tom From lfredlund@REDACTED Fri May 22 10:30:26 2009 From: lfredlund@REDACTED (=?ISO-8859-1?Q?Lars-=C5ke_Fredlund?=) Date: Fri, 22 May 2009 10:30:26 +0200 Subject: [erlang-bugs] Core Erlang compilation problem In-Reply-To: <4A156983.6050604@fi.upm.es> References: <4A156983.6050604@fi.upm.es> Message-ID: <4A1662A2.90203@fi.upm.es> Lars-?ke Fredlund wrote: > The attached Core Erlang module causes the compiler to crash: > > > > 1> compile:file("test.core",[return_errors, from_core]). > Function: stop_mp/2 > {error, > [{"./test.core", > [{none,compile, > {crash,v3_codegen, > {{case_clause, > {'EXIT', > {function_clause, > [{v3_codegen,bif_cg, > [element, > [{integer,7},{var,'_cor0'}], > [], > {l,{...},...}, > [{...}], > {...}|...]}, > {v3_codegen,guard_cg,5}, > > {v3_codegen,'-guard_cg_list/6-anonymous-0-',4}, > {v3_codegen,flatmapfoldl,3}, > {v3_codegen,guard_cg_list,6}, > {v3_codegen,protected_cg,7}, > {v3_codegen,guard_clause_cg,4}, > {v3_codegen,match_cg,...}]}}}, > [{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}]}}}]}], > [{"no_file",[{none,sys_core_fold,result_ignored}]}]} > > > 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? > > /Lars-Ake Fredlund > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs Oops. A buggy bug report. The correct (failing :-) core module is the following, with the second case still there: And the Erlang/OTP version is: Erlang R13B (erts-5.7.1) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Sorry for the confusion earlier. /Lars-Ake -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.core URL: From pguyot@REDACTED Fri May 22 17:29:01 2009 From: pguyot@REDACTED (Paul Guyot) Date: Fri, 22 May 2009 17:29:01 +0200 Subject: [erlang-bugs] Bug in http client (inets 5.0.13) Message-ID: <9CA52FBB-755C-4A90-82BB-C35A60EE4491@kallisys.net> Hello, There seems to be a bug in http.erl, in function http_options/2, line 368. http_options([{version, Val} | Settings], Acc) when is_atom(Val)-> <====== here http_options(Settings, Acc#http_options{version = Val}); From the documentation, the version is supposed to be a string, not an atom (and passing an atom crashes later). I guess line 368 should just be changed to when is_list(Val)-> Regards, Paul From bgustavsson@REDACTED Mon May 25 07:50:34 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Mon, 25 May 2009 07:50:34 +0200 Subject: [erlang-bugs] Compiler bug In-Reply-To: <4A13281A.6080103@di.uminho.pt> References: <4A13281A.6080103@di.uminho.pt> Message-ID: <6672d0160905242250m4aefd8d0w94f6447de163fdab@mail.gmail.com> 2009/5/19 Paulo S?rgio Almeida : > Hi, > > when compiling a file under R13B I got a compiler error. I isolated the > problem to the file attached below. The compiler crashes as: > Thanks! This bug is already known to us and corrected. The correction will be included in R13B01. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Mon May 25 08:05:28 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Mon, 25 May 2009 08:05:28 +0200 Subject: [erlang-bugs] clock_gettime stability check locked out for linux In-Reply-To: <4A146EB2.7080201@joetify.com> References: <4A0C4C92.60207@joetify.com> <4A146EB2.7080201@joetify.com> Message-ID: <6672d0160905242305t109bdf6ay140d5efc6186f291@mail.gmail.com> On Wed, May 20, 2009 at 10:57 PM, Joe Williams wrote: > Can anyone give me any insight on this? > The original reason for disabling it, if I remember correctly, is that it was not reliable on multi-CPU systems, as mentioned in http://www.linuxhowtos.org/manpages/2/clock_gettime.htm /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From masse@REDACTED Mon May 25 11:43:54 2009 From: masse@REDACTED (mats cronqvist) Date: Mon, 25 May 2009 11:43:54 +0200 Subject: [erlang-bugs] clock_gettime stability check locked out for linux In-Reply-To: <6672d0160905242305t109bdf6ay140d5efc6186f291@mail.gmail.com> (Bjorn Gustavsson's message of "Mon\, 25 May 2009 08\:05\:28 +0200") References: <4A0C4C92.60207@joetify.com> <4A146EB2.7080201@joetify.com> <6672d0160905242305t109bdf6ay140d5efc6186f291@mail.gmail.com> Message-ID: <87k545v7ol.fsf@sterlett.hq.kred> Bjorn Gustavsson writes: > On Wed, May 20, 2009 at 10:57 PM, Joe Williams wrote: >> Can anyone give me any insight on this? >> > > The original reason for disabling it, if I remember correctly, is that > it was not reliable on multi-CPU systems, as mentioned in > > http://www.linuxhowtos.org/manpages/2/clock_gettime.htm that note is quite old; "2004-08-06 Christoph Lameter , SMP note" also, if i read the note correctly, there is a way to test for the condition, "clock_getcpuclockid(0) will return ENOENT to signify this ." I can see no trace of the config testing for this. mats From zerthurd@REDACTED Tue May 26 11:16:17 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Tue, 26 May 2009 16:16:17 +0700 Subject: [erlang-bugs] ASN.1 compiler does not support multiline comments Message-ID: Hello ASN.1compiler from OTP does not handles /* multiline comments */ I have tried to fix it but it seems not so easy without some global changes in lexical scanner (asn1ct_tok) due to line-by-line reading of file. Thank you -- Maxim Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Tue May 26 16:55:44 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 26 May 2009 16:55:44 +0200 Subject: [erlang-bugs] ASN.1 compiler does not support multiline comments In-Reply-To: References: Message-ID: Hi, I would not call this a bug. It is rather that the Erlang ASN.1 compiler does not support the ASN.1 standard from 2002 (or very little of it). We have so far not seen the need to support the 2002 specs of ASN.1 (where multi-line comments and other things where introduced). Do you have an example of standard protocol specified using ASN.1 (2002)? Or are you creating your own ASN.1 specifications? /Kenneth On Tue, May 26, 2009 at 11:16 AM, Maxim Treskin wrote: > Hello > > ASN.1compiler from OTP does not handles /* multiline comments */ > I have tried to fix it but it seems not so easy without some global changes > in lexical scanner (asn1ct_tok) due to line-by-line reading of file. > > Thank you > > -- > Maxim Treskin > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From jwebb@REDACTED Wed May 27 04:45:03 2009 From: jwebb@REDACTED (John Webb) Date: Wed, 27 May 2009 11:45:03 +0900 Subject: [erlang-bugs] ASN.1 compiler does not support multiline comments In-Reply-To: References: Message-ID: <7ACA3E22-8607-454D-9DAE-94EA43B2F6BA@gol.com> Maxim, You may like to try the attached patch for the tokenizer e.g. $ cd $(ERL_TOP)/lib/asn1 $ patch asn1ct_tok.erl < asn1ct_tok.patch It is my shot at implementing nested, multiline comments from the 2002 standard. Useful when debugging specs or excluding unwanted chunks from large ones. The patch was made against asn1-1.6.10. Hope it is of some use, John Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: asn1ct_tok.patch Type: application/octet-stream Size: 1721 bytes Desc: not available URL: -------------- next part -------------- On May 26, 2009, at 11:55 PM, Kenneth Lundin wrote: > Hi, > > I would not call this a bug. It is rather that the Erlang ASN.1 > compiler does not support > the ASN.1 standard from 2002 (or very little of it). > > We have so far not seen the need to support the 2002 specs of ASN.1 > (where > multi-line comments and other things where introduced). > > Do you have an example of standard protocol specified using ASN.1 > (2002)? > Or are you creating your own ASN.1 specifications? > > /Kenneth > > On Tue, May 26, 2009 at 11:16 AM, Maxim Treskin > wrote: >> Hello >> >> ASN.1compiler from OTP does not handles /* multiline comments */ >> I have tried to fix it but it seems not so easy without some global >> changes >> in lexical scanner (asn1ct_tok) due to line-by-line reading of file. >> >> Thank you >> >> -- >> Maxim Treskin >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From carlmcdade@REDACTED Sat May 30 09:53:56 2009 From: carlmcdade@REDACTED (Carl McDade) Date: Sat, 30 May 2009 09:53:56 +0200 Subject: #exec in CGI directive in INETS does not work Message-ID: Hi, Windows XP sp3 Python (python.exe) MinGW GNU Bash for Windows (sh.exe) Erlang R13B I am running the inets examples and have not had any luck with getting CGI to work. The exec.shtml parses but the command tag #exec cgi="" is not functioning. All other directives work. exec.shtml: /exec.shtml

/exec.shtml
python.py: #!C:/Python30/python.exe -u print '' print 'My Page' print '' print '

Powers of two

\n
    ' for n in range(1,11): print '
  1. '+str(2**n)+'
    2. ' print '
' printenv.sh: #!C:/MinGW/bin/bash echo "Content-type: text/html" echo "" echo " OS Environment 
"
env
echo "
" inets conf: ScriptAlias /cgi-bin/ c:/var/tmp/server_root/cgi-bin/ mime.types: application/x-sh sh application/x-python py All the other CGI directives (include... etc.) work but exec only leads to this dead end. /exec.shtml [an error occurred while processing this directive] -- Carl McDade Content Management Systems Consultant www.hiveminds.co.uk ________________________ From akitada@REDACTED Sat May 30 18:51:18 2009 From: akitada@REDACTED (Akira Kitada) Date: Sun, 31 May 2009 01:51:18 +0900 Subject: Segmentation faul when building R13B on FreeBSD 4.11 with gcc 2.95.4 Message-ID: <90bb445a0905300951j79825a61ibfa335bd4aa7eddf@mail.gmail.com> Hi, I got the following error when compiling R13B on FreeBSD 4.11 with gcc 2.95.4. """ gmake[4]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/etc/common' gmake[3]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/etc/common' gmake[2]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/etc' gmake[2]: Entering directory `/usr/home/build/dev/otp_src_R13B/erts/epmd' gmake[3]: Entering directory `/usr/home/build/dev/otp_src_R13B/erts/epmd/src' gmake -f i386-unknown-freebsd4.11/Makefile TYPE=opt gmake[4]: Entering directory `/usr/home/build/dev/otp_src_R13B/erts/epmd/src' gcc -g -O2 -I/usr/home/build/dev/otp_src_R13B/erts/i386-unknown-freebsd4.11 -DHAVE_CONFIG_H -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -DEPMD_PORT_NO=4369 -o /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd.o -c epmd.c gcc -g -O2 -I/usr/home/build/dev/otp_src_R13B/erts/i386-unknown-freebsd4.11 -DHAVE_CONFIG_H -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -DEPMD_PORT_NO=4369 -o /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd_cli.o -c epmd_cli.c gcc -g -O2 -I/usr/home/build/dev/otp_src_R13B/erts/i386-unknown-freebsd4.11 -DHAVE_CONFIG_H -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -DEPMD_PORT_NO=4369 -o /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd_srv.o -c epmd_srv.c gcc -o /usr/home/build/dev/otp_src_R13B/bin/i386-unknown-freebsd4.11/epmd /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd.o /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd_cli.o /usr/home/build/dev/otp_src_R13B/erts/obj/i386-unknown-freebsd4.11/epmd_srv.o -lutil -lm gmake[4]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/epmd/src' gmake[3]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/epmd/src' gmake[2]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/epmd' gmake[2]: Entering directory `/usr/home/build/dev/otp_src_R13B/erts/lib_src' gmake -f i386-unknown-freebsd4.11/Makefile TYPE=opt gmake[3]: Entering directory `/usr/home/build/dev/otp_src_R13B/erts/lib_src' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/lib_src' gmake[2]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts/lib_src' gmake[1]: Leaving directory `/usr/home/build/dev/otp_src_R13B/erts' cd lib && \ ERL_TOP=/usr/home/build/dev/otp_src_R13B PATH=/usr/home/build/dev/otp_src_R13B/bootstrap/bin:${PATH} \ gmake opt SECONDARY_BOOTSTRAP=true gmake[1]: Entering directory `/usr/home/build/dev/otp_src_R13B/lib' gmake[2]: Entering directory `/usr/home/build/dev/otp_src_R13B/lib/parsetools' === Entering application parsetools gmake[3]: Entering directory `/usr/home/build/dev/otp_src_R13B/lib/parsetools/src' erlc -W +debug_info +warn_obsolete_guard -I/usr/home/build/dev/otp_src_R13B/lib/stdlib/include -o../ebin yecc.erl gmake[3]: *** [../ebin/yecc.beam] Segmentation fault (core dumped) gmake[3]: Leaving directory `/usr/home/build/dev/otp_src_R13B/lib/parsetools/src' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/usr/home/build/dev/otp_src_R13B/lib/parsetools' gmake[1]: *** [opt] Error 2 gmake[1]: Leaving directory `/usr/home/build/dev/otp_src_R13B/lib' gmake: *** [secondary_bootstrap_build] Error 2 """ You can reproduce this simply by doing "./configure && gmake". Note that I do not get this error when building R12B5 on the same environment. Best regards From smith.winston.101@REDACTED Sun May 31 07:17:32 2009 From: smith.winston.101@REDACTED (Winston Smith) Date: Sun, 31 May 2009 01:17:32 -0400 Subject: eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap") // R13B cross-compiled on avr32-linux Message-ID: I'm hoping for a little advice with getting Erlang R13B working on Atmel's AVR32/Linux [http://avr32linux.org] based NGW100 development board [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102]. ?The NGW100 is based on a buildroot [http://buildroot.uclibc.org/] cross compiler system, which seems to be fairly widely used with embedded systems. I based the erlang.mk on?Brian Zhou's?NSLU2-Linux Erlang makefile [http://svn.nslu2-linux.org/svnroot/optware/trunk/make/erlang.mk] and was able to cross compile Erlang for the avr32-linux system using Ubuntu 9.04 (x86) as a host. Once booted on the NGW100, running 'erl' crashes with: /home/avr32 # erl Crash dump was written to: erl_crash.dump eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap") Aborted The system version reported in erl_crash.dump is: System version: Erlang R13B (erts-5.7.1) [source] [rq:1] [async:threads:0] [kernel-poll:false] It seems that 3,480,006,320 bytes of memory is somewhat excessive for an embedded system, so I suspect there's some kind of overflow issue. The .dump file is 55k; if it's useful, I can provide it. I'm somewhat new to Erlang, so I'm not sure where to start looking -- any advice? Is there a way to build a diagnostic version that might yield more clues? Many thanks! W.