From kruskakli@REDACTED Tue Nov 8 13:22:37 2011 From: kruskakli@REDACTED (etnt) Date: Tue, 8 Nov 2011 13:22:37 +0100 Subject: [erlang-bugs] ssl badarith In-Reply-To: <4E9E73F1.3070708@erix.ericsson.se> References: <4E9E73F1.3070708@erix.ericsson.se> Message-ID: Hi. I don't want to do any tracing like that in our production system. But it must be the #session.timestamp that is a non-integer (unset?). For example: 1> rr(ssl_session). 2> catch ssl_session:valid_session(#session{}, 3600). {'EXIT',{badarith,[{ssl_session,valid_session,2}, {erl_eval,do_apply,5}, {erl_eval,expr,5}, {shell,exprs,7}, {shell,eval_exprs,7}, {shell,eval_loop,3}]}} So perhaps you can figure out a way for the timestamp to not be set properly. --Tobbe On Wed, Oct 19, 2011 at 8:53 AM, Ingela Anderton Andin < ingela@REDACTED> wrote: > Hi! > > It is always good to check if the problem is in the latest release (R14B03 > was alas not a very good ssl-release). > If the problem should still be there could you use the following trace > commands > > dbg:tracer(). > dbg:p(all, [call]). > dbg:tpl(ssl_session, x). > > to see if you can get some more information. > > Regards Ingela Erlang OTP/team -Ericsson AB > > etnt wrote: > >> Hi, >> >> We are getting lots of error messages like this: >> >> == 18-Oct-2011::14:11:00 == ERROR - emulator >> Error in process <0.27172.1216> on node 'xxx@REDACTED' with exit value: >> {badarith,[{ssl_session,valid_**session,2},{ssl_manager,** >> validate_session,3},{ssl_**manager,session_validation,2},** >> {lists,foldl,3},{ets,do_foldl,**4},{ets,foldl,3}]} >> >> That 'badarith' doesn't look good. >> We are running R14B03. >> >> Cheers, K. >> ------------------------------**------------------------------** >> ------------ >> >> >> ______________________________**_________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-bugs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.lindberg@REDACTED Wed Nov 9 11:22:03 2011 From: adam.lindberg@REDACTED (Adam Lindberg) Date: Wed, 09 Nov 2011 10:22:03 -0000 (GMT) Subject: [erlang-bugs] erlc -smp flag is broken In-Reply-To: <0497ec64-3746-434c-8944-27499fb585de@knuth> Message-ID: <73c43499-c426-4eee-9cb9-4f060c7beee3@knuth> Hi, The -smp flag to erlc is broken/unnecessary on most systems (those that default to SMP) since the SMP emulator is chosen when running erlc on those systems anyway. The workaround is to set the ERLC_EMULATOR environment variable to "erl -smp disable". It would, however, be nice if the -smp flag to erlc could take the same parameters as for erl (enable, disable and auto) instead of removing the flag altogether. Cheers, Adam From dmitry.sensei@REDACTED Wed Nov 9 14:22:46 2011 From: dmitry.sensei@REDACTED (Dmitry Orlov) Date: Wed, 9 Nov 2011 18:22:46 +0500 Subject: [erlang-bugs] I cannot build erlang R14B04 on OpenBSD 5.0 Message-ID: <20111109182246.49d78375.dmitry.sensei@gmail.com> I cannot build erlang R14B04 on OpenBSD 5.0/ Firstly, I got warning from 'configure' checking sys/sysctl.h usability... no checking sys/sysctl.h presence... yes ........... configure: WARNING: sys/sysctl.h: present but cannot be compiled Secondly, after gmake ran I got error cc1plus: out of memory allocating 219008 bytes after a total of 0 bytes gmake[3]: *** [i386-unknown-openbsd5.0/wxe_funcs.o] Error 1 gmake[2]: *** [opt] Error 2 gmake[1]: *** [opt] Error 2 gmake: *** [libs] Error 2 For R14B03 build process on OpenBSD 4.9 was ok Please fix this errors -- Dmitry Orlov From raimo+erlang-bugs@REDACTED Wed Nov 9 15:45:48 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 9 Nov 2011 15:45:48 +0100 Subject: [erlang-bugs] I cannot build erlang R14B04 on OpenBSD 5.0 In-Reply-To: <20111109182246.49d78375.dmitry.sensei@gmail.com> References: <20111109182246.49d78375.dmitry.sensei@gmail.com> Message-ID: <20111109144548.GA15480@erix.ericsson.se> On Wed, Nov 09, 2011 at 06:22:46PM +0500, Dmitry Orlov wrote: > I cannot build erlang R14B04 on OpenBSD 5.0/ > Firstly, I got warning from 'configure' > checking sys/sysctl.h usability... no > checking sys/sysctl.h presence... yes > ........... > configure: WARNING: sys/sysctl.h: present but cannot be compiled Do you build from tarball with configure, make, ... or do you firstly use autoconf and if so which is your autoconf version? We see this warning in our daily builds where we use autoconf 2.59. It might be fixed in a later release of autoconf. > > Secondly, after gmake ran I got error > > cc1plus: out of memory allocating 219008 bytes after a total of 0 bytes > gmake[3]: *** [i386-unknown-openbsd5.0/wxe_funcs.o] Error 1 > gmake[2]: *** [opt] Error 2 > gmake[1]: *** [opt] Error 2 > gmake: *** [libs] Error 2 The C preprocessor runs out of memory. You seem to have to low limits on your account class. The defaults for OpenBSD 5.0 are (I think): $ ulimit -d 524288 $ulimit -v 1048576 You need to crank them up for your login class in /etc/login.conf, e.g: :datasize=1024M:\ :vmemoryuse=2048M:\ or give your login class e.g 'staff' and then raise your current limit: $ ulimit -d 1048576. I think it is the datasize that is your current problem, not sure about vmemoryuse. > > For R14B03 build process on OpenBSD 4.9 was ok > I think the wxe_funcs.c compilation was maybe not as memory hungry for R14B03, or the defaults in /etc/login.conf were different, or the compiler in OpenBSD 4.9 was different... Speculations... > Please fix this errors > -- > Dmitry Orlov > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From daniel.goertzen@REDACTED Wed Nov 9 21:00:59 2011 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 9 Nov 2011 14:00:59 -0600 Subject: [erlang-bugs] open_port() slow on Windows In-Reply-To: References: Message-ID: I've figured the Windows open_port() delay problem and will document the issue here in case anyone else trips on it. The function create_child_process() in erts/ermulator/sys/win32/sys.c makes the following call after the port process has been created: WaitForInputIdle(piProcInfo.hProcess, 5000); What this does is wait for the Windows message loop in the port process to become active. If the port process doesn't start a message loop right away (or ever), WaitForInputIdle(), and hence open_port() will just hang for up to 5 sec. A partial work-around for this problem is to have the port program do a single iteration through the Windows message loop early in its life. In my Python/PyQt port program this was achieved with: app = QtGui.QApplication(sys.argv) app.processEvents() Apparently the purpose of the WaitForInputIdle() call was to address a memory leak problem in Windows NT 3.5 ( http://support.microsoft.com/kb/124121) . This has been fixed in NT 3.5 and everything following, so it is probably time to do away with the WaitForInputIdle() call so nobody else gets burnt by this issue. Dan. On Tue, Nov 8, 2011 at 4:19 PM, Daniel Goertzen wrote: > I am observing slow behavior for open_port() on Windows. The port program > itself starts up quickly, but open_port() itself hangs for several seconds > before returning... long after the port program is up and running. > > > Here is my instrumented Erlang code.... > > io:format("~p opening port~n",[now()]), > Port=open_port( {spawn_executable, Exe}, > [ > {cd, Dir}, > {args, Args}, > stream, > binary, > exit_status > ]), > io:format("~p done port~n",[now()]), > > > My port program is a python PyQt program. One of the first things I have > it do is... > > logfile = open("c:\\logfile.txt","w") > print(time.time(), "starting", file=logfile) > > > > The output of my Erlang code interspersed with the above starting message > is.... > > {1320,789477,830000} opening port [werl.exe] > 1320789478.968 starting [my_port_program.exe] > {1320,789483,337000} done port [werl.exe] > > > > Any idea why open_port() waits for so long before returning? > > > Thanks, > Dan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Sun Nov 13 11:57:31 2011 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 13 Nov 2011 11:57:31 +0100 Subject: [erlang-bugs] mnesia:dirty_update_counter/3 doesn't work on ordered sets Message-ID: The function mnesia:dirty_update_counter/3 checks the type of the table, and only wants to work for Type==set. However, ordered_set tables also have 'set' semantics, and are perfectly capable of supporting update_counter/3. Eshell V5.8.4 (abort with ^G) (foo@REDACTED)1> mnesia:start(). ok (foo@REDACTED)2> mnesia:create_table(t,[{type,ordered_set}]). {atomic,ok} (foo@REDACTED)3> mnesia:dirty_update_counter(t,a,1). ** exception exit: {aborted,{combine_error,t,update_counter}} in function mnesia:abort/1 (foo@REDACTED)4> mnesia:create_table(u,[{type,set}]). {atomic,ok} (foo@REDACTED)5> mnesia:dirty_update_counter(u,a,1). 1 The reason for this is the following code in mnesia.erl: do_dirty_update_counter(SyncMode, Tab, Key, Incr) when is_atom(Tab), Tab /= schema, is_integer(Incr) -> case ?catch_val({Tab, record_validation}) of {RecName, 3, set} -> Oid = {Tab, Key}, mnesia_tm:dirty(SyncMode, {Oid, {RecName, Incr}, update_counter}); _ -> abort({combine_error, Tab, update_counter}) end; If it were to be changed to do_dirty_update_counter(SyncMode, Tab, Key, Incr) when is_atom(Tab), Tab /= schema, is_integer(Incr) -> case ?catch_val({Tab, record_validation}) of {RecName, 3, Type} when Type==set; Type==ordered_set -> ... end; ?it would work as expected, IMHO. :) No patch - apologies, but I'm knee-deep in other stuff atm. BR, Ulf W From ingela@REDACTED Tue Nov 15 10:56:40 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 15 Nov 2011 10:56:40 +0100 Subject: [erlang-bugs] ssl badarith In-Reply-To: References: <4E9E73F1.3070708@erix.ericsson.se> Message-ID: <4EC23758.3010801@erix.ericsson.se> Hi! etnt wrote: > Hi. > > I don't want to do any tracing like that in our production system. I see, we actually got a report about this problem last week from a customer that also could easily reproduce it in there lab and do the trace :). > But it must be the #session.timestamp that is a non-integer (unset?). Well yes I agree. > > So perhaps you can figure out a way for the timestamp to not be set > properly. I figured it out and got it confirmed with trace from our customer and the fix will be in R15. Regards Ingela Erlang/OTP team - Ericsson AB From fritchie@REDACTED Tue Nov 15 22:01:05 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 15 Nov 2011 15:01:05 -0600 Subject: [erlang-bugs] Test suite status for "master"/R15A? Message-ID: <2813.1321390865@snookles.snookles.com> Hi, all. I'm not quite certain if this is the best forum for this question, but I'll try anyway. What should I be expecting the status of the full Erlang/OTP test suite to be for the "master" branch a.k.a. R15A? I just ran a complete set of tests, per the instructions over at https://github.com/erlang/otp/wiki/Running-tests. I checked out the "master" branch of the OTP repo, with this as the last commit: # git log | head -6 commit 9169a0322066614373ef2d602325e02e90ffc597 Merge: 6acdb64 5fbadf9 Author: Micael Karlberg Date: Mon Nov 14 17:06:17 2011 +0100 Merge branch 'bmk/megaco/r15_integration' ... and built on a 64-bit CentOS 5 machine (well, a virtual machine) with 2GB of RAM and 2 virtual i686 CPUs. After about 7 hours of runtime, I see that test_server/index.html reports: OK: 9780 Failed: 292 Skipped (User/Auto): 1228 (544/684) Missing suites: 12 According to the wiki: "There will currently be 15 or so failed test cases in the kernel application." Have I managed to do something bad/stupid with my test environment, or are the 292 failures about right for the current R15A code? -Scott From wallentin.dahlberg@REDACTED Tue Nov 15 22:56:50 2011 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 15 Nov 2011 22:56:50 +0100 Subject: [erlang-bugs] Test suite status for "master"/R15A? In-Reply-To: <2813.1321390865@snookles.snookles.com> References: <2813.1321390865@snookles.snookles.com> Message-ID: The statement regarding stability are for a released and tagged Erlang/OTP, i.e. OTP_R14B04, OTP_R14B03. You can expect less stability during development and especially between major versions, e.g. R14 -> R15. That said, we try to make things in master as stable as possible. It must compile and known issues must be resolved before merged to our development branches, but things do slip between the cracks. The number of failures of an entire run usually varies between hardware, os, environment etc. But the most I have seen have been nowhere near 292 failures. I think the highest i've ever seen have been around 200 and that was with native compiled stdlib and kernel and a faulty openssl. I don't have the figures in front of me but emulator, kernel and stdlib runs more or less clean. System has some undefined functions and MIB compiler error (faulty testcase). Corba and cos* has some issues in current master if I remember correctly. If inets, ssl or ssh are bonkers that usually mean a bad environment. // Bj?rn-Egil 2011/11/15 Scott Lystig Fritchie > Hi, all. I'm not quite certain if this is the best forum for this > question, but I'll try anyway. What should I be expecting the status of > the full Erlang/OTP test suite to be for the "master" branch > a.k.a. R15A? > > I just ran a complete set of tests, per the instructions over at > https://github.com/erlang/otp/wiki/Running-tests. I checked out the > "master" branch of the OTP repo, with this as the last commit: > > # git log | head -6 > commit 9169a0322066614373ef2d602325e02e90ffc597 > Merge: 6acdb64 5fbadf9 > Author: Micael Karlberg > Date: Mon Nov 14 17:06:17 2011 +0100 > > Merge branch 'bmk/megaco/r15_integration' > > ... and built on a 64-bit CentOS 5 machine (well, a virtual machine) > with 2GB of RAM and 2 virtual i686 CPUs. After about 7 hours of > runtime, I see that test_server/index.html reports: > > OK: 9780 > Failed: 292 > Skipped (User/Auto): 1228 (544/684) > Missing suites: 12 > > According to the wiki: > > "There will currently be 15 or so failed test cases in the kernel > application." > > Have I managed to do something bad/stupid with my test environment, or > are the 292 failures about right for the current R15A code? > > -Scott > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From caox@REDACTED Wed Nov 16 10:31:56 2011 From: caox@REDACTED (caox) Date: Wed, 16 Nov 2011 17:31:56 +0800 Subject: [erlang-bugs] Fwd: Inets(5.5.1) http client keep alive mode doesn't follow RFC2616 References: Message-ID: <6C827D0F-815B-4070-A5CE-280F1406ABF4@lightpole.net> Hi, Have this bug been fixed in the latest version? B.R. ?????????? > ???: caox > ??: 2011?8?16? ??05?45?27?????????+0800 > ???: Ingela Anderton Andin > ??: Micael Karlberg > ??: ??? Inets(5.5.1) http client keep alive mode doesn't follow RFC2616 > > Thanks. > > ? 2011-8-16???5:28? Ingela Anderton Andin ??? > >> Hi! >> >> Well it looks like a bug to me, probably a slip up during a refactoring >> of the code. >> I have created a ticket for it to be solved for the next release. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> caox wrote: >>> Sorry to bother you. But I have some questions of inets http client as >>> below. And I found you in the author list of inets so I sent this to you. >>> >>> ?????????? >>> >>>> *???: *caox > >>>> *??: *2011?8?14???11?32?57?????????+0800 >>>> *???: *erlang-bugs@REDACTED >>>> *??: **Inets(5.5.1) http client keep alive mode doesn't follow RFC2616* >>>> >>>> Hi >>>> >>>> According to RFC2616, a HTTP/1.1 client should send a request and >>>> then wait for the response before sending any subsequent request on a >>>> persistent connection if without pipelining. >>>> But when using inets5.5.1 of R14B01, we found httpc send requests >>>> directly to the connection without checking whether the earlier >>>> request on it has been responded. According to the TCP packets we >>>> captured from web communication, several requests were passed on the >>>> same connection in one TCP packet and it seems worked in pipelining >>>> mode. And we use the default inets opiton setting so the pipelining >>>> should be off in the situation. >>>> Also, we follow the source code of inets implementation and do not >>>> find any significant difference between keep alive and pipelining in >>>> the sending mechanism. In both mode httpc_manager:handle_request call >>>> httpc_handler:send, and in httpc_handler:send pipelining and keep >>>> alive requests will be queued in different queue in the process state >>>> and then sent to current connection of handler by httpc_request:send >>>> and then httpc_transport:send. >>>> So,it is a bug, or there is something I have missed in the source code? >>>> >>>> BR >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Wed Nov 16 10:44:56 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 16 Nov 2011 10:44:56 +0100 Subject: [erlang-bugs] Test suite status for "master"/R15A? In-Reply-To: References: <2813.1321390865@snookles.snookles.com> Message-ID: <4EC38618.8010107@erlang.org> Now that the ssl fixes where merged to 'master' the test fails for 'pu' on my local build dropped "abit" Latest Test Result (56 failures / -171). So if you are using the new version of OpenSSL you might see a drop after yesterdays push On 11/15/2011 10:56 PM, Bj?rn-Egil Dahlberg wrote: > The statement regarding stability are for a released and tagged > Erlang/OTP, i.e. OTP_R14B04, OTP_R14B03. > > You can expect less stability during development and especially > between major versions, e.g. R14 -> R15. That said, we try to make > things in master as stable as possible. It must compile and known > issues must be resolved before merged to our development branches, but > things do slip between the cracks. > > The number of failures of an entire run usually varies between > hardware, os, environment etc. But the most I have seen have been > nowhere near 292 failures. I think the highest i've ever seen have > been around 200 and that was with native compiled stdlib and kernel > and a faulty openssl. I don't have the figures in front of me but > emulator, kernel and stdlib runs more or less clean. System has some > undefined functions and MIB compiler error (faulty testcase). Corba > and cos* has some issues in current master if I remember correctly. If > inets, ssl or ssh are bonkers that usually mean a bad environment. > > // Bj?rn-Egil > > > 2011/11/15 Scott Lystig Fritchie > > > Hi, all. I'm not quite certain if this is the best forum for this > question, but I'll try anyway. What should I be expecting the > status of > the full Erlang/OTP test suite to be for the "master" branch > a.k.a. R15A? > > I just ran a complete set of tests, per the instructions over at > https://github.com/erlang/otp/wiki/Running-tests. I checked out the > "master" branch of the OTP repo, with this as the last commit: > > # git log | head -6 > commit 9169a0322066614373ef2d602325e02e90ffc597 > Merge: 6acdb64 5fbadf9 > Author: Micael Karlberg > > Date: Mon Nov 14 17:06:17 2011 +0100 > > Merge branch 'bmk/megaco/r15_integration' > > ... and built on a 64-bit CentOS 5 machine (well, a virtual machine) > with 2GB of RAM and 2 virtual i686 CPUs. After about 7 hours of > runtime, I see that test_server/index.html reports: > > OK: 9780 > Failed: 292 > Skipped (User/Auto): 1228 (544/684) > Missing suites: 12 > > According to the wiki: > > "There will currently be 15 or so failed test cases in the kernel > application." > > Have I managed to do something bad/stupid with my test environment, or > are the 292 failures about right for the current R15A code? > > -Scott > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From eurekafag@REDACTED Wed Nov 16 17:45:45 2011 From: eurekafag@REDACTED (eurekafag) Date: Wed, 16 Nov 2011 20:45:45 +0400 Subject: [erlang-bugs] Unicode bug in io:format Message-ID: I described the problem here thinking it's some kind of misunderstanding but it looks like it's a bug: http://erlang.org/pipermail/erlang-questions/2011-November/062508.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Thu Nov 17 06:29:21 2011 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 16 Nov 2011 23:29:21 -0600 Subject: [erlang-bugs] Test suite status for "master"/R15A? In-Reply-To: Message of "Tue\, 15 Nov 2011 22\:56\:50 +0100." Message-ID: <37798.1321507761@snookles.snookles.com> Bj?rn-Egil Dahlberg wrote: b-ed> The number of failures of an entire run usually varies between b-ed> hardware, os, environment etc. But the most I have seen have been b-ed> nowhere near 292 failures. I think the highest i've ever seen have b-ed> been around 200 and that was with native compiled stdlib and b-ed> kernel and a faulty openssl. I don't have the figures in front of b-ed> me but emulator, kernel and stdlib runs more or less clean. System b-ed> has some undefined functions and MIB compiler error (faulty b-ed> testcase). Corba and cos* has some issues in current master if I b-ed> remember correctly. If inets, ssl or ssh are bonkers that usually b-ed> mean a bad environment. Hi, thanks for the data points. I re-ran the full battery of tests last night using the R15A "master" branch as of 15 Nov 2011, on a CentOS 5 64-bit virtual machine. I'm wondering if there is either: 1. Weird interactions between the guest OS system clock & host OS system clock & Erlang's timekeeping, or 2. Odd timing bugs in the test suite. ... because some of last night's failures aren't repeatable, if I just run the single test (or a single suite) by itself. I'm going to assume #1 right now, unless you happen to know that #2 is a real possibility? Overall, I saw 135 failures. A not-so-wonderful text rendering of the top-level index.html file is included below, for the curious. -Scott --- snip --- snip --- snip --- snip --- snip --- Test Results All test runs in "test_server" Test Name Label Test Run Started _Ok_ Failed Skipped (User/Auto) Missing Suites Node CT Log Old Runs tests.asn1_test - Wed Nov 16 2011 13:16:06 349 0 2 (2/0) 0 test_server@REDACTED CT Log none tests.common_test_test - Wed Nov 16 2011 14:44:25 116 13 0 (0/0) 0 test_server@REDACTED CT Log none tests.compiler_test - Wed Nov 16 2011 12:23:00 850 0 12 (12/0) 0 test_server@REDACTED CT Log none tests.cosEventDomain_test - Wed Nov 16 2011 14:58:21 18 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.cosEvent_test - Wed Nov 16 2011 14:57:47 23 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.cosFileTransfer_test - Wed Nov 16 2011 14:58:38 1 0 7 (7/0) 0 test_server@REDACTED CT Log none tests.cosNotification_test - Wed Nov 16 2011 14:58:43 114 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.cosProperty_test - Wed Nov 16 2011 15:06:44 33 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.cosTime_test - Wed Nov 16 2011 15:06:47 12 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.cosTransactions_test - Wed Nov 16 2011 15:07:33 27 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.crypto_test - Wed Nov 16 2011 15:08:09 53 0 1 (1/0) 0 test_server@REDACTED CT Log none tests.debugger_test - Wed Nov 16 2011 12:33:22 179 1 28 (28/0) 0 test_server@REDACTED CT Log none tests.dialyzer_test - Wed Nov 16 2011 15:08:13 247 1 1 (1/0) 0 test_server@REDACTED CT Log none tests.diameter_test - Wed Nov 16 2011 15:38:30 63 0 4 (4/0) 5 test_server@REDACTED CT Log none tests.edoc_test - Wed Nov 16 2011 15:43:44 1 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.emulator_test - Wed Nov 16 2011 10:58:18 928 3 10 (10/0) 0 test_server@REDACTED CT Log none tests.epmd_test - Wed Nov 16 2011 15:43:48 26 0 2 (2/0) 0 test_server@REDACTED CT Log none tests.erl_interface_test - Wed Nov 16 2011 12:27:23 98 5 0 (0/0) 0 test_server@REDACTED CT Log none tests.et_test - Wed Nov 16 2011 15:48:09 0 0 1 (0/1) 0 test_server@REDACTED CT Log none tests.eunit_test - Wed Nov 16 2011 15:48:10 1 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.ic_test - Wed Nov 16 2011 12:33:52 213 11 18 (0/18) 0 test_server@REDACTED CT Log none tests.inets_test - Wed Nov 16 2011 12:55:00 167 1 698 (2/696) 0 test_server@REDACTED CT Log none tests.inviso_test - Wed Nov 16 2011 15:48:11 6 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.jinterface_test - Wed Nov 16 2011 12:28:29 0 42 2 (2/0) 0 test_server@REDACTED CT Log none tests.kernel_test - Wed Nov 16 2011 11:30:28 552 4 42 (15/27) 0 test_server@REDACTED CT Log none tests.megaco_test - Wed Nov 16 2011 15:48:31 709 2 278 (36/242) 0 test_server@REDACTED CT Log none tests.mnesia_test - Wed Nov 16 2011 14:14:41 431 0 147 (147/0) 0 test_server@REDACTED CT Log none tests.observer_test - Wed Nov 16 2011 16:15:01 57 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.odbc_test - Wed Nov 16 2011 16:17:31 0 0 101 (0/101) 0 test_server@REDACTED CT Log none tests.orber_test - Wed Nov 16 2011 12:34:34 252 13 0 (0/0) 0 test_server@REDACTED CT Log none tests.os_mon_test - Wed Nov 16 2011 13:44:44 24 13 3 (2/1) 0 test_server@REDACTED CT Log none tests.parsetools_test - Wed Nov 16 2011 12:33:15 29 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.percept_test - Wed Nov 16 2011 16:17:33 10 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.public_key_test - Wed Nov 16 2011 16:17:36 25 0 36 (0/36) 0 test_server@REDACTED CT Log none tests.reltool_test - Wed Nov 16 2011 16:18:28 9 6 2 (1/1) 0 test_server@REDACTED CT Log none tests.runtime_tools_test - Wed Nov 16 2011 12:30:30 49 3 1 (1/0) 0 test_server@REDACTED CT Log none tests.sasl_test - Wed Nov 16 2011 12:28:35 63 6 0 (0/0) 0 test_server@REDACTED CT Log none tests.snmp_test - Wed Nov 16 2011 13:44:58 331 1 27 (27/0) 0 test_server@REDACTED CT Log none tests.ssh_test - Wed Nov 16 2011 16:21:50 1 0 53 (0/53) 0 test_server@REDACTED CT Log none tests.ssl_test - Wed Nov 16 2011 16:21:52 202 0 4 (3/1) 0 test_server@REDACTED CT Log none tests.stdlib_test - Wed Nov 16 2011 11:56:36 955 3 8 (6/2) 0 test_server@REDACTED CT Log none tests.syntax_tools_test - Wed Nov 16 2011 16:25:09 1 0 0 (0/0) 0 test_server@REDACTED CT Log none tests.system_test - Wed Nov 16 2011 16:28:54 57 4 1 (1/0) 0 test_server@REDACTED CT Log none tests.test_server_test - Wed Nov 16 2011 11:28:45 5 1 2 (0/2) 0 test_server@REDACTED CT Log none tests.tools_test - Wed Nov 16 2011 12:29:34 73 1 13 (13/0) 0 test_server@REDACTED CT Log none tests.wx_test - Wed Nov 16 2011 16:25:16 4 1 29 (0/29) 0 test_server@REDACTED CT Log none tests.xmerl_test - Wed Nov 16 2011 16:25:41 3569 0 240 (240/0) 0 test_server@REDACTED CT Log none Total 10933 135 1773 (563/1210) 5 __________________________________________________________________________________________________________________________________ Copyright ? 2011 Open Telecom Platform Updated: Wed Nov 16 2011 16:40:19 From erlang@REDACTED Fri Nov 18 14:11:00 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 18 Nov 2011 14:11:00 +0100 Subject: [erlang-bugs] parser/preprocessor bug Message-ID: -module(bug). -compile(export_all). -record(bug,{a}). test() -> [#bug{a=1} #bug{a=2}]. 1> c(bug). {ok,bug} 2> bug:test(). [{bug,2}] Should be "," or "|" between the records in the list /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Nov 18 14:16:34 2011 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 18 Nov 2011 14:16:34 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: References: Message-ID: Hi, On Fri, Nov 18, 2011 at 14:11, Joe Armstrong wrote: > -module(bug). > -compile(export_all). > -record(bug,{a}). > test() -> > ??? [#bug{a=1} #bug{a=2}]. It's not a bug, it's the same as test() -> B = #bug{a=1}, ??? [B#bug{a=2}]. regards, Vlad From erlang@REDACTED Fri Nov 18 15:46:16 2011 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 18 Nov 2011 15:46:16 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: References: Message-ID: On Fri, Nov 18, 2011 at 2:16 PM, Vlad Dumitrescu wrote: > Hi, > > On Fri, Nov 18, 2011 at 14:11, Joe Armstrong wrote: > > -module(bug). > > -compile(export_all). > > -record(bug,{a}). > > test() -> > > [#bug{a=1} #bug{a=2}]. > > It's not a bug, it's the same as > > test() -> > B = #bug{a=1}, > [B#bug{a=2}]. > > Ouch - oh dear you're right. When I wrote this I thought #bug{a=1} is syntactic sugar for {bug,1} therefore [#bug{a=1} #bug{a=2}] is the same as [{bug1,} {bug,2}] which is an invalid list. /J > regards, > Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Fri Nov 18 17:04:13 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 18 Nov 2011 17:04:13 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: References: Message-ID: <20111118160412.GA3120@erix.ericsson.se> On Fri, Nov 18, 2011 at 03:46:16PM +0100, Joe Armstrong wrote: > On Fri, Nov 18, 2011 at 2:16 PM, Vlad Dumitrescu wrote: > > > Hi, > > > > On Fri, Nov 18, 2011 at 14:11, Joe Armstrong wrote: > > > -module(bug). > > > -compile(export_all). > > > -record(bug,{a}). > > > test() -> > > > [#bug{a=1} #bug{a=2}]. > > > > It's not a bug, it's the same as > > > > test() -> > > B = #bug{a=1}, > > [B#bug{a=2}]. > > > > > Ouch - oh dear you're right. > > When I wrote this I thought #bug{a=1} is syntactic sugar for {bug,1} > therefore [#bug{a=1} #bug{a=2}] is the same as [{bug1,} {bug,2}] which is > an invalid list. I have not tried but you can think of it like that: [#bug{a=1} #bug{a=2}] is [{bug,1} #bug{a=2}] %% uncertain if valid is [setelement(2, {bug,1}, 2)] since R#bug{a=A} is syntactical sugar for (kind of) if is_record(R, bug) -> setelement(2, R, A) end in the context of your record definition. > > /J > > > > > > > regards, > > Vlad > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From robert.virding@REDACTED Fri Nov 18 22:51:08 2011 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 18 Nov 2011 21:51:08 -0000 (GMT) Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: <20111118160412.GA3120@erix.ericsson.se> Message-ID: <43d76551-a82c-4f2a-8096-6609af7f4bdd@knuth> Originally the parentheses were mandatory but then the need for them around an record expression was removed to "improve" the syntax. Only in some cases though. Sorry for griping but I think it was a bad change. Other people have had exactly the same errors. Robert ----- Original Message ----- > On Fri, Nov 18, 2011 at 03:46:16PM +0100, Joe Armstrong wrote: > > On Fri, Nov 18, 2011 at 2:16 PM, Vlad Dumitrescu > > wrote: > > > > > Hi, > > > > > > On Fri, Nov 18, 2011 at 14:11, Joe Armstrong > > > wrote: > > > > -module(bug). > > > > -compile(export_all). > > > > -record(bug,{a}). > > > > test() -> > > > > [#bug{a=1} #bug{a=2}]. > > > > > > It's not a bug, it's the same as > > > > > > test() -> > > > B = #bug{a=1}, > > > [B#bug{a=2}]. > > > > > > > > Ouch - oh dear you're right. > > > > When I wrote this I thought #bug{a=1} is syntactic sugar for > > {bug,1} > > therefore [#bug{a=1} #bug{a=2}] is the same as [{bug1,} {bug,2}] > > which is > > an invalid list. > > I have not tried but you can think of it like that: > [#bug{a=1} #bug{a=2}] > is > [{bug,1} #bug{a=2}] %% uncertain if valid > is > [setelement(2, {bug,1}, 2)] > > since R#bug{a=A} is syntactical sugar for (kind of) > if is_record(R, bug) -> setelement(2, R, A) end > in the context of your record definition. > > > > > /J > > > > > > > > > > > > > regards, > > > Vlad > > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From samuelrivas@REDACTED Sun Nov 20 23:56:56 2011 From: samuelrivas@REDACTED (Samuel) Date: Sun, 20 Nov 2011 23:56:56 +0100 Subject: [erlang-bugs] scarce dialyzer message "illegal declaration of..." with records Message-ID: Hello, If you run dialyzer in the attached file it will fail with next message: Analysis failed with error: Illegal declaration of #state{parent} In the example the problem is pretty obvious, there is a mismatch between the declared type of the 'parent' field and the function specification. However in a larger example I found it very hard to spot. Even worse, if dialyzer is analysing a list of modules it wouldn't say what module caused the error. (Actually, I ran a very boring 'shrinking' binary process of deleting code sections until I found the cause of the error, which happened to be a type annotation generated by typer before I started refining the specs). I saw a couple other mails related to illegal declarations but they both were issues with polymorphic types, so I guess this is something different. Regards -- Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: test.erl Type: text/x-erlang Size: 123 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Mon Nov 21 14:02:01 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 21 Nov 2011 14:02:01 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: <43d76551-a82c-4f2a-8096-6609af7f4bdd@knuth> References: <20111118160412.GA3120@erix.ericsson.se> <43d76551-a82c-4f2a-8096-6609af7f4bdd@knuth> Message-ID: <20111121130201.GA5335@erix.ericsson.se> On Fri, Nov 18, 2011 at 09:51:08PM +0000, Robert Virding wrote: > Originally the parentheses were mandatory but then the need for them around an record expression was removed to "improve" the syntax. Only in some cases though. Sorry for griping but I think it was a bad change. Other people have had exactly the same errors. Yes. It has now become a pitfall worth repeating. The intention was to improve (simplify) the syntax for nested records e.g: Y = X#outer_record.a#inner_record.b was syntactically invalid and had to be written: Y = (X#outer_record.a)#inner_record.b / Raimo > > Robert > > ----- Original Message ----- > > On Fri, Nov 18, 2011 at 03:46:16PM +0100, Joe Armstrong wrote: > > > On Fri, Nov 18, 2011 at 2:16 PM, Vlad Dumitrescu > > > wrote: > > > > > > > Hi, > > > > > > > > On Fri, Nov 18, 2011 at 14:11, Joe Armstrong > > > > wrote: > > > > > -module(bug). > > > > > -compile(export_all). > > > > > -record(bug,{a}). > > > > > test() -> > > > > > [#bug{a=1} #bug{a=2}]. > > > > > > > > It's not a bug, it's the same as > > > > > > > > test() -> > > > > B = #bug{a=1}, > > > > [B#bug{a=2}]. > > > > > > > > > > > Ouch - oh dear you're right. > > > > > > When I wrote this I thought #bug{a=1} is syntactic sugar for > > > {bug,1} > > > therefore [#bug{a=1} #bug{a=2}] is the same as [{bug1,} {bug,2}] > > > which is > > > an invalid list. > > > > I have not tried but you can think of it like that: > > [#bug{a=1} #bug{a=2}] > > is > > [{bug,1} #bug{a=2}] %% uncertain if valid > > is > > [setelement(2, {bug,1}, 2)] > > > > since R#bug{a=A} is syntactical sugar for (kind of) > > if is_record(R, bug) -> setelement(2, R, A) end > > in the context of your record definition. > > > > > > > > /J > > > > > > > > > > > > > > > > > > > regards, > > > > Vlad > > > > > > > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ess@REDACTED Mon Nov 21 17:11:42 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 21 Nov 2011 17:11:42 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: <20111121130201.GA5335@erix.ericsson.se> References: <20111118160412.GA3120@erix.ericsson.se> <43d76551-a82c-4f2a-8096-6609af7f4bdd@knuth> <20111121130201.GA5335@erix.ericsson.se> Message-ID: <4ECA783E.1060901@trifork.com> One possibility is to warn if a record selection/modification is applied directly to a record or tuple creation. (The rationale being that value construction followed by immediate deconstruction is not likely to be a common pattern.) I.e. on {foo,bar} #record.f {foo,bar} #record{...} #record1{...} #record2.f #record1{...} #record2{...} Exp#record{...}#record.f Exp#record{...}#record{...} but, if reasonably easy to do in the compiler, not to warn on the parenthesized variants. (The topic has come up before, a couple of years ago; I don't know if I suggested the same back then.) On 21-11-2011 14:02, Raimo Niskanen wrote: > On Fri, Nov 18, 2011 at 09:51:08PM +0000, Robert Virding wrote: >> Originally the parentheses were mandatory but then the need for them around an record expression was removed to "improve" the syntax. Only in some cases though. Sorry for griping but I think it was a bad change. Other people have had exactly the same errors. > Yes. It has now become a pitfall worth repeating. > > The intention was to improve (simplify) the syntax for nested records e.g: > Y = X#outer_record.a#inner_record.b > was syntactically invalid and had to be written: > Y = (X#outer_record.a)#inner_record.b > > / Raimo > > > >> Robert >> >> ----- Original Message ----- >>> On Fri, Nov 18, 2011 at 03:46:16PM +0100, Joe Armstrong wrote: >>>> On Fri, Nov 18, 2011 at 2:16 PM, Vlad Dumitrescu >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Fri, Nov 18, 2011 at 14:11, Joe Armstrong >>>>> wrote: >>>>>> -module(bug). >>>>>> -compile(export_all). >>>>>> -record(bug,{a}). >>>>>> test() -> >>>>>> [#bug{a=1} #bug{a=2}]. >>>>> It's not a bug, it's the same as >>>>> >>>>> test() -> >>>>> B = #bug{a=1}, >>>>> [B#bug{a=2}]. >>>>> >>>>> >>>> Ouch - oh dear you're right. >>>> >>>> When I wrote this I thought #bug{a=1} is syntactic sugar for >>>> {bug,1} >>>> therefore [#bug{a=1} #bug{a=2}] is the same as [{bug1,} {bug,2}] >>>> which is >>>> an invalid list. >>> I have not tried but you can think of it like that: >>> [#bug{a=1} #bug{a=2}] >>> is >>> [{bug,1} #bug{a=2}] %% uncertain if valid >>> is >>> [setelement(2, {bug,1}, 2)] >>> >>> since R#bug{a=A} is syntactical sugar for (kind of) >>> if is_record(R, bug) -> setelement(2, R, A) end >>> in the context of your record definition. >>> >>>> /J >>>> >>>> >>>> >>>> >>>> >>>>> regards, >>>>> Vlad >>>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> -- >>> >>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> From eurekafag@REDACTED Mon Nov 21 20:48:06 2011 From: eurekafag@REDACTED (eurekafag) Date: Mon, 21 Nov 2011 23:48:06 +0400 Subject: [erlang-bugs] Unicode bug in io:format Message-ID: Well... am I talking about something inappropriate or just stupid? Is it a bug or am I doing something wrong? How to properly print unicode text using io:format? Please, don't ignore me, it's very easy to try the code and see it's working differently with and without -noinput. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Mon Nov 21 20:55:03 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 21 Nov 2011 13:55:03 -0600 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: Message-ID: Tried the code. Works fine locally. OS X 10.7 with LANG=en_US.UTF-8 On Mon, Nov 21, 2011 at 1:48 PM, eurekafag wrote: > Well... am I talking about something inappropriate or just stupid? Is it a > bug or am I doing something wrong? How to properly print unicode text using > io:format? Please, don't ignore me, it's very easy to try the code and see > it's working differently with and without -noinput. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From eurekafag@REDACTED Mon Nov 21 21:06:44 2011 From: eurekafag@REDACTED (eurekafag) Date: Tue, 22 Nov 2011 00:06:44 +0400 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: Message-ID: What exactly do you get? Please, provide the full output of both cases with and without -noinput. I tried export LANG=en_US.UTF-8 (my system-wide locale is ru_RU.UTF-8) and I still get the same result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Mon Nov 21 21:19:54 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 21 Nov 2011 14:19:54 -0600 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: Message-ID: Oh, good call. I just pasted your code into the shell and it worked. But then when compiling it into a file it breaks like you have. Specifically, the UTF-8 literal in the source file is broken. This suggests that the Erlang compiler doesn't like UTF-8 literals, and sure enough, a quick google brought up a post: http://erlang.2086793.n4.nabble.com/utf8-in-source-files-td3031128.html Which references: http://www.erlang.org/doc/apps/stdlib/unicode_usage.html HTH, Paul Davis On Mon, Nov 21, 2011 at 2:06 PM, eurekafag wrote: > What exactly do you get? Please, provide the full output of both cases with > and without -noinput. I tried?export LANG=en_US.UTF-8 (my system-wide locale > is ru_RU.UTF-8) and I still get the same result. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From eurekafag@REDACTED Mon Nov 21 22:42:07 2011 From: eurekafag@REDACTED (eurekafag) Date: Tue, 22 Nov 2011 01:42:07 +0400 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: Message-ID: Thanks, I'm aware of it. The problem is different behavior with and without -noinput. I'm just curious which case is right and why it makes difference at all. I explicitly define that binary string as utf8-encoded but it only works with -noinput and fails without it. On the other hand, a list without any unicode letters at all (only integers) printed as hex values with -noinput and as test without it. It may be understandable if this is some kind of parser problem which wants latin-1 letters in source but what's wrong with plain list of integers which it fails to output as a string? The problem is that those two cases are mutually exclusive so one of them works with -noinput and fails without and vice versa. So I'm curious which method I should use so it works like expected. 22 ?????? 2011 ?. 0:19 ???????????? Paul Davis ???????: > Oh, good call. I just pasted your code into the shell and it worked. > But then when compiling it into a file it breaks like you have. > Specifically, the UTF-8 literal in the source file is broken. This > suggests that the Erlang compiler doesn't like UTF-8 literals, and > sure enough, a quick google brought up a post: > > http://erlang.2086793.n4.nabble.com/utf8-in-source-files-td3031128.html > > Which references: > > http://www.erlang.org/doc/apps/stdlib/unicode_usage.html > > HTH, > Paul Davis > > On Mon, Nov 21, 2011 at 2:06 PM, eurekafag wrote: > > What exactly do you get? Please, provide the full output of both cases > with > > and without -noinput. I tried export LANG=en_US.UTF-8 (my system-wide > locale > > is ru_RU.UTF-8) and I still get the same result. > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue Nov 22 09:41:55 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 22 Nov 2011 10:41:55 +0200 Subject: [erlang-bugs] Missing dependency Message-ID: <4ECB6053.7030809@cs.ntua.gr> On a machine with a minimal installation of Debian, I've discovered that the 'diameter' application requires the presence of the 'ed' program to create/modify the 'diameter.app' file, but the configure script does not check whether 'ed' is installed. As a result, making the system fails miserably. This is on R14B04, but I suspect the same happens on R15. Kostis From ess@REDACTED Tue Nov 22 11:02:10 2011 From: ess@REDACTED (=?UTF-8?B?RXJpayBTw7hlIFPDuHJlbnNlbg==?=) Date: Tue, 22 Nov 2011 11:02:10 +0100 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: Message-ID: <4ECB7322.8080505@trifork.com> I thought it might have something to do with io:setopts() being called when -noinput is absent, and not when it is present; the evidence is mixed, but I think I may be on to something useful. Consider the following extension of your program: -module(unicode_test). -export([main/0]). main() -> print(), ok = io:setopts(standard_io, [{encoding, unicode}]), print(). print() -> io:format("Encoding=~p~n", [lists:keyfind(encoding,1,io:getopts())]), io:format("~ts~n", [[1058,1077,1089,1090,1086,1074,1072,1103,32,1089,1090,1088,1086,1082,1072]]), io:format("~ts~n", ["???????? ??????"]). Without -noinput (and with LANG=da_DK.utf8), I get: 1> Encoding={encoding,latin1} ???????? ?????? ???????????????? ???????????? Encoding={encoding,latin1} ???????? ?????? ???????????????? ???????????? i.e. the list-of-integers version is OK in both cases. With -noinput, I get: Encoding={encoding,latin1} \x{422}\x{435}\x{441}\x{442}\x{43E}\x{432}\x{430}\x{44F} \x{441}\x{442}\x{440}\x{43E}\x{43A}\x{430} ???????? ?????? Encoding={encoding,unicode} ???????? ?????? ???????????????? ???????????? I.e. first the string-literal version is good, but after using io:setopts(), the list-of-integers version is the good one. So, if you explicitly select unicode encoding in your program, you have consistent behaviour. The only thing that bothers me is that there appears to be something else going on - it's not just about the encoding. I find that without -noinput, output is consistent no matter what I set encoding to. With -noinput, on the other hand, output differs whether I select latin1 or unicode encoding. Hoping this helps. /Erik On 21-11-2011 22:42, eurekafag wrote: > Thanks, I'm aware of it. The problem is different behavior with and > without -noinput. I'm just curious which case is right and why it > makes difference at all. I explicitly define that binary string as > utf8-encoded but it only works with -noinput and fails without it. On > the other hand, a list without any unicode letters at all (only > integers) printed as hex values with -noinput and as test without it. > It may be understandable if this is some kind of parser problem which > wants latin-1 letters in source but what's wrong with plain list of > integers which it fails to output as a string? The problem is that > those two cases are mutually exclusive so one of them works with > -noinput and fails without and vice versa. So I'm curious which method > I should use so it works like expected. > > 22 ?????? 2011 ?. 0:19 ???????????? Paul Davis > > > ???????: > > Oh, good call. I just pasted your code into the shell and it worked. > But then when compiling it into a file it breaks like you have. > Specifically, the UTF-8 literal in the source file is broken. This > suggests that the Erlang compiler doesn't like UTF-8 literals, and > sure enough, a quick google brought up a post: > > http://erlang.2086793.n4.nabble.com/utf8-in-source-files-td3031128.html > > Which references: > > http://www.erlang.org/doc/apps/stdlib/unicode_usage.html > > HTH, > Paul Davis > > On Mon, Nov 21, 2011 at 2:06 PM, eurekafag > wrote: > > What exactly do you get? Please, provide the full output of both > cases with > > and without -noinput. I tried export LANG=en_US.UTF-8 (my > system-wide locale > > is ru_RU.UTF-8) and I still get the same result. > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Tue Nov 22 12:16:28 2011 From: ess@REDACTED (=?UTF-8?B?RXJpayBTw7hlIFPDuHJlbnNlbg==?=) Date: Tue, 22 Nov 2011 12:16:28 +0100 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: <4ECB7322.8080505@trifork.com> References: <4ECB7322.8080505@trifork.com> Message-ID: <4ECB848C.7030504@trifork.com> Trying to track down the difference between -noinput and lack thereof, I find this: $ erl -eval 'io:format("~p / ~p\n", [process_info(whereis(user), A) || A <- [initial_call, current_function]]), init:stop().' Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8.4 (abort with ^G) 1> {initial_call,{group,server,3}} / {current_function,{group,server_loop,3}} $ erl -eval 'io:format("~p / ~p\n", [process_info(whereis(user), A) || A <- [initial_call, current_function]]), init:stop().' -noinput {initial_call,{erlang,apply,2}} / {current_function,{user,server_loop,2}} I.e. in one case, 'group' is handling I/O, while in the other, it is 'user'. In fact, in both cases, only one of the modules is loaded at all: $ erl -eval 'io:format("~p\n", [{code:is_loaded(user), code:is_loaded(group)}]), init:stop().' Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8.4 (abort with ^G) 1> {false,{file,"/usr/local/lib/erlang/lib/kernel-2.14.4/ebin/group.beam"}} $ erl -eval 'io:format("~p\n", [{code:is_loaded(user), code:is_loaded(group)}]), init:stop().' -noinput {{file,"/usr/local/lib/erlang/lib/kernel-2.14.4/ebin/user.beam"},false} The differences in behaviour are caused by differences between these two modules. The character encoding translation is done in group:io_request/3 and user:wrap_characters_to_binary/3, respectively (it is the latter which produces the "\x" escapes). /Erik On 22-11-2011 11:02, Erik S?e S?rensen wrote: > I thought it might have something to do with io:setopts() being called > when -noinput is absent, and not when it is present; the evidence is > mixed, but I think I may be on to something useful. > > Consider the following extension of your program: > > -module(unicode_test). > -export([main/0]). > > main() -> > print(), > ok = io:setopts(standard_io, [{encoding, unicode}]), > print(). > > print() -> > io:format("Encoding=~p~n", > [lists:keyfind(encoding,1,io:getopts())]), > io:format("~ts~n", > [[1058,1077,1089,1090,1086,1074,1072,1103,32,1089,1090,1088,1086,1082,1072]]), > io:format("~ts~n", ["???????? ??????"]). > > > Without -noinput (and with LANG=da_DK.utf8), I get: > > 1> Encoding={encoding,latin1} > ???????? ?????? > ???????????????? ???????????? > Encoding={encoding,latin1} > ???????? ?????? > ???????????????? ???????????? > > i.e. the list-of-integers version is OK in both cases. > > With -noinput, I get: > > Encoding={encoding,latin1} > \x{422}\x{435}\x{441}\x{442}\x{43E}\x{432}\x{430}\x{44F} > \x{441}\x{442}\x{440}\x{43E}\x{43A}\x{430} > ???????? ?????? > Encoding={encoding,unicode} > ???????? ?????? > ???????????????? ???????????? > > I.e. first the string-literal version is good, but after using > io:setopts(), the list-of-integers version is the good one. > > So, if you explicitly select unicode encoding in your program, you > have consistent behaviour. > > The only thing that bothers me is that there appears to be something > else going on - it's not just about the encoding. > I find that without -noinput, output is consistent no matter what I > set encoding to. With -noinput, on the other hand, output differs > whether I select latin1 or unicode encoding. > > Hoping this helps. > /Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Tue Nov 22 12:25:46 2011 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 22 Nov 2011 12:25:46 +0100 Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: <20111121130201.GA5335@erix.ericsson.se> References: <20111118160412.GA3120@erix.ericsson.se> <43d76551-a82c-4f2a-8096-6609af7f4bdd@knuth> <20111121130201.GA5335@erix.ericsson.se> Message-ID: On Mon, Nov 21, 2011 at 2:02 PM, Raimo Niskanen wrote: > On Fri, Nov 18, 2011 at 09:51:08PM +0000, Robert Virding wrote: > > Originally the parentheses were mandatory but then the need for > > them around an record expression was removed to "improve" the > > syntax. Only in some cases though. Sorry for griping but I think it > > was a bad change. Other people have had exactly the same errors. > > Yes. It has now become a pitfall worth repeating. > > The intention was to improve (simplify) the syntax for nested > records e.g: > Y = X#outer_record.a#inner_record.b > was syntactically invalid and had to be written: > Y = (X#outer_record.a)#inner_record.b Even though I took the original patch and reworked it for inclusion in OTP, seeing the user confusion and misuse, I'd like to see the changes reverted. Could it be that during the review by the OTP board the potential issues Jesper and Joe ran into have been missed? If we want to keep it, is there a reliable and correct way to generate a syntax error/warning or limit the paren-less record access in erl_parse.yrl? If not, I think it's best to revert the changes. This reminds me of the missing check for a closing paren in macro definitions. That has been fixed and I think this should also be fixed. I also don't think the patch is worth the trouble it has caused. Relevant commits: 3829e5 and 45c380d From eurekafag@REDACTED Tue Nov 22 13:11:58 2011 From: eurekafag@REDACTED (eurekafag) Date: Tue, 22 Nov 2011 16:11:58 +0400 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: <4ECB848C.7030504@trifork.com> References: <4ECB7322.8080505@trifork.com> <4ECB848C.7030504@trifork.com> Message-ID: Many thanks for this thorough research! However I have two things to mention. Setting or getting encoding introduces noticeable delay in launching without -noinput, but with it it starts just as fast as usual. Pretty strange. And another a bit illogical issue: to print UTF-8 strings one should NOT set binary type /utf8. This works fine with encoding set: io:format("~ts~n", [<<"???????? ??????">>]). This fails in both noinput-cases with encoding set: io:format("~ts~n", [<<"???????? ??????"/utf8>>]). I guess it's because of double encoding (by explicitly defined encoding and that suffix) but I was confused at first. It's better not to set encoding but declare it in binary strings like they do in Python prepending strings with 'u' literal, which doesn't work in Erlang for all cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Tue Nov 22 14:02:55 2011 From: ess@REDACTED (=?UTF-8?B?RXJpayBTw7hlIFPDuHJlbnNlbg==?=) Date: Tue, 22 Nov 2011 14:02:55 +0100 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: References: <4ECB7322.8080505@trifork.com> <4ECB848C.7030504@trifork.com> Message-ID: <4ECB9D7F.60308@trifork.com> On 22-11-2011 13:11, eurekafag wrote: > Many thanks for this thorough research! However I have two things to > mention. Setting or getting encoding introduces noticeable delay in > launching without -noinput, but with it it starts just as fast as > usual. Pretty strange. Yes, I noticed that too; the delay is so long that there is probably a timeout somewhere. > And another a bit illogical issue: to print UTF-8 strings one should > NOT set binary type /utf8. This works fine with encoding > set: io:format("~ts~n", [<<"???????? ??????">>]). > This fails in both noinput-cases with encoding set: io:format("~ts~n", > [<<"???????? ??????"/utf8>>]). Remember that still, *source files are always interpreted as latin-1*. From http://www.erlang.org/doc/apps/stdlib/unicode_usage.html : It is convenient to be able to write a list of Unicode characters in the string syntax. However, the language specifies strings as being in the ISO-latin-1 character set which the compiler tool chain as well as many other tools expect. Also the source code is (for now) still expected to be written using the ISO-latin-1 character set, why Unicode characters beyond that range cannot be entered in string literals. Which means that the "/utf8" modifier will always do a latin1->utf8 encoding. So, yes, if you ensure that your source files are UTF-8 encoded, you can use the string literals as they are, and expect them to be UTF-8. > I guess it's because of double encoding (by explicitly defined > encoding and that suffix) but I was confused at first. It's better not > to set encoding but declare it in binary strings like they do in > Python prepending strings with 'u' literal, which doesn't work in > Erlang for all cases. Well, for the u"..." syntax, Python also needs to know the encoding of the source file. Unlike Erlang, however, Python can be told what the encoding is (and can recognize Unicode files which begin with a BOM character). /Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders@REDACTED Tue Nov 22 15:21:53 2011 From: anders@REDACTED (Anders Svensson) Date: Tue, 22 Nov 2011 15:21:53 +0100 Subject: [erlang-bugs] Missing dependency In-Reply-To: <4ECB61D4.7050806@erix.ericsson.se> References: <4ECB6053.7030809@cs.ntua.gr> <4ECB61D4.7050806@erix.ericsson.se> Message-ID: Kostis Sagonas wrote: > On a machine with a minimal installation of Debian, I've discovered that > the 'diameter' application requires the presence of the 'ed' program to > create/modify the 'diameter.app' file, but the configure script does not > check whether 'ed' is installed. ?As a result, making the system fails > miserably. > > This is on R14B04, but I suspect the same happens on R15. Should already be fixed in R15. The dependency on ed has been removed. Anders > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > From robert.virding@REDACTED Wed Nov 23 00:11:17 2011 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 22 Nov 2011 23:11:17 -0000 (GMT) Subject: [erlang-bugs] parser/preprocessor bug In-Reply-To: Message-ID: <638d911b-950f-4bd3-be2e-a6a66224aef0@knuth> My opinion is, as everyone has probably guessed, is to revert back to what it was before. I don't think that the extra parentheses were worth worrying about. It was actually exactly the opposite with the trailing parenthesis in macro definitions. That was laziness on my part on not bothering to add an extra test for that case. Revert the parentheses, or at least add a warning which will cause people to put them back. Robert ----- Original Message ----- > On Mon, Nov 21, 2011 at 2:02 PM, Raimo Niskanen wrote: > > On Fri, Nov 18, 2011 at 09:51:08PM +0000, Robert Virding wrote: > > > Originally the parentheses were mandatory but then the need for > > > them around an record expression was removed to "improve" the > > > syntax. Only in some cases though. Sorry for griping but I think > > > it > > > was a bad change. Other people have had exactly the same errors. > > > > Yes. It has now become a pitfall worth repeating. > > > > The intention was to improve (simplify) the syntax for nested > > records e.g: > > Y = X#outer_record.a#inner_record.b > > was syntactically invalid and had to be written: > > Y = (X#outer_record.a)#inner_record.b > > Even though I took the original patch and reworked it for inclusion > in > OTP, seeing the user confusion and misuse, I'd like to see the > changes > reverted. > > Could it be that during the review by the OTP board the potential > issues Jesper and Joe ran into have been missed? > > If we want to keep it, is there a reliable and correct way to > generate > a syntax error/warning or limit the paren-less record access in > erl_parse.yrl? If not, I think it's best to revert the changes. > > This reminds me of the missing check for a closing paren in macro > definitions. That has been fixed and I think this should also be > fixed. I also don't think the patch is worth the trouble it has > caused. > > Relevant commits: 3829e5 and 45c380d > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From jonas.boberg@REDACTED Thu Nov 24 13:08:30 2011 From: jonas.boberg@REDACTED (Jonas Boberg) Date: Thu, 24 Nov 2011 13:08:30 +0100 Subject: [erlang-bugs] eprof overflow causes incorrect analysis Message-ID: Hi, Looks like there is an integer overflow or similar in eprof: 37> eprof:analyze(total). FUNCTION CALLS % TIME [ uS / CALLS] ets:lookup/2 15948 0.00 21003 [ 1.32] erlang:setelement/3 90211 0.00 24342 [ 0.27] erlang:port_control/3 19667 0.00 101628 [ 5.17] prim_inet:enum_val/2 21664 100.00 1000000008142 [46159527.70] The last row is obviously incorrect (profiling was active for about 5 second). This is when profiling a moderately loaded node. I can consistently reproduce the problem. If I reduce the time of profiling (so that less function calls are made) I don't get this problem. OTP release: 5.8.4 (R14B03). Regards Jonas From egil@REDACTED Thu Nov 24 14:26:30 2011 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 24 Nov 2011 14:26:30 +0100 Subject: [erlang-bugs] eprof overflow causes incorrect analysis In-Reply-To: References: Message-ID: <4ECE4606.5050104@erlang.org> On 2011-11-24 13:08, Jonas Boberg wrote: > Hi, > > Looks like there is an integer overflow or similar in eprof: > > 37> eprof:analyze(total). > FUNCTION CALLS > % TIME [ uS / CALLS] > ets:lookup/2 15948 > 0.00 21003 [ 1.32] > erlang:setelement/3 90211 > 0.00 24342 [ 0.27] > erlang:port_control/3 19667 > 0.00 101628 [ 5.17] > prim_inet:enum_val/2 21664 > 100.00 1000000008142 [46159527.70] > > The last row is obviously incorrect (profiling was active for about 5 > second). This is when profiling a moderately loaded node. > I can consistently reproduce the problem. If I reduce the time of > profiling (so that less function calls are made) I don't get this > problem. Can you send me a test module so I can reproduce this? // Bj?rn-Egil From jonas.boberg@REDACTED Thu Nov 24 15:33:18 2011 From: jonas.boberg@REDACTED (Jonas Boberg) Date: Thu, 24 Nov 2011 15:33:18 +0100 Subject: [erlang-bugs] erlang:monitor(process, {Regname, Nodename}) gives badarg when not alive Message-ID: Hi, erlang:monitor fails with badarg when the local node is not alive. $ erl 1> erlang:monitor(process, {a, b}). ** exception error: bad argument in function monitor/2 called as monitor(process,{a,b}) $ erl -sname test 1> erlang:monitor(process, {a, b}). #Ref<0.0.0.34> Probably the problem is the documentation of the function rather than the implementation. The erlang:monitor_node documentation says 'Failure: badargif the local node is not alive.', but the documentation for erlang:monitor doesn't. Regards Jonas From copypastor@REDACTED Fri Nov 25 23:03:15 2011 From: copypastor@REDACTED (Denis Nesterov) Date: Sat, 26 Nov 2011 02:03:15 +0400 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system Message-ID: Hello! I wrote simple benchmark code to measure floating-point Erlang performance. And seems that code gets Erlang system into a deadlock :-p The thing is that my code doing VERY simple thing - it first generates big list of pairs of Euclidian vectors, then in loop performs sequential mult-add operation on each element. When I start one such process per CPU core and list is big enough, the Erlang systems quickly stops responding. The code is: -module ( bug ). -export ( [start/0] ). -record ( vec3, { x=0, y=0, z=0 } ). vec3ma( V0, V1, K ) when is_record( V0, vec3 ) and is_record( V1, vec3 ) and is_number( K ) -> #vec3{ x = V0#vec3.x + V1#vec3.x * K, y = V0#vec3.y + V1#vec3.y * K, z = V0#vec3.z + V1#vec3.z * K }. %create test data makeVecTestList( L, 0 ) -> L; makeVecTestList( L, N ) -> E = { #vec3{ x = N * 10.0, y = 20.0, z = 30.0 }, #vec3{ x=10.0, y=20.0, z=-40.0 } }, makeVecTestList( [ E|L ], N - 1 ). %Test list-processing code proc( L ) -> proc( L, [] ). proc( [], Acc ) -> Acc; proc( [ { P, V } | T ], Acc ) -> proc( T, [ { vec3ma( P, V, 0.11 ), V } | Acc ] ). %process loop vecTestLoop( L, T, I ) -> Now = now(), DT = timer:now_diff( Now, T ) * 1.0e-3, io:format( "Step~p: ~p ms\n", [I, DT] ), vecTestLoop( proc( L ), Now, I ). start() -> L = makeVecTestList( [], 1000000 ), io:format( "Running test with: ~p\n", [length(L)] ), spawn( fun() -> vecTestLoop( L, now(), 1 ) end ), spawn( fun() -> vecTestLoop( L, now(), 2 ) end ), spawn( fun() -> vecTestLoop( L, now(), 3 ) end ), spawn( fun() -> vecTestLoop( L, now(), 4 ) end ). I used next test-cases: AMD 64 2 core, 3.1 GHZ, Windows XP, Erlang R14B04: - Works well with one process and any list that fits into memory - Works well with two processes and list of 500000 elements - Hangs in about 30-60 seconds with list of 750000 elements - Hangs almost immediately with list of 1000000 elements Intel Quad 2.67 GHz, Windows 7 x64, Erlang R14B04: - Works well with one process and any list that fits into memory - Hangs in about 30-60 seconds with list of 1000000 elements - Hangs almost immediately with list of 1500000 elements This looks very similar to deadlock - when normal iterations freeezes, the erl.exe cannot be stopped with Ctrl+C/Break, typing "q()." etc, and starts to load ONLY ONE CORE. Though while it still alive, it consumes all cores. Memory consumption by erl.exe was about or even under 1 GB in all cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Nov 26 02:17:01 2011 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Nov 2011 02:17:01 +0100 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system In-Reply-To: References: Message-ID: It is not a deadlock, it seems to be a memory issue. I got the same behavior. It seemed to freeze but not long after that: mmap(size=374341632) failed (error code=12) can't allocate region. At that point it had allocated 2GB of memory and I hit the virtual memory limit. This was a 32bit emulator on Mac osx lion. I changed vecTestLoop/3 to ... L2 = proc(L), erlang:garbage_collect(), %% <--- vecTestLoop( L2, Now, I ). It ran better. A vecTestList with 1000000 elements takes 33M words of memory. Four such lists takes roughly (33M * 4 * 4= ) 0.5+ GB of memory. On top of this garbage will be generated, well in this case almost everything is garbage since your list is recreated at each iteration. The copying garbage collector needs twice the heap memory, for that process, during a collection. It is not hard to reach the virtual memory limit in this case. You say that your memory consumption was about 1 GB, I think it was a bit more. // Bj?rn-Egil 2011/11/25 Denis Nesterov > Hello! > > I wrote simple benchmark code to measure floating-point Erlang > performance. And seems that code gets Erlang system into a deadlock :-p > > The thing is that my code doing VERY simple thing - it first generates big > list of pairs of Euclidian vectors, then in loop performs sequential > mult-add operation on each element. > When I start one such process per CPU core and list is big enough, the > Erlang systems quickly stops responding. > > The code is: > > -module ( bug ). > -export ( [start/0] ). > > -record ( vec3, { x=0, y=0, z=0 } ). > > > vec3ma( V0, V1, K ) when is_record( V0, vec3 ) and is_record( V1, vec3 ) > and is_number( K ) -> > #vec3{ x = V0#vec3.x + V1#vec3.x * K, y = V0#vec3.y + V1#vec3.y * K, z = > V0#vec3.z + V1#vec3.z * K }. > > %create test data > makeVecTestList( L, 0 ) -> L; > makeVecTestList( L, N ) -> > E = { #vec3{ x = N * 10.0, y = 20.0, z = 30.0 }, #vec3{ x=10.0, y=20.0, > z=-40.0 } }, > makeVecTestList( [ E|L ], N - 1 ). > > %Test list-processing code > proc( L ) -> proc( L, [] ). > proc( [], Acc ) -> Acc; > proc( [ { P, V } | T ], Acc ) -> proc( T, [ { vec3ma( P, V, 0.11 ), V } | > Acc ] ). > > %process loop > vecTestLoop( L, T, I ) -> > Now = now(), > DT = timer:now_diff( Now, T ) * 1.0e-3, > io:format( "Step~p: ~p ms\n", [I, DT] ), > vecTestLoop( proc( L ), Now, I ). > > start() -> > L = makeVecTestList( [], 1000000 ), > io:format( "Running test with: ~p\n", [length(L)] ), > spawn( fun() -> vecTestLoop( L, now(), 1 ) end ), > spawn( fun() -> vecTestLoop( L, now(), 2 ) end ), > spawn( fun() -> vecTestLoop( L, now(), 3 ) end ), > spawn( fun() -> vecTestLoop( L, now(), 4 ) end ). > > > I used next test-cases: > > AMD 64 2 core, 3.1 GHZ, Windows XP, Erlang R14B04: > - Works well with one process and any list that fits into memory > - Works well with two processes and list of 500000 elements > - Hangs in about 30-60 seconds with list of 750000 elements > - Hangs almost immediately with list of 1000000 elements > > Intel Quad 2.67 GHz, Windows 7 x64, Erlang R14B04: > - Works well with one process and any list that fits into memory > - Hangs in about 30-60 seconds with list of 1000000 elements > - Hangs almost immediately with list of 1500000 elements > > This looks very similar to deadlock - when normal iterations freeezes, > the erl.exe cannot be stopped with Ctrl+C/Break, typing "q()." etc, and > starts to load ONLY ONE CORE. Though while it still alive, it consumes all > cores. > > Memory consumption by erl.exe was about or even under 1 GB in all cases. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Sat Nov 26 03:13:41 2011 From: ess@REDACTED (=?iso-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Sat, 26 Nov 2011 03:13:41 +0100 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system Message-ID: I can reproduce this on Linux (Intel(R) Core(TM)2 Duo CPU, 2.10GHz, 2GB). This was done using 4 processes and 750k elements; apparent deadlock happened within a couple of minutes (but see below). The OS threads of the Erlang VM are stuck doing this: Thread 1: #1 0x00c19971 in select () at ../sysdeps/unix/syscall-template.S:82 #2 0x08184554 in erts_sys_main_thread () at sys/unix/sys.c:3049 #3 0x08095be3 in erl_start (argc=14, argv=0xbfeb3f54) at beam/erl_init.c:1441 #4 0x080785eb in main (argc=14, argv=0xbfeb3f54) at sys/unix/erl_main.c:29 Thread 2: #1 0x00ef2015 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0x081e0ee7 in ethr_cond_wait (cnd=0x826bacc, mtx=0x826bab4) at common/ethr_mutex.c:1350 #3 0x080c51cc in erts_cnd_wait (old_activity=ERTS_ACTIVITY_GC, new_activity=ERTS_ACTIVITY_UNDEFINED, locked=1, prepare=0, resume=0, arg=0x0) at beam/erl_threads.h:697 #4 erts_smp_cnd_wait (old_activity=ERTS_ACTIVITY_GC, new_activity=ERTS_ACTIVITY_UNDEFINED, locked=1, prepare=0, resume=0, arg=0x0) at beam/erl_smp.h:472 #5 block_me (old_activity=ERTS_ACTIVITY_GC, new_activity=ERTS_ACTIVITY_UNDEFINED, locked=1, prepare=0, resume=0, arg=0x0) at beam/utils.c:3439 #6 erts_check_block (old_activity=ERTS_ACTIVITY_GC, new_activity=ERTS_ACTIVITY_UNDEFINED, locked=1, prepare=0, resume=0, arg=0x0) at beam/utils.c:3646 #7 0x0813a72c in erts_smp_set_activity (p=0xb543ef04, need=3, objv=0xb7688ec0, nobj=11) at beam/sys.h:940 #8 erts_garbage_collect (p=0xb543ef04, need=3, objv=0xb7688ec0, nobj=11) at beam/erl_gc.c:395 #9 0x080f63d5 in erts_gc_mixed_times (p=0xb543ef04, reg=0xb7688ec0, live=11) at beam/erl_arith.c:1690 #10 0x0816a431 in process_main () at beam/beam_emu.c:2678 Thread 3: #1 0x00ef4edb in write () at ../sysdeps/unix/syscall-template.S:82 #2 0x081e5d27 in write_fd (vfdp=0xb6570dd0, buf=0x81f2c41 "\n", len=1) at common/erl_printf.c:140 #3 0x081e566c in erts_printf_format (fn=0x81e5cf0 , arg=0xb6570dd0, fmt=0x81f2c3b "F%X:%s\n", ap=0xb6570dfc "\033") at common/erl_printf_format.c:858 #4 0x081e5a72 in erts_vfdprintf (fd=3, format=0x81f2c3b "F%X:%s\n", arglist=0xb6570dfc "\033") at common/erl_printf.c:376 #5 0x080bf2b0 in erts_print (to=1, arg=0x0, format=0x1
) at beam/utils.c:313 #6 0x0814a289 in heap_dump (to=3, to_arg=0x0, x=2828803689) at beam/erl_process_dump.c:331 #7 0x0814a8d2 in dump_process_info (to=3, to_arg=0x0) at beam/erl_process_dump.c:125 #8 erts_deep_process_dump (to=3, to_arg=0x0) at beam/erl_process_dump.c:73 #9 0x08134f97 in erl_crash_dump_v (file=0xb547566c "\245\323\026\bXVG\265", line=0, fmt=0x81e8698 "%s: Cannot %s %lu bytes of memory (of type \"%s\").\n", args=0xb6571f48 "*\206\036\b\301]\037\b|P\321\021\035\204\036\b") at beam/break.c:711 #10 0x080949fa in erl_exit (n=1, fmt=0x81e8698 "%s: Cannot %s %lu bytes of memory (of type \"%s\").\n") #11 0x0807ae5f in erts_alc_fatal_error (error=1, func=0, n=131) at beam/erl_alloc.c:1642 #12 0x0807af67 in erts_alloc_n_enomem (n=131, size=298930300) at beam/erl_alloc.c:1667 #13 0x081376b8 in erts_alloc (p=, new_sz=, objv=, nobj=11) at beam/erl_alloc.h:205 #14 do_minor (p=, new_sz=, objv=, nobj=11) at beam/erl_gc.c:897 #15 0x0813a29d in minor_collection (p=0xb543ed54, need=3, objv=0xb767fe40, nobj=11) at beam/erl_gc.c:769 #16 erts_garbage_collect (p=0xb543ed54, need=3, objv=0xb767fe40, nobj=11) at beam/erl_gc.c:376 #17 0x080f6e1a in erts_gc_mixed_plus (p=0xb543ed54, reg=0xb767fe40, live=11) at beam/erl_arith.c:1308 #18 0x0816a431 in process_main () at beam/beam_emu.c:2678 Thread 4: #1 0x00ef2015 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0x081e0ee7 in ethr_cond_wait (cnd=0x82706c0, mtx=0x82706a4) at common/ethr_mutex.c:1350 #3 0x08185d31 in erts_cnd_wait (unused=0x0) at beam/erl_threads.h:697 #4 child_waiter (unused=0x0) at sys/unix/sys.c:2835 #5 0x081e2fb5 in thr_wrapper (vtwd=0xbfeb39f0) at pthread/ethread.c:106 #6 0x00eed96e in start_thread (arg=0xb6577b70) at pthread_create.c:300 #7 0x00c20a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 5: #1 0x00ef2015 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0x081e0ee7 in ethr_cond_wait (cnd=0x8247dc0, mtx=0x8247d74) at common/ethr_mutex.c:1350 #3 0x080b902e in erts_cnd_wait (unused=0x0) at beam/erl_threads.h:697 #4 erts_smp_cnd_wait (unused=0x0) at beam/erl_smp.h:472 #5 sys_msg_dispatcher_func (unused=0x0) at beam/erl_trace.c:3238 #6 0x081e2fb5 in thr_wrapper (vtwd=0xbfeb3a70) at pthread/ethread.c:106 #7 0x00eed96e in start_thread (arg=0xb6d78b70) at pthread_create.c:300 #8 0x00c20a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 6: #1 0x00c19971 in select () at ../sysdeps/unix/syscall-template.S:82 #2 0x081e69d0 in erts_milli_sleep (ms=60000) at common/erl_misc_utils.c:159 #3 0x080bfd89 in emergency_watchdog (unused=0x0) at beam/utils.c:3959 #4 0x081e2fb5 in thr_wrapper (vtwd=0xbfeb3a70) at pthread/ethread.c:106 #5 0x00eed96e in start_thread (arg=0xb6d81b70) at pthread_create.c:300 #6 0x00c20a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 7: #0 0x00d38422 in __kernel_vsyscall () #1 0x00ef4f5b in read () at ../sysdeps/unix/syscall-template.S:82 #2 0x08184b3f in read (unused=0x0) at /usr/include/bits/unistd.h:45 #3 signal_dispatcher_thread_func (unused=0x0) at sys/unix/sys.c:2906 #4 0x081e2fb5 in thr_wrapper (vtwd=0xbfeb39a0) at pthread/ethread.c:106 #5 0x00eed96e in start_thread (arg=0xb7582b70) at pthread_create.c:300 #6 0x00c20a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 --that's all-- My summary: one of the interpreter threads has detected an out-of-memory situation during GC and is creating a crash dump (verified: an erl_crash.dump file does exist in the directory and is slowly increasing in size once I detached the debugger); the other interpreter thread is stuck during GC, presumably waiting for the first one. Denis: Do you see any erl_crash.dump files being created in the apparent deadlock situation? If so, then it's a simple out-of-memory situation, and the only bug appears to be that the printing of the out-of-memory error report (see thread 3, stack frame #8 above) is blocked for some reason; I have not waited to find out whether it will eventually be printed. Dumping a ~1GB process obviously takes some time, and is what the one busy CPU is doing. (I did try lowering the limit of virtual memory the OS process was allowed; then the output is: Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 32097420 bytes of memory (of type "old_heap"). so it appears it will be printed, but for unknown-but-user-unfriendly reasons not until after dumping has completed.) Regards, Erik S?e S?rensen ________________________________________ From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] On Behalf Of Denis Nesterov [copypastor@REDACTED] Sent: 25 November 2011 23:03 To: erlang-bugs@REDACTED Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system Hello! I wrote simple benchmark code to measure floating-point Erlang performance. And seems that code gets Erlang system into a deadlock :-p The thing is that my code doing VERY simple thing - it first generates big list of pairs of Euclidian vectors, then in loop performs sequential mult-add operation on each element. When I start one such process per CPU core and list is big enough, the Erlang systems quickly stops responding. The code is: -module ( bug ). -export ( [start/0] ). -record ( vec3, { x=0, y=0, z=0 } ). vec3ma( V0, V1, K ) when is_record( V0, vec3 ) and is_record( V1, vec3 ) and is_number( K ) -> #vec3{ x = V0#vec3.x + V1#vec3.x * K, y = V0#vec3.y + V1#vec3.y * K, z = V0#vec3.z + V1#vec3.z * K }. %create test data makeVecTestList( L, 0 ) -> L; makeVecTestList( L, N ) -> E = { #vec3{ x = N * 10.0, y = 20.0, z = 30.0 }, #vec3{ x=10.0, y=20.0, z=-40.0 } }, makeVecTestList( [ E|L ], N - 1 ). %Test list-processing code proc( L ) -> proc( L, [] ). proc( [], Acc ) -> Acc; proc( [ { P, V } | T ], Acc ) -> proc( T, [ { vec3ma( P, V, 0.11 ), V } | Acc ] ). %process loop vecTestLoop( L, T, I ) -> Now = now(), DT = timer:now_diff( Now, T ) * 1.0e-3, io:format( "Step~p: ~p ms\n", [I, DT] ), vecTestLoop( proc( L ), Now, I ). start() -> L = makeVecTestList( [], 1000000 ), io:format( "Running test with: ~p\n", [length(L)] ), spawn( fun() -> vecTestLoop( L, now(), 1 ) end ), spawn( fun() -> vecTestLoop( L, now(), 2 ) end ), spawn( fun() -> vecTestLoop( L, now(), 3 ) end ), spawn( fun() -> vecTestLoop( L, now(), 4 ) end ). I used next test-cases: AMD 64 2 core, 3.1 GHZ, Windows XP, Erlang R14B04: - Works well with one process and any list that fits into memory - Works well with two processes and list of 500000 elements - Hangs in about 30-60 seconds with list of 750000 elements - Hangs almost immediately with list of 1000000 elements Intel Quad 2.67 GHz, Windows 7 x64, Erlang R14B04: - Works well with one process and any list that fits into memory - Hangs in about 30-60 seconds with list of 1000000 elements - Hangs almost immediately with list of 1500000 elements This looks very similar to deadlock - when normal iterations freeezes, the erl.exe cannot be stopped with Ctrl+C/Break, typing "q()." etc, and starts to load ONLY ONE CORE. Though while it still alive, it consumes all cores. Memory consumption by erl.exe was about or even under 1 GB in all cases. From ess@REDACTED Sat Nov 26 03:16:51 2011 From: ess@REDACTED (=?iso-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Sat, 26 Nov 2011 03:16:51 +0100 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system In-Reply-To: References: Message-ID: Apparently that reply took too long to write - Bj?rn got there first :-) Still, I think there's a point in that the situation would be less mysterious if the error message about what caused the crash-dump was printed (and flushed) before the crash-dump is written out. /Erik ________________________________________ From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] On Behalf Of Erik S?e S?rensen [ess@REDACTED] Sent: 26 November 2011 03:13 To: Denis Nesterov; erlang-bugs@REDACTED Subject: Re: [erlang-bugs] Simple floating-point lists operation hungs Erlang system I can reproduce this on Linux (Intel(R) Core(TM)2 Duo CPU, 2.10GHz, 2GB). This was done using 4 processes and 750k elements; apparent deadlock happened within a couple of minutes (but see below). The OS threads of the Erlang VM are stuck doing this: [snip] From wallentin.dahlberg@REDACTED Sat Nov 26 03:30:06 2011 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Nov 2011 03:30:06 +0100 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system In-Reply-To: References: Message-ID: 2011/11/26 Erik S?e S?rensen > > Still, I think there's a point in that the situation would be less > mysterious if the error message about what caused the crash-dump was > printed (and flushed) before the crash-dump is written out. > I agree! =) // Bj?rn-Egil > ________________________________________ > From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] On > Behalf Of Erik S?e S?rensen [ess@REDACTED] > Sent: 26 November 2011 03:13 > To: Denis Nesterov; erlang-bugs@REDACTED > Subject: Re: [erlang-bugs] Simple floating-point lists operation hungs > Erlang system > > I can reproduce this on Linux (Intel(R) Core(TM)2 Duo CPU, 2.10GHz, 2GB). > This was done using 4 processes and 750k elements; apparent deadlock > happened within a couple of minutes (but see below). > > The OS threads of the Erlang VM are stuck doing this: > [snip] > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From copypastor@REDACTED Sat Nov 26 21:13:03 2011 From: copypastor@REDACTED (Denis Nesterov) Date: Sun, 27 Nov 2011 00:13:03 +0400 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system In-Reply-To: References: Message-ID: Thanks a lot for attention. Yes, this is just an out of memory situation, sorry for spending your time. Crash dump was finally written in about 10 minutes and weighted 410 MB. But yes, that was very unclear what erlang system was doing that 10 minutes. While trying to solve this 'mystery' I waited several minutes - suppose long cleanup operation. But never had enough patience to wait 10 minutes :) Another question - how can I estimate size of data structures, and know more about internal erlang data structures? For example, here: http://www.erlang.org/doc/efficiency_guide/advanced.htmlstated that 'float' takes 16 or even 24 bytes on 32/64 bit system respectively. Is that true? I just can't figure out for what reason float number (double, or even extended precision) can take whole lot of space... 2011/11/26 Bj?rn-Egil Dahlberg > > > 2011/11/26 Erik S?e S?rensen >> >> Still, I think there's a point in that the situation would be less >> mysterious if the error message about what caused the crash-dump was >> printed (and flushed) before the crash-dump is written out. >> > > I agree! =) > > // Bj?rn-Egil > >> ________________________________________ >> From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] On >> Behalf Of Erik S?e S?rensen [ess@REDACTED] >> Sent: 26 November 2011 03:13 >> To: Denis Nesterov; erlang-bugs@REDACTED >> Subject: Re: [erlang-bugs] Simple floating-point lists operation hungs >> Erlang system >> >> I can reproduce this on Linux (Intel(R) Core(TM)2 Duo CPU, 2.10GHz, 2GB). >> This was done using 4 processes and 750k elements; apparent deadlock >> happened within a couple of minutes (but see below). >> >> The OS threads of the Erlang VM are stuck doing this: >> [snip] >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Nov 26 22:28:57 2011 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Nov 2011 22:28:57 +0100 Subject: [erlang-bugs] Simple floating-point lists operation hungs Erlang system In-Reply-To: References: Message-ID: 2011/11/26 Denis Nesterov > > Another question - how can I estimate size of data structures, and know > more about internal erlang data structures? > A useful function can be erts_debug:flat_size/1. Take any erlang structure into this function and it will return the word size for that structure. > > For example, here: > http://www.erlang.org/doc/efficiency_guide/advanced.html stated that > 'float' takes 16 or even 24 bytes on 32/64 bit system respectively. Is that > true? I just can't figure out for what reason float number (double, or even > extended precision) can take whole lot of space... > Any data in erlang takes a minimum of one word of data, i.e. 4 or 8 bytes as you said. I think for float there is a header, 1 word and the float_def (see erl_term.h). And yes it takes a bit more memory than is *really* needed for defining a float but it is needed for defining it within the virtual machine. The header is for instance needed for identifying the data and all data needs to word sized aligned. // Bj?rn-Egil > > 2011/11/26 Bj?rn-Egil Dahlberg > >> >> >> 2011/11/26 Erik S?e S?rensen >>> >>> Still, I think there's a point in that the situation would be less >>> mysterious if the error message about what caused the crash-dump was >>> printed (and flushed) before the crash-dump is written out. >>> >> >> I agree! =) >> >> // Bj?rn-Egil >> >>> ________________________________________ >>> From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] >>> On Behalf Of Erik S?e S?rensen [ess@REDACTED] >>> Sent: 26 November 2011 03:13 >>> To: Denis Nesterov; erlang-bugs@REDACTED >>> Subject: Re: [erlang-bugs] Simple floating-point lists operation hungs >>> Erlang system >>> >>> I can reproduce this on Linux (Intel(R) Core(TM)2 Duo CPU, 2.10GHz, 2GB). >>> This was done using 4 processes and 750k elements; apparent deadlock >>> happened within a couple of minutes (but see below). >>> >>> The OS threads of the Erlang VM are stuck doing this: >>> [snip] >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baryluk@REDACTED Sun Nov 27 23:35:06 2011 From: baryluk@REDACTED (Witold Baryluk) Date: Sun, 27 Nov 2011 23:35:06 +0100 Subject: [erlang-bugs] Unicode bug in io:format In-Reply-To: <4ECB9D7F.60308@trifork.com> References: <4ECB7322.8080505@trifork.com> <4ECB848C.7030504@trifork.com> <4ECB9D7F.60308@trifork.com> Message-ID: <20111127223506.GD9190@smp.if.uj.edu.pl> On 11-22 14:02, Erik S?e S?rensen wrote: > On 22-11-2011 13:11, eurekafag wrote: > >Many thanks for this thorough research! However I have two things > >to mention. Setting or getting encoding introduces noticeable > >delay in launching without -noinput, but with it it starts just as > >fast as usual. Pretty strange. > Yes, I noticed that too; the delay is so long that there is probably > a timeout somewhere. > > >And another a bit illogical issue: to print UTF-8 strings one > >should NOT set binary type /utf8. This works fine with encoding > >set: io:format("~ts~n", [<<"???????? ??????">>]). > >This fails in both noinput-cases with encoding set: > >io:format("~ts~n", [<<"???????? ??????"/utf8>>]). > Remember that still, *source files are always interpreted as latin-1*. > > From http://www.erlang.org/doc/apps/stdlib/unicode_usage.html : > > It is convenient to be able to write a list of Unicode characters in > the string syntax. However, the language specifies strings as being > in the ISO-latin-1 character set which the compiler tool chain as > well as many other tools expect. > > Also the source code is (for now) still expected to be written using > the ISO-latin-1 character set, why Unicode characters beyond that > range cannot be entered in string literals. > > Which means that the "/utf8" modifier will always do a latin1->utf8 > encoding. > So, yes, if you ensure that your source files are UTF-8 encoded, you > can use the string literals as they are, and expect them to be > UTF-8. This is undocumented 'feature' of how erl_scan works on binaries strings, it basically eats bytes from input until it will find trailing closing " (modulo handling of \ to escape characters). However it is not supported. It doesn't work on normal list strings also. I'm trying to solve this by introducing proper utf8 support https://github.com/baryluk/otp/compare/master...source_code_encoding_in_compiler_and_epp This patch make string literals and character constants ($?, $?, $?) to support utf8. Unfortunetly it makes string binaries to be broken after this patch. It is due how binaries are construcuted, it is however easly fixable (will just need to reverse encoding back from unicode codepoints to utf8 when parsing binaries). Patch is still WIP because few minor things must be smoothed out. (recursive inclusion of files, BOM detection, and cooperation with -compile() directive) > > >I guess it's because of double encoding (by explicitly defined > >encoding and that suffix) but I was confused at first. It's better > >not to set encoding but declare it in binary strings like they do > >in Python prepending strings with 'u' literal, which doesn't work > >in Erlang for all cases. > Well, for the u"..." syntax, Python also needs to know the encoding > of the source file. Unlike Erlang, however, Python can be told what > the encoding is (and can recognize Unicode files which begin with a > BOM character). Yes, I also work on BOM detection in this patch. You can use for example compile:file("somemodule.erl", [{encoding, utf8}]) with for now default encoding being 'latin1', one can also explicitly say {encoding, default_encoding}, which again will be 'latin1' but in the future could use BOM to detect each file properly. One can force detection using {encoding, detect_unicode_encoding}, however it is not yet working correctly, especially with UTF-16 and UTF-32 files, but it will be fixed quickly. I do this mainly because I want to easly write webpages in Erlang, and do not want to use be forced to use external files, and lookups to other files / databases. I'm ok with external files for example for l10n/i18n, but instead of using .po files, and _() equivalent .erl files + function call, will give me better performance, and simpler toolchain. Even without considering l10n/i18n, there still can be some characters (like mathematics, punctations, elipsis, etc) I would like to have and see them literally in code, than using html entities, or other not nice to eyes things. Regards, Witek -- Witold Baryluk From baryluk@REDACTED Mon Nov 28 01:30:44 2011 From: baryluk@REDACTED (Witold Baryluk) Date: Mon, 28 Nov 2011 01:30:44 +0100 Subject: [erlang-bugs] Dialyzer crash on simple list types Message-ID: <20111128003044.GE9190@smp.if.uj.edu.pl> Hi, I was adding some specs to my code, and run dialyzer. First I found that there is no -type maybe_improper_list(T) :: maybe_improper_list(T, any()). predefined (but it should be according to documentation). Anyway, documentation doesn't exaclty define what 'maybe_' means. Then I noticed dialyzer crashes, and after simiplication found another problem. Here is simplified test case (think about lists:split/2 function). -module(bug_dialyzer). -spec s(maybe_improper_list(X, Z)) -> {list(X), maybe_improper_list(X, Z)}. s(L) -> {L, L}. It compiles without problem, but dialyzer bug_dialyzer.erl gives: $ dialyzer bug_dialyzer.erl Checking whether the PLT /home/baryluk/.dialyzer_plt is up-to-date... yes Proceeding with analysis... =ERROR REPORT==== 28-Nov-2011::01:25:13 === Error in process <0.30.0> with exit value: {{badmatch,{c,list,[any,any],nonempty}}, [{erl_types,t_subst,3},{erl_types,t_subst,3},{erl_types,t_subst,3}, {dialyzer_contracts,general_domain,2}, {dialyzer_contracts,'-process_contract_remote_types/1-fun-0-',4}, {dict... dialyzer: Analysis failed with error: {{badmatch,{c,list,[any,any],nonempty}}, [{erl_types,t_subst,3}, {erl_types,t_subst,3}, {erl_types,t_subst,3}, {dialyzer_contracts,general_domain,2}, {dialyzer_contracts,'-process_contract_remote_types/1-fun-0-',4}, {dict,map_bucket,2}, {dict,map_bkt_list,...}, {dict,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 0.23 secs Removing edges... done in 0.00 secs $ I know maybe_improper_list/2 is discourced to use, and will be probably removed, and instead one will need to use nonempty_improper_list/2, and eventually define other types manually. But this not explains crash. Bug doesn't happen when I do not use polymorphic types, also subsituting any() for Z above -spec s(maybe_improper_list(X, any())) -> {list(X), maybe_improper_list(X, any())}. make it pass dialyzer. Any ideas? -- Witold Baryluk From bob@REDACTED Tue Nov 29 01:44:56 2011 From: bob@REDACTED (Bob Ippolito) Date: Mon, 28 Nov 2011 16:44:56 -0800 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: References: <19903.46889.761570.628729@pilspetsen.it.uu.se> <19904.33588.924591.882382@pilspetsen.it.uu.se> <19905.2793.962779.656652@pilspetsen.it.uu.se> Message-ID: On Wed, May 4, 2011 at 7:03 AM, Bob Ippolito wrote: > On Wed, May 4, 2011 at 1:14 AM, Mikael Pettersson wrote: > > On Tue, 3 May 2011 16:48:20 -0700, Bob Ippolito wrote: > >> On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson > wrote: > >> > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito > wrote: > >> >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson > wrote= > >> : > >> >> > Bob Ippolito writes: > >> >> > =3DC2=3DA0> I only see this error on Mac OS X. I have not been > able to= > >> reprod=3D > >> >> uce in Linux. > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Here's an example, any number larger than > 16#7ffffffffffff= > >> e00 wil=3D > >> >> l > >> >> > =3DC2=3DA0> cause this error. > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] > [rq= > >> :4] > >> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) > >> >> > =3DC2=3DA0> 1> trunc(16#7ffffffffffffdff * 1.0). > >> >> > =3DC2=3DA0> 9223372036854774784 > >> >> > =3DC2=3DA0> 2> trunc(16#7ffffffffffffdff * 1.0). > >> >> > =3DC2=3DA0> 9223372036854774784 > >> >> > =3DC2=3DA0> 3> trunc(16#7ffffffffffffe00 * 1.0). > >> >> > =3DC2=3DA0> 9223372036854775808 > >> >> > =3DC2=3DA0> 4> trunc(16#7ffffffffffffe00 * 1.0). > >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled > FPE a= > >> t > >> >> > =3DC2=3DA0> 0x19223372036854775808 > >> >> > =3DC2=3DA0> 5> trunc(16#7ffffffffffffe00 * 1.0). > >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled > FPE a= > >> t > >> >> > =3DC2=3DA0> 0x19223372036854775808 > >> >> > =3DC2=3DA0> 6> io:format("~s~n", [os:cmd("uname -a")]). > >> >> > =3DC2=3DA0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: > Sat J= > >> an 29 > >> >> > =3DC2=3DA0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 > i386 > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Here's another example: > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] > [rq= > >> :4] > >> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] > >> >> > =3DC2=3DA0> > >> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) > >> >> > =3DC2=3DA0> 1> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> >> > =3DC2=3DA0> 9223372036854775808 > >> >> > =3DC2=3DA0> 2> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled > FPE a= > >> t > >> >> > =3DC2=3DA0> 0x19223372036854775808 > >> >> > =3DC2=3DA0> 3> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled > FPE a= > >> t > >> >> > =3DC2=3DA0> 0x19223372036854775808 > >> >> > > >> >> > It means that the code at 0x19223372036854775808 in the > >> >> > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. > >> >> > > >> >> > Please attach gdb (or whatever debugger Darwin uses) to a running > >> >> > Erlang VM and disassemble the code at 0x19223372036854775808. > >> >> > We need to know the name of the enclosing function, and preferably > >> >> > also the actual instruction sequence that throws the FPE. If gdb > >> >> > can show the exact original source code line then that's even > better. > >> >> > > >> >> > If this is in libc rather than the Erlang VM itself, then we need > >> >> > a call trace to identify which code in the VM called out to this > >> >> > FP-throwing code. =3DC2=3DA0For that you should probably plant a > break= > >> point > >> >> > at 0x19223372036854775808 and then evaluate one of those Erlang > >> >> > expressions above to trigger the FPE. > >> >> > > >> >> > >> >> Well, it's actually saying 0x1, the result of the trunc is > >> >> 9223372036854775808 =C2=A0and the message string is truncated to 64 > >> >> characters which is not enough to show it all. Perhaps the buffer > size > >> >> in erts_fp_check_init_error should be adjusted. > >> > > >> > Something in your terminal or email client ate a \r\n sequence after > the > >> > 0x1 from erts_fp_check_init_error() making it appear glued together > with > >> > the 9223372036854775808 that the erlang prompt printed. > >> > >> Not my terminal or email client, this is a bug in > >> erts_fp_check_init_error. It only allocates a 64 byte buffer for the > >> error message. The pointer address and the \r\n are eaten because the > >> buffer is too small to fit the whole error message. buf[64] is too > >> small... the format string itself is already 57 chars (including the > >> NULL). > > > > Ah yes. I did see your comment about the short buffer but failed > > to connect that with the strange message. The buffer needs to be at > > least (calculating..) 89 bytes, making it 96 bytes should suffice. > > > > This means that my comment about 0x1 and the wrong type SIGFPE > > handler was invalid. (0x1 is used as a fake PC value in that case.) > > > >> Maybe you missed it in my previous email, it's not 0x1, it is > >> 0x10025433. I showed that by breaking at the function that prints the > >> error. > >> Breakpoint 1, erts_fp_check_init_error (fpexnp=3D0x110f2528) at > >> sys/unix/sys_float.c:87 > >> 87 { > >> (gdb) p (void*)*fpexnp > >> $1 =3D (void *) 0x10025433 > > > > In your previous disassembly that pointed to a cvttsd2siq instruction. > > That can probably throw a SIGFPE, but I see similar code in a build on > > Linux, and there SIGFPE isn't thrown. > > > > If you attach gdb to a freshly started beam instance, let the process > > continue, and evaluate one of those expressions at the Erlang prompt, > > then gdb should wake up with a SIGFPE at that location. At that point > > dump parts of the SSE2 state with: > > > > print $mxcsr (SSE control and status flags) > > print $xmm1 (the source operand in the failing SSE instruction) > > > > (If the first SIGFPE occurs elsewhere, disassemble that code first, then > > adjust the print $xmm1 to match that instruction's source operand.) > > Program received signal EXC_ARITHMETIC, Arithmetic exception. > [Switching to process 14985] > double_to_integer [inlined] () at > /Users/bob/src/otp_src_R14B02/erts/emulator/beam/erl_bif_guard.c:301 > 301 d = x; /* trunc */ > (gdb) info frame > Stack level 0, frame at 0x10: > rip = 0x10025433 in trunc_1 (beam/erl_bif_guard.c:301); saved rip > 0x10025433 > called by frame at 0x0 > source language c. > Arglist at unknown address. > Locals at unknown address, Previous frame's sp in rsp > (gdb) disassemble 0x0000000010025433 > [...] > 0x0000000010025433 : cvttsd2siq %xmm1,%rdx > [...] > (gdb) print $mxcsr > $1 = 6433 > (gdb) print $xmm1 > $2 = { > v4_float = {0, 0, 448, 0}, > v2_double = {0, 9.2233720368547758e+18}, > v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, 67, -32, 0, 0, 0, 0, 0, 0}, > v8_int16 = {0, 0, 0, 0, 17376, 0, 0, 0}, > v4_int32 = {0, 0, 1138753536, 0}, > v2_int64 = {0, 4890909195324358656}, > uint128 = 57411 > } > (gdb) print $rdx > $3 = 16 For the archives - just saw this again on R14B04, Mac OS X. It appears to be fixed in R15A (git 1c99516 from a couple weeks ago) though. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue Nov 29 13:15:34 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 29 Nov 2011 13:15:34 +0100 Subject: [erlang-bugs] scarce dialyzer message "illegal declaration of..." with records In-Reply-To: References: Message-ID: <4ED4CCE6.2070201@cs.ntua.gr> On 11/20/2011 11:56 PM, Samuel wrote: > Hello, > > If you run dialyzer in the attached file it will fail with next message: > > Analysis failed with error: Illegal declaration of #state{parent} > > In the example the problem is pretty obvious, there is a mismatch > between the declared type of the 'parent' field and the function > specification. However in a larger example I found it very hard to > spot. Even worse, if dialyzer is analysing a list of modules it > wouldn't say what module caused the error. (Actually, I ran a very > boring 'shrinking' binary process of deleting code sections until I > found the cause of the error, which happened to be a type annotation > generated by typer before I started refining the specs). Thanks for reporting this issue and sending a minimal test case for it. We very much appreciate it. We have added file and line number information to this error and sent a patch which is included in 'pu'. Hopefully, it will appear in R15. Kostis