From magnus.henoch@REDACTED Thu Dec 1 18:24:30 2011 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Thu, 01 Dec 2011 17:24:30 -0000 (GMT) Subject: [erlang-bugs] mnesia:read returns undefined when getting write lock when sticky_write lock is held In-Reply-To: <92818a4a-e6ae-40e4-99b8-9d353b4149c2@knuth> Message-ID: <85b7e280-3f6d-47ff-8db0-924e7a37600b@knuth> Hi all, I noticed that mnesia:read would return the atom undefined instead of a list of records in some cases, and managed to reduce it to the test case below, which triggers the error in both R14B01 and R15A. This seems to happen when one node holds a sticky lock on a table, and another node calls mnesia:read(Table, Key, write), i.e. reading while getting a write lock. (It wasn't intentional, I was in the process of removing sticky locks and had forgotten one place.) This test case: -module(foo). -include_lib("eunit/include/eunit.hrl"). -export([foo/0]). foo() -> net_kernel:start([foo@REDACTED, shortnames]), {ok, Slave} = slave:start_link(localhost, slave), mnesia:start(), try ?assertEqual(ok, rpc:call(Slave, mnesia, start, [])), ?assertMatch({ok, _}, mnesia:change_config(extra_db_nodes, [Slave])), ?debugVal(mnesia:create_table(foo, [{ram_copies, [node(), Slave]}])), ?assertEqual(ok, rpc:call(Slave, mnesia, wait_for_tables, [[foo], 1000])), ?assertEqual({atomic, ok}, ?debugVal( mnesia:transaction( fun() -> mnesia:write(foo, {foo, 42, a}, sticky_write) end))), ?assertEqual({atomic, [{foo, 42, a}]}, ?debugVal( rpc:call( Slave, mnesia, transaction, [fun mnesia:read/3, [foo, 42, write]]))) after mnesia:stop(), mnesia:delete_schema([node(), Slave]), slave:stop(Slave) end. produces this output: Erlang R15A (erts-5.9.pre) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.pre (abort with ^G) 1> foo:foo(). foo.erl:14:<0.32.0>: mnesia : create_table ( foo , [ { ram_copies , [ node ( ) , Slave ] } ] ) = {atomic, ok} foo.erl:17:<0.32.0>: mnesia : transaction ( fun ( ) -> mnesia : write ( foo , { foo , 42 , a } , sticky_write ) end ) = {atomic, ok} foo.erl:23:<0.32.0>: rpc : call ( Slave , mnesia , transaction , [ fun mnesia : read / 3 , [ foo , 42 , write ] ] ) = {atomic, undefined} =INFO REPORT==== 1-Dec-2011::17:22:22 === application: mnesia exited: stopped type: temporary ** exception error: {assertEqual_failed,[{module,foo}, {line,26}, {expression,"? debugVal ( rpc : call ( Slave , mnesia , transaction , [ fun mnesia : read / 3 , [ foo , 42 , write ] ] ) )"}, {expected,{atomic,[{foo,42,a}]}}, {value,{atomic,undefined}}]} in function foo:'-foo/0-fun-8-'/2 (foo.erl, line 26) in call from foo:foo/0 (foo.erl, line 22) -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From rene.kijewski@REDACTED Thu Dec 1 18:26:50 2011 From: rene.kijewski@REDACTED (=?UTF-8?B?UmVuw6k=?= Kijewski) Date: Thu, 1 Dec 2011 18:26:50 +0100 Subject: [erlang-bugs] "Internal consistency check failed - please report this bug." Message-ID: <20111201182650.3b06768d@rara> Hello, I just got this message: > one_meh.http_utils: function split_at_comma/2+50: > Internal consistency check failed - please report this bug. > Instruction: {put,{x,0}} > Error: {match_context,{x,0}}: Causing file is attached. I compiled Erlang from sources of the git tag OTP_R14B03. > Erlang R14B03 (erts-5.8.4) [source] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] I upgraded to R14B04 but some the same problem. Compiling options where: > ./configure --prefix=... --enable-threads --enable-smp-support > --enable-kernel-poll --disable-sctp --enable-hipe Some more --version information: > Linux _ 2.6.35-30-generic #61-Ubuntu SMP Tue Oct 11 15:29:15 UTC > 2011 i686 GNU/Linux gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) > GNU ld (GNU Binutils for Ubuntu) 2.20.51-system.20100908 > GNU Make 3.81 > autoconf (GNU Autoconf) 2.67 Regards Ren? Kijewski -- Ren? Kijewski Freie Universit?t Berlin ASCII ribbon campaign _ Veterin?rmedizinische Bibliothek against HTML e-mail ( ) Oertzenweg 19b, 14163 Berlin against proprietary attachments X Tel.: 030 838 62652 www.asciiribbon.org / \ -------------- next part -------------- A non-text attachment was scrubbed... Name: html_utils.erl Type: text/x-erlang Size: 4044 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rene.kijewski@REDACTED Thu Dec 1 18:31:12 2011 From: rene.kijewski@REDACTED (=?UTF-8?B?UmVuw6k=?= Kijewski) Date: Thu, 1 Dec 2011 18:31:12 +0100 Subject: [erlang-bugs] "Internal consistency check failed - please report this bug." In-Reply-To: <20111201182650.3b06768d@rara> References: <20111201182650.3b06768d@rara> Message-ID: <20111201183112.79432a81@rara> Am Thu, 1 Dec 2011 18:26:50 +0100 schrieb Ren? Kijewski : > Causing file is attached. Sorry, I attached a wrong file. :-/ Right one here. -- Ren? Kijewski Freie Universit?t Berlin ASCII ribbon campaign _ Veterin?rmedizinische Bibliothek against HTML e-mail ( ) Oertzenweg 19b, 14163 Berlin against proprietary attachments X Tel.: 030 838 62652 www.asciiribbon.org / \ -------------- next part -------------- A non-text attachment was scrubbed... Name: http_utils.erl Type: text/x-erlang Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dgud@REDACTED Thu Dec 1 18:34:49 2011 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 1 Dec 2011 18:34:49 +0100 Subject: [erlang-bugs] mnesia:read returns undefined when getting write lock when sticky_write lock is held In-Reply-To: <85b7e280-3f6d-47ff-8db0-924e7a37600b@knuth> References: <92818a4a-e6ae-40e4-99b8-9d353b4149c2@knuth> <85b7e280-3f6d-47ff-8db0-924e7a37600b@knuth> Message-ID: Thanks for the bug report and thanks for the excellent tests. /Dan On Thu, Dec 1, 2011 at 6:24 PM, Magnus Henoch wrote: > Hi all, > > I noticed that mnesia:read would return the atom undefined instead of > a list of records in some cases, and managed to reduce it to the test > case below, which triggers the error in both R14B01 and R15A. > > This seems to happen when one node holds a sticky lock on a table, and > another node calls mnesia:read(Table, Key, write), i.e. reading while > getting a write lock. ?(It wasn't intentional, I was in the process of > removing sticky locks and had forgotten one place.) > > This test case: > > -module(foo). > > -include_lib("eunit/include/eunit.hrl"). > > -export([foo/0]). > > foo() -> > ? ?net_kernel:start([foo@REDACTED, shortnames]), > ? ?{ok, Slave} = slave:start_link(localhost, slave), > ? ?mnesia:start(), > ? ?try > ? ? ? ??assertEqual(ok, rpc:call(Slave, mnesia, start, [])), > ? ? ? ??assertMatch({ok, _}, mnesia:change_config(extra_db_nodes, [Slave])), > ? ? ? ??debugVal(mnesia:create_table(foo, [{ram_copies, [node(), Slave]}])), > ? ? ? ??assertEqual(ok, rpc:call(Slave, mnesia, wait_for_tables, [[foo], 1000])), > ? ? ? ??assertEqual({atomic, ok}, > ? ? ? ? ? ? ? ? ? ? ?debugVal( > ? ? ? ? ? ? ? ? ? ? ? ?mnesia:transaction( > ? ? ? ? ? ? ? ? ? ? ? ? ?fun() -> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mnesia:write(foo, {foo, 42, a}, sticky_write) > ? ? ? ? ? ? ? ? ? ? ? ? ?end))), > ? ? ? ??assertEqual({atomic, [{foo, 42, a}]}, > ? ? ? ? ? ? ? ? ? ? ?debugVal( > ? ? ? ? ? ? ? ? ? ? ? ?rpc:call( > ? ? ? ? ? ? ? ? ? ? ? ? ?Slave, mnesia, transaction, > ? ? ? ? ? ? ? ? ? ? ? ? ?[fun mnesia:read/3, [foo, 42, write]]))) > ? ?after > ? ? ? ?mnesia:stop(), > ? ? ? ?mnesia:delete_schema([node(), Slave]), > ? ? ? ?slave:stop(Slave) > ? ?end. > > produces this output: > > Erlang R15A (erts-5.9.pre) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9.pre ?(abort with ^G) > 1> foo:foo(). > foo.erl:14:<0.32.0>: mnesia : create_table ( foo , [ { ram_copies , [ node ( ) , Slave ] } ] ) = {atomic, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ok} > foo.erl:17:<0.32.0>: mnesia : transaction ( fun ( ) -> mnesia : write ( foo , { foo , 42 , a } , sticky_write ) end ) = {atomic, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok} > foo.erl:23:<0.32.0>: rpc : call ( Slave , mnesia , transaction , [ fun mnesia : read / 3 , [ foo , 42 , write ] ] ) = {atomic, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?undefined} > > =INFO REPORT==== 1-Dec-2011::17:22:22 === > ? ?application: mnesia > ? ?exited: stopped > ? ?type: temporary > ** exception error: {assertEqual_failed,[{module,foo}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {line,26}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {expression,"? debugVal ( rpc : call ( Slave , mnesia , transaction , [ fun mnesia : read / 3 , [ foo , 42 , write ] ] ) )"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {expected,{atomic,[{foo,42,a}]}}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {value,{atomic,undefined}}]} > ? ? in function ?foo:'-foo/0-fun-8-'/2 (foo.erl, line 26) > ? ? in call from foo:foo/0 (foo.erl, line 22) > > > -- > Magnus Henoch > Erlang Solutions Ltd > http://www.erlang-solutions.com/ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From bgustavsson@REDACTED Fri Dec 2 15:22:05 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 2 Dec 2011 15:22:05 +0100 Subject: [erlang-bugs] "Internal consistency check failed - please report this bug." In-Reply-To: <20111201183112.79432a81@rara> References: <20111201182650.3b06768d@rara> <20111201183112.79432a81@rara> Message-ID: On 12/1/11, Ren? Kijewski wrote: > Am Thu, 1 Dec 2011 18:26:50 +0100 > schrieb Ren? Kijewski : > >> Causing file is attached. > > Sorry, I attached a wrong file. :-/ > > Right one here. > I can't reproduce the problem. I have tried R14B03, R14B04, and 'master' from the git repository. You are sure this is the right file? Any specific compilation options needed? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From rene.kijewski@REDACTED Fri Dec 2 17:13:32 2011 From: rene.kijewski@REDACTED (Rene Kijewski) Date: Fri, 2 Dec 2011 17:13:32 +0100 Subject: [erlang-bugs] "Internal consistency check failed - please report this bug." In-Reply-To: References: <20111201182650.3b06768d@rara> <20111201183112.79432a81@rara> Message-ID: <20111202171332.6d55d88d@lappy-ng.localdomain> Am Fri, 2 Dec 2011 15:22:05 +0100 schrieb Bj?rn Gustavsson : > I can't reproduce the problem. I have tried R14B03, > R14B04, and 'master' from the git repository. > > You are sure this is the right file? Any specific > compilation options needed? Hello Bj?rn, I can reproduce the problem at home (64bit, R14B03), too, so I can rule out that it is a word size problem. I re-attached the file so we can be sure we are talking about the same file(, after my messing up with the first mail). The exact line I use to compile the file (while being in $ROOT, and the file residing in $ROOT/src/one_meh/http_utils.erl): > $ erlc +debug_info +inline +'{inline_effort,1000}' +'{inline_size,100}' +'{inline_unroll,2}' -I deps -I include -o ebin/one_meh src/one_meh/http_utils.erl > one_meh.http_utils: function split_at_comma/2+50: > Internal consistency check failed - please report this bug. > Instruction: {put,{x,0}} > Error: {match_context,{x,0}}: > (No further text after the colon.) After updating to master (6971b9618b629014127c1e6d0a12343dbe864f58), the problem is still present (seemingly one bit later, though :-) ): > one_meh.http_utils: function split_at_comma/2+51: > Internal consistency check failed - please report this bug. > Instruction: {put,{x,0}} > Error: {match_context,{x,0}}: I built Erlang using: > git clean -xfd > ./otp_build setup --enable-m64-build --enable-hipe --disable-sctp --enable-kernel-poll --enable-smp-support --enable-threads Some version information: * Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] * Ubuntu 11.10 * Linux _ 3.2.0-2-generic #4-Ubuntu SMP Sun Nov 27 15:32:08 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux * gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) * GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 * GNU Make 3.81 * autoconf (GNU Autoconf) 2.68 * install (GNU coreutils) 8.5 Regards, Ren? -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: http_utils.erl Type: text/x-erlang Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bgustavsson@REDACTED Sat Dec 3 11:09:02 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sat, 3 Dec 2011 11:09:02 +0100 Subject: [erlang-bugs] "Internal consistency check failed - please report this bug." In-Reply-To: <20111202171332.6d55d88d@lappy-ng.localdomain> References: <20111201182650.3b06768d@rara> <20111201183112.79432a81@rara> <20111202171332.6d55d88d@lappy-ng.localdomain> Message-ID: 2011/12/2 Rene Kijewski : > The exact line I use to compile the file (while being in $ROOT, and the file residing in $ROOT/src/one_meh/http_utils.erl): >> $ erlc +debug_info +inline +'{inline_effort,1000}' +'{inline_size,100}' +'{inline_unroll,2}' -I deps -I include -o ebin/one_meh src/one_meh/http_utils.erl >> one_meh.http_utils: function split_at_comma/2+50: >> ? Internal consistency check failed - please report this bug. >> ? Instruction: {put,{x,0}} >> ? Error: ? ? ? {match_context,{x,0}}: >> > (No further text after the colon.) Thanks! Now I can reproduce the problem. Since we are already late in the development cycle for R15B, I can't promise that we can fix the problem in R15B. By the way, have you done any measurements to find out whether you gain anything by doing such aggressive inlining? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From tuncer.ayaz@REDACTED Sat Dec 3 17:05:12 2011 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 3 Dec 2011 17:05:12 +0100 Subject: [erlang-bugs] binary:matches/3 fails in R14A In-Reply-To: References: Message-ID: 2010/8/25 Bartosz Ko?odziej: > binary:split/3 fails when option "global" is set and input is an empty > binary. > > 1> binary:split(<<>>,<<"a">>,[global]) gives: > ** exception error: bad argument > ? ? in function ?binary:split/3 Seems to be fixed in OTP_R15A-180-g6971b96. 1> binary:split(<<>>,<<"a">>,[global]). [<<>>] > The problem lays in binary:matches/3 function: > > 2> binary:matches(<<>>,<<"a">>,[global]). > ** exception error: bad argument > ? ? in function ?binary:matches/3 > ? ? ? ?called as binary:matches(<<>>,<<"a">>,[global]) > > Without "global" option it works just fine. Same badarg in OTP_R15A-180-g6971b96. From thomas@REDACTED Thu Dec 8 15:14:16 2011 From: thomas@REDACTED (Thomas Lange) Date: Thu, 08 Dec 2011 15:14:16 +0100 Subject: [erlang-bugs] Wrong EXIT status when shell startup fails Message-ID: <4EE0C638.7000400@corelatus.se> There is a bug that occurs when Erlang is started with shell activated but shell cannot be launched. When this happens, erlang terminates with exit status 0, which is incorrect behavior. A typical example is when Erlang is started via a cron job. How to trigger bug: * Put both attached files in /tmp * update crontest with path to your otp release * compile crontest.erl * run /tmp/crontest via cron * cronjob should fail Example on system running debian squeeze and otp git HEAD: ------------------------------------------ k4:/tmp$ chmod +x crontest k4:/tmp$ /u1/otp/bin/erlc crontest.erl k4:/tmp$ ls -l crontest* -rwxr-xr-x 1 tle tle 681 Dec 8 14:42 crontest -rw-r--r-- 1 tle tle 536 Dec 8 14:45 crontest.beam -rw-r--r-- 1 tle tle 83 Dec 8 14:42 crontest.erl k4:/tmp$ ./crontest Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> Erlang exit status 100. Normal result when everything is started ok. k4:/tmp$ crontab -e crontab: installing new crontab k4:/tmp$ crontab -l # m h dom mon dow command 47 14 * * * /tmp/crontest Syslog: Dec 8 14:47:02 k4 /USR/SBIN/CRON[27923]: (CRON) error (grandchild #27924 failed with exit status 1) Cron daemon error mail contains: ---------------- Eshell V5.9 (abort with ^G) 1> *** Terminating erlang (nonode@REDACTED) Erlang exit status 0. Should never happen! ---------------- /Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: crontest.erl Type: text/x-erlang Size: 83 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crontest URL: From dcartt@REDACTED Thu Dec 8 23:40:34 2011 From: dcartt@REDACTED (David Cartt) Date: Thu, 8 Dec 2011 14:40:34 -0800 Subject: [erlang-bugs] dets:from_ets EXIT error caused by large ets table and binary filename used in dets:open_file Message-ID: I'm getting an 'EXIT' error response from a call to dets:from_ets. The error response is shown below. Steps to reproduce: Do dets:open_file/2 with a binary() type filename, then a dets:from_ets/2 where the ets table is large (small ets tables don't cause the error). My guess is that the ets table needs to be large enough that the dets:from_ets needs to use a temporary file. Don't know if this matters, but in my case the dets:open_file always creates a new file and the ets table is type ordered_set.. The documentation for dets:open_file/2 states that the filename for the file option can be a binary: {file, file:name()}. file:name() includes the binary() type. dets:from_ets return result: {'EXIT',{function_clause,[{lists,thing_to_list, [<<"d:/misc/workspaces/Erlang workspace/test1/scratch/fs_Node_test1@REDACTED">>]}, {lists,flatmap,2}, {file_sorter,next_temp,1}, {file_sorter,write_run,2}, {file_sorter,fun_run,5}, {file_sorter,do_sort,5}, {dets,do_sort,6}, {dets,do_finit,4}]}} Code fragment: DetsName = <<"db.dets">>, Filename = filename:join(<<"d:/misc/workspaces/Erlang workspace/test1/scratch">>, DetsName), {error, enoent} = file:read_link_info(Filename), %make sure the name is unique {ok, DetsName} = dets:open_file(DetsName, [{file, Filename} , {type, set}, {ram_file, true}]), ok = dets:from_ets(DetsName, EtsName), A "exception error: no match of right hand side value" exception occurs on the "ok = dets:from_ets(DetsName, EtsName)" statement, obviously because ok /= {'EXIT', ...}. Changing the {file, Filename} option to {file, binary_to_list(Filename)} makes the error go away. The resultant dets table is about 2MB in size. OS: Windows 7 64 bit Erlang version (installed from the R14B04 release Windows Binary File download) (erl +V): Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.8.5 Node name (node()): Node_test1@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Fri Dec 9 15:43:27 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Fri, 9 Dec 2011 15:43:27 +0100 Subject: [erlang-bugs] erlang/odbc <-> ms-sql error with 'uniqueidentifiers' (aka GUIDs): ODBC_UNSUPPORTED_TYPE Message-ID: I try to connect to one of our companies Microsoft SQL databases using Erlang/OTP R14B04 running on an Ubuntu 10.04 64 Bit installation (using the FreeTDS drivers from the Ubuntu repositories). The problem I have is, that the Erlang ODBC module can't handle 'uniqueidentifier' (aka GUID) fields in tables. For example a 'select *' doesn't work, but when I only select the non-uniqueidentifier fields from the same table it works. On the other hand, when I use the "isql" (commandline-)tool with the same ODBC connection, I don't get any errors. So I would say that something within the Erlang ODBC module is broken (I believe it is in "odbcserver.c"). Is this a known bug, or did I miss anything? Regards, Boris From ingela@REDACTED Fri Dec 9 15:56:45 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 9 Dec 2011 15:56:45 +0100 Subject: [erlang-bugs] erlang/odbc <-> ms-sql error with 'uniqueidentifiers' (aka GUIDs): ODBC_UNSUPPORTED_TYPE In-Reply-To: References: Message-ID: <4EE221AD.7050100@erix.ericsson.se> Hi! It seems to be a missing feature. Support for the data_type SQL_GUID is not implemented. I do not think it would be all that hard to implement but will not be highly prioritized by Ericsson. Maybe somebody would like to make a user-contribution?! You should start looking at the funtion encode_data_type in odbcserver.c Regards Ingela Erlang/OTP team - Ericsson AB Boris M?hmer wrote: > I try to connect to one of our companies Microsoft SQL databases using > Erlang/OTP R14B04 running on an Ubuntu 10.04 64 Bit installation > (using the FreeTDS drivers from the Ubuntu repositories). > > The problem I have is, that the Erlang ODBC module can't handle > 'uniqueidentifier' (aka GUID) fields in tables. For example a 'select > *' doesn't work, but when I only select the non-uniqueidentifier > fields from the same table it works. > > On the other hand, when I use the "isql" (commandline-)tool with the > same ODBC connection, I don't get any errors. > > So I would say that something within the Erlang ODBC module is broken > (I believe it is in "odbcserver.c"). > > Is this a known bug, or did I miss anything? > > > Regards, > Boris > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From magnus.klaar@REDACTED Fri Dec 9 22:34:45 2011 From: magnus.klaar@REDACTED (Magnus Klaar) Date: Fri, 9 Dec 2011 22:34:45 +0100 Subject: [erlang-bugs] R14B04 and R15A: Possible bug when compiling code using binary expressions with hipe Message-ID: Hi! We found some code that successfully compiles to bytecode and behaves as expected using the beam interpreter but fails to compile using the hipe compiler. The code in questions is the 'cowboy_http' module in the cowboy web server. The code is available to browse online at https://github.com/extend/cowboy The module contains many occurances of <<..., Var/bits>> patterns. Replacing all occurances of "bits" with "binary" solves the problem. I tried this because the code is only working on character strings, matching out bitstrings doesn't make much sense to begin with. I have reproduced the error on 64bit builds of the R14B04 and R15A releases under GNU/Linux (Debian wheezy). I did not try older releases to check if it is a new issue. To reproduce the error. Execute the following steps on a system with either one of these releases installed. I'm using R15A here because the line numbers in the error messages are pretty useful to include in a bug report. (thanks for this addition of line numbers in R15). 1. Download, compile and run tests using bytecode interpreter git clone git://github.com/extend/cowboy.git cd cowboy git checkout 168405830d564ff87fac61bd990c17ab6a35dfa8 # in case the code is updated rebar get-deps rebar compile rebar eunit skip_deps=true 2. Add native to the erl_opts parameter list in rebar.config vim rebar.config # add it under warn_export_all 3. Recompile using hipe rebar clean rebar compile 4. Expect an output containing these error messages ==> cowboy (compile) Compiled src/cowboy_http_handler.erl Compiled src/cowboy_http_websocket_handler.erl Compiled src/cowboy_protocol.erl Compiled src/cowboy.erl Compiled src/cowboy_app.erl Compiled src/cowboy_acceptors_sup.erl Compiled src/cowboy_acceptor.erl Compiled src/cowboy_bstr.erl Compiled src/cowboy_dispatcher.erl EXITED with reason {function_clause,[{hipe_rtl_binary_match,gen_rtl,[{bs_match_string,<<34>>,1},[],[{rtl_var,21}],17,6],[{file,[104,105,112,101,95,114,116,108,95,98,105,110,97,114,121,95,109,97,116,99,104,46,101,114,108]},{line,45}]},{hipe_rtl_binary,gen_rtl,7,[{file,[104,105,112,101,95,114,116,108,95,98,105,110,97,114,121,46,101,114,108]},{line,33}]},{hipe_rtl_primops,gen_primop,3,[{file,[104,105,112,101,95,114,116,108,95,112,114,105,109,111,112,115,46,101,114,108]},{line,147}]},{hipe_icode2rtl,gen_call,3,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,189}]},{hipe_icode2rtl,translate_instrs,5,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,104}]},{hipe_icode2rtl,translate,2,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,71}]},{hipe_main,translate_to_rtl,2,[{file,[104,105,112,101,95,109,97,105,110,46,101,114,108]},{line,396}]},{hipe_main,icode_to_rtl,4,[{file,[104,105,112,101,95,109,97,105,110,46,101,114,108]},{line,376}]}]} @hipe:867 =ERROR REPORT==== 9-Dec-2011::22:18:06 === Error: [hipe:866]: ERROR: {function_clause, [{hipe_rtl_binary_match, gen_rtl, [{bs_match_string,<<"\"">>, 1}, [], [{rtl_var,21}], 17,6], [{file, "hipe_rtl_binary_match.erl"}, {line,45}]}, {hipe_rtl_binary,gen_rtl,7, [{file, "hipe_rtl_binary.erl"}, {line,33}]}, {hipe_rtl_primops, gen_primop,3, [{file, "hipe_rtl_primops.erl"}, {line,147}]}, {hipe_icode2rtl,gen_call,3, [{file,"hipe_icode2rtl.erl"}, {line,189}]}, {hipe_icode2rtl, translate_instrs,5, [{file,"hipe_icode2rtl.erl"}, {line,104}]}, {hipe_icode2rtl,translate,2, [{file,"hipe_icode2rtl.erl"}, {line,71}]}, {hipe_main,translate_to_rtl, 2, [{file,"hipe_main.erl"}, {line,396}]}, {hipe_main,icode_to_rtl,4, [{file,"hipe_main.erl"}, {line,376}]}]} =ERROR REPORT==== 9-Dec-2011::22:18:06 === Error in process <0.788.0> with exit value: {{hipe,867,{function_clause,[{hipe_rtl_binary_match,gen_rtl,[{bs_match_string,<<1 byte>>,1},[],[{rtl_var,21}],17,6],[{file,"hipe_rtl_binary_match.erl"},{line,45}]},{hipe_rtl_binary,gen_rtl,7,[{file,"hipe_rtl_binary.erl"},{line,33}]},{hipe_rtl_primops... src/cowboy_http.erl:none: internal error in native_compile; crash reason: {{hipe,867, {function_clause, [{hipe_rtl_binary_match,gen_rtl, [{bs_match_string,<<"\"">>,1}, [], [{rtl_var,21}], 17,6], [{file,"hipe_rtl_binary_match.erl"},{line,45}]}, {hipe_rtl_binary,gen_rtl,7, [{file,"hipe_rtl_binary.erl"},{line,33}]}, {hipe_rtl_primops,gen_primop,3, [{file,"hipe_rtl_primops.erl"},{line,147}]}, {hipe_icode2rtl,gen_call,3, [{file,"hipe_icode2rtl.erl"},{line,189}]}, {hipe_icode2rtl,translate_instrs,5, [{file,"hipe_icode2rtl.erl"},{line,104}]}, {hipe_icode2rtl,translate,2, [{file,"hipe_icode2rtl.erl"},{line,71}]}, {hipe_main,translate_to_rtl,2, [{file,"hipe_main.erl"},{line,396}]}, {hipe_main,icode_to_rtl,4, [{file,"hipe_main.erl"},{line,376}]}]}}, [{hipe,finalize_fun_sequential,3, [{file,"hipe.erl"},{line,867}]}, {hipe,'-finalize_fun_concurrent/3-fun-3-',4, [{file,"hipe.erl"},{line,833}]}]} I hope this is enough information to reproduce the issue once it hits someones desk at the other side of the internet. / Magnus Klaar -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Sat Dec 10 08:36:47 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Sat, 10 Dec 2011 08:36:47 +0100 Subject: [erlang-bugs] erlang/odbc <-> ms-sql error with 'uniqueidentifiers' (aka GUIDs): ODBC_UNSUPPORTED_TYPE In-Reply-To: <4EE221AD.7050100@erix.ericsson.se> References: <4EE221AD.7050100@erix.ericsson.se> Message-ID: Well, maybe I will be able to do such a user-contribution, because either I get it running, find another way to access the Microsoft SQL server from Erlang, or drop Erlang/OTP (nothing I want to do). I started to have a closer look at "odbcserver.c". My first success was to get a SELECT query with a GUID "working". My question now is: what would be the "best" Erlang representation for a GUID? The C structure behind a GUID is (found in "sqltypes.h"): typedef struct tagSQLGUID { DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[ 8 ]; } SQLGUID; For my 1st hack I used the following statements to transform this struct to an Erlang tuple: psg = (SQLGUID*)column.buffer; ei_x_encode_tuple_header(&dynamic_buffer(state), 4); ei_x_encode_ulong(&dynamic_buffer(state), psg->Data1); ei_x_encode_ulong(&dynamic_buffer(state), psg->Data2); ei_x_encode_ulong(&dynamic_buffer(state), psg->Data3); ei_x_encode_tuple_header(&dynamic_buffer(state), 8); for(i=0; i<8; i++){ ei_x_encode_char(&dynamic_buffer(state), psg->Data4[i]); } For example, this conversion results in: 19BCB12A-E6D1-4E58-A841-30F794C614FA => {{431796522,59089,20056,{168,65,48,247,148,198,20,250}} 703F9C47-F1B9-407E-847D-34840AC1E346 => {1883216967,61881,16510,{132,125,52,132,10,193,227,70}} Somewhat odd to see how the C struct looks and how Microsoft "displays" a GUID. Should the Erlang representation be changed? Currently, I don't care about how it is displayed; of course it would be nice to see something more similar to the Microsoft way, on the other hand, it must't be converted back in the c-driver. Would be a bit-string better? Or just use a 128 Bit value? I really like to get some input on this. - boris 2011/12/9 Ingela Anderton Andin : > Hi! > > It seems to be a missing feature. Support for the data_type SQL_GUID is not > implemented. > I do not think it would be all that hard to implement but will not be highly > prioritized by Ericsson. > Maybe somebody would like to make a user-contribution?! You should start > looking at the > funtion encode_data_type in odbcserver.c > > Regards Ingela Erlang/OTP team - Ericsson AB > > Boris M?hmer wrote: >> >> I try to connect to one of our companies Microsoft SQL databases using >> Erlang/OTP R14B04 running on an Ubuntu 10.04 64 Bit installation >> (using the FreeTDS drivers from the Ubuntu repositories). >> >> The problem I have is, that the Erlang ODBC module can't handle >> 'uniqueidentifier' (aka GUID) fields in tables. For example a 'select >> *' doesn't work, but when I only select the non-uniqueidentifier >> fields from the same table it works. >> >> On the other hand, when I use the "isql" (commandline-)tool with the >> same ODBC connection, I don't get any errors. >> >> So I would say that something within the Erlang ODBC module is broken >> (I believe it is in "odbcserver.c"). >> >> Is this a known bug, or did I miss anything? >> >> >> Regards, >> Boris >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > From kostis@REDACTED Sat Dec 10 10:14:51 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 10 Dec 2011 11:14:51 +0200 Subject: [erlang-bugs] R14B04 and R15A: Possible bug when compiling code using binary expressions with hipe In-Reply-To: References: Message-ID: <4EE3230B.30409@cs.ntua.gr> On 12/09/11 23:34, Magnus Klaar wrote: > Hi! > > We found some code that successfully compiles to bytecode and behaves as > expected using the beam interpreter but fails to compile using the hipe > compiler. The code in questions is the 'cowboy_http' module in the > cowboy web server. The code is available to browse online at > https://github.com/extend/cowboy > > The module contains many occurances of <<..., Var/bits>> patterns. > Replacing all occurances of "bits" with "binary" solves the problem. I > tried this because the code is only working on character strings, > matching out bitstrings doesn't make much sense to begin with. I have > reproduced the error on 64bit builds of the R14B04 and R15A releases > under GNU/Linux (Debian wheezy). I did not try older releases to check > if it is a new issue. > > To reproduce the error. Execute the following steps on a system with > either one of these releases installed.... Thanks for the bug report. This was mote than enough information to reproduce the compiler crash and pinpoint where it occurs. For the file that contains it, it happens in function word/2 and I suggest that for the time being you modify the first clause of that function to contain _/binary instead of _/bits. This will bypass the problem and I think it will allow cowboy to be compiled to native code. However, the native compiler crash should be fixed. It really boils down to the following code: -module(cowboy). -export([f/1]). f(<<42, _/bits>> = B) -> B. for which the BEAM compiler produces: label 1: {func_info,{atom,cowboy},{atom,f},1} label 2: {test,bs_start_match2,{f,1},[{x,0},1,0,{x,1}]} {test,bs_match_string,{f,1},[{x,1},8,<<"*">>]} return This is obviously correct BEAM code, but I think it's suboptimal. I would have expected some lighter-weight instruction instead of a bs_match_string one, which presumably involves some loop in its implementation. Bjorn what say you? Anyway, the crash is not due to that. It's due to this instruction not being followed by some other one, like a bs_check_unit or a bs_test_tail. This confuses the native code compiler. I will fix this, but I am afraid it's too late for R15B. Kostis From magnus.klaar@REDACTED Sat Dec 10 17:37:59 2011 From: magnus.klaar@REDACTED (Magnus Klaar) Date: Sat, 10 Dec 2011 17:37:59 +0100 Subject: [erlang-bugs] R14B04 and R15A: Possible bug when compiling code using binary expressions with hipe In-Reply-To: <4EE3230B.30409@cs.ntua.gr> References: <4EE3230B.30409@cs.ntua.gr> Message-ID: On Sat, Dec 10, 2011 at 10:14 AM, Kostis Sagonas wrote: > > > Thanks for the bug report. This was mote than enough information to > reproduce the compiler crash and pinpoint where it occurs. For the file > that contains it, it happens in function word/2 and I suggest that for the > time being you modify the first clause of that function to contain _/binary > instead of _/bits. This will bypass the problem and I think it will allow > cowboy to be compiled to native code. > > > However, the native compiler crash should be fixed. It really boils down > to the following code: > > -module(cowboy). > -export([f/1]). > > f(<<42, _/bits>> = B) -> B. > > for which the BEAM compiler produces: > > label 1: > {func_info,{atom,cowboy},{**atom,f},1} > label 2: > {test,bs_start_match2,{f,1},[{**x,0},1,0,{x,1}]} > {test,bs_match_string,{f,1},[{**x,1},8,<<"*">>]} > return > > This is obviously correct BEAM code, but I think it's suboptimal. I would > have expected some lighter-weight instruction instead of a bs_match_string > one, which presumably involves some loop in its implementation. Bjorn what > say you? > > Anyway, the crash is not due to that. It's due to this instruction not > being followed by some other one, like a bs_check_unit or a bs_test_tail. > This confuses the native code compiler. > > I will fix this, but I am afraid it's too late for R15B. > > Kostis > Hi! Thanks for the quick reply and for verifying that my approach to working around the issue wasn't completely brain dead (better safe than sorry). / Magnus Klaar -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Sun Dec 11 10:42:58 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 11 Dec 2011 10:42:58 +0100 Subject: [erlang-bugs] R14B04 and R15A: Possible bug when compiling code using binary expressions with hipe In-Reply-To: <4EE3230B.30409@cs.ntua.gr> References: <4EE3230B.30409@cs.ntua.gr> Message-ID: On Sat, Dec 10, 2011 at 10:14 AM, Kostis Sagonas wrote: [...] > However, the native compiler crash should be fixed. ?It really boils down to > the following code: > > ?-module(cowboy). > ?-export([f/1]). > > ?f(<<42, _/bits>> = B) -> B. > > for which the BEAM compiler produces: > > ?label 1: > ? ?{func_info,{atom,cowboy},{atom,f},1} > ?label 2: > ? ?{test,bs_start_match2,{f,1},[{x,0},1,0,{x,1}]} > ? ?{test,bs_match_string,{f,1},[{x,1},8,<<"*">>]} > ? ?return > > This is obviously correct BEAM code, but I think it's suboptimal. I would > have expected some lighter-weight instruction instead of a bs_match_string > one, which presumably involves some loop in its implementation. ?Bjorn what > say you? It is not obvious to me without measuring. If you don't use bs_match_string, you will need one more instruction: label 1: {func_info,{atom,cowboy},{atom,f},1} label 2: {test,bs_start_match2,{f,1},[{x,0},1,0,{x,1}]} {test,bs_get_integer2,{f,1},2,[{x,1},{integer,8}, 1,{field_flags,[{anno,[5,{file,"t.erl"}]},unsigned,big]}], {x,2}}. {test,is_eq_exact,{f,1},[{x,2},{integer,42}]}. return. That is, one instruction to retrieve 8 bits from the binary and one instruction to compare that it is equal to 42. Provided that the binary is aligned on a byte boundary, bs_match_string will use memcmp(). I think that GCC will inline calls to memcmp(), but I have no idea how efficient it will be for a size value of one. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ingela@REDACTED Mon Dec 12 12:18:50 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 12 Dec 2011 12:18:50 +0100 Subject: [erlang-bugs] erlang/odbc <-> ms-sql error with 'uniqueidentifiers' (aka GUIDs): ODBC_UNSUPPORTED_TYPE In-Reply-To: References: <4EE221AD.7050100@erix.ericsson.se> Message-ID: <4EE5E31A.3080606@erix.ericsson.se> Hi! I probably am not the best person to comment on this as I do not use SQL-databases very much and do not know how GUIDs are used. Maybe someone else can help me out? Generally if you should convert the value it would probably be easier to do the conversion in the erlang-code and always let the c-code get what it expects. Regards Ingela Erlang/OTP-team -Ericsson AB Boris M?hmer wrote: > Well, maybe I will be able to do such a user-contribution, because > either I get it running, find another way to access the Microsoft SQL > server from Erlang, or drop Erlang/OTP (nothing I want to do). > > I started to have a closer look at "odbcserver.c". My first success > was to get a SELECT query with a GUID "working". > > My question now is: what would be the "best" Erlang representation for a GUID? > > The C structure behind a GUID is (found in "sqltypes.h"): > typedef struct tagSQLGUID > { > DWORD Data1; > WORD Data2; > WORD Data3; > BYTE Data4[ 8 ]; > } SQLGUID; > > For my 1st hack I used the following statements to transform this > struct to an Erlang tuple: > psg = (SQLGUID*)column.buffer; > ei_x_encode_tuple_header(&dynamic_buffer(state), 4); > ei_x_encode_ulong(&dynamic_buffer(state), psg->Data1); > ei_x_encode_ulong(&dynamic_buffer(state), psg->Data2); > ei_x_encode_ulong(&dynamic_buffer(state), psg->Data3); > ei_x_encode_tuple_header(&dynamic_buffer(state), 8); > for(i=0; i<8; i++){ > ei_x_encode_char(&dynamic_buffer(state), psg->Data4[i]); > } > > For example, this conversion results in: > 19BCB12A-E6D1-4E58-A841-30F794C614FA => > {{431796522,59089,20056,{168,65,48,247,148,198,20,250}} > > 703F9C47-F1B9-407E-847D-34840AC1E346 => > {1883216967,61881,16510,{132,125,52,132,10,193,227,70}} > > Somewhat odd to see how the C struct looks and how Microsoft "displays" a GUID. > > Should the Erlang representation be changed? Currently, I don't care > about how it is displayed; of course it would be nice to see something > more similar to the Microsoft way, on the other hand, it must't be > converted back in the c-driver. Would be a bit-string better? Or just > use a 128 Bit value? > > I really like to get some input on this. > > > - boris > > > 2011/12/9 Ingela Anderton Andin : > >> Hi! >> >> It seems to be a missing feature. Support for the data_type SQL_GUID is not >> implemented. >> I do not think it would be all that hard to implement but will not be highly >> prioritized by Ericsson. >> Maybe somebody would like to make a user-contribution?! You should start >> looking at the >> funtion encode_data_type in odbcserver.c >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> Boris M?hmer wrote: >> >>> I try to connect to one of our companies Microsoft SQL databases using >>> Erlang/OTP R14B04 running on an Ubuntu 10.04 64 Bit installation >>> (using the FreeTDS drivers from the Ubuntu repositories). >>> >>> The problem I have is, that the Erlang ODBC module can't handle >>> 'uniqueidentifier' (aka GUID) fields in tables. For example a 'select >>> *' doesn't work, but when I only select the non-uniqueidentifier >>> fields from the same table it works. >>> >>> On the other hand, when I use the "isql" (commandline-)tool with the >>> same ODBC connection, I don't get any errors. >>> >>> So I would say that something within the Erlang ODBC module is broken >>> (I believe it is in "odbcserver.c"). >>> >>> Is this a known bug, or did I miss anything? >>> >>> >>> Regards, >>> Boris >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >>> >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From hynek@REDACTED Mon Dec 12 15:14:57 2011 From: hynek@REDACTED (Hynek Vychodil) Date: Mon, 12 Dec 2011 15:14:57 +0100 Subject: [erlang-bugs] erlang/odbc <-> ms-sql error with 'uniqueidentifiers' (aka GUIDs): ODBC_UNSUPPORTED_TYPE In-Reply-To: <4EE5E31A.3080606@erix.ericsson.se> References: <4EE221AD.7050100@erix.ericsson.se> <4EE5E31A.3080606@erix.ericsson.se> Message-ID: Hi, So in other words keep it in binary and split as needed? ei_x_encode_binary(&dynamic_buffer(state), (const void *)column.buffer, sizeof(SQLGUID)); and in erlang you can do what you want. I think GUID is mostly used as opaque reference like ref in erlang so I would also prefer let it be as binary. It is simple, fast and least memory consuming. Regards Hynek On Mon, Dec 12, 2011 at 12:18 PM, Ingela Anderton Andin wrote: > Hi! > > I probably ?am not the best person to comment on this as I do not use > SQL-databases very much and do not know how GUIDs are used. ?Maybe someone > else can help me out? Generally if you should convert ?the value it would > probably be easier to do the conversion in the erlang-code and always let > the c-code get what it expects. > > Regards Ingela Erlang/OTP-team ?-Ericsson AB > > > Boris M?hmer wrote: >> >> Well, maybe I will be able to do such a user-contribution, because >> either I get it running, find another way to access the Microsoft SQL >> server from Erlang, or drop Erlang/OTP (nothing I want to do). >> >> I started to have a closer look at "odbcserver.c". My first success >> was to get a SELECT query with a GUID "working". >> >> My question now is: what would be the "best" Erlang representation for a >> GUID? >> >> The C structure behind a GUID is (found in "sqltypes.h"): >> ? ?typedef struct ?tagSQLGUID >> ? ?{ >> ? ? ? ?DWORD Data1; >> ? ? ? ?WORD Data2; >> ? ? ? ?WORD Data3; >> ? ? ? ?BYTE Data4[ 8 ]; >> ? ?} SQLGUID; >> >> For my 1st hack I used the following statements to transform this >> struct to an Erlang tuple: >> ? ? ? ?psg = (SQLGUID*)column.buffer; >> ? ? ? ?ei_x_encode_tuple_header(&dynamic_buffer(state), 4); >> ? ? ? ?ei_x_encode_ulong(&dynamic_buffer(state), psg->Data1); >> ? ? ? ?ei_x_encode_ulong(&dynamic_buffer(state), psg->Data2); >> ? ? ? ?ei_x_encode_ulong(&dynamic_buffer(state), psg->Data3); >> ? ? ? ?ei_x_encode_tuple_header(&dynamic_buffer(state), 8); >> ? ? ? ?for(i=0; i<8; i++){ >> ? ? ? ? ? ?ei_x_encode_char(&dynamic_buffer(state), psg->Data4[i]); >> ? ? ? ?} >> >> For example, this conversion results in: >> ? ?19BCB12A-E6D1-4E58-A841-30F794C614FA => >> ? ? ? ?{{431796522,59089,20056,{168,65,48,247,148,198,20,250}} >> >> ? ?703F9C47-F1B9-407E-847D-34840AC1E346 => >> ? ? ? ?{1883216967,61881,16510,{132,125,52,132,10,193,227,70}} >> >> Somewhat odd to see how the C struct looks and how Microsoft "displays" a >> GUID. >> >> Should the Erlang representation be changed? Currently, I don't care >> about how it is displayed; of course it would be nice to see something >> more similar to the Microsoft way, on the other hand, it must't be >> converted back in the c-driver. Would be a bit-string better? Or just >> use a 128 Bit value? >> >> I really like to get some input on this. >> >> >> ?- boris >> >> >> 2011/12/9 Ingela Anderton Andin : >> >>> >>> Hi! >>> >>> It seems to be a missing feature. Support for the data_type SQL_GUID is >>> not >>> implemented. >>> I do not think it would be all that hard to implement but will not be >>> highly >>> prioritized by Ericsson. >>> Maybe somebody would like to make a user-contribution?! You should start >>> looking at the >>> funtion encode_data_type in odbcserver.c >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> Boris M?hmer wrote: >>> >>>> >>>> I try to connect to one of our companies Microsoft SQL databases using >>>> Erlang/OTP R14B04 running on an Ubuntu 10.04 64 Bit installation >>>> (using the FreeTDS drivers from the Ubuntu repositories). >>>> >>>> The problem I have is, that the Erlang ODBC module can't handle >>>> 'uniqueidentifier' (aka GUID) fields in tables. For example a 'select >>>> *' doesn't work, but when I only select the non-uniqueidentifier >>>> fields from the same table it works. >>>> >>>> On the other hand, when I use the "isql" (commandline-)tool with the >>>> same ODBC connection, I don't get any errors. >>>> >>>> So I would say that something within the Erlang ODBC module is broken >>>> (I believe it is in "odbcserver.c"). >>>> >>>> Is this a known bug, or did I miss anything? >>>> >>>> >>>> Regards, >>>> Boris >>>> _______________________________________________ >>>> 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 From norton@REDACTED Mon Dec 19 02:22:00 2011 From: norton@REDACTED (Joseph Norton) Date: Mon, 19 Dec 2011 10:22:00 +0900 Subject: [erlang-bugs] www.erlang.org On-line documentation title out of date Message-ID: <583D8C47-E682-47DC-A5F6-B81A361EDEAF@lovely.email.ne.jp> The title for On-line documentation is out of date. The link points to R15B documentation. http://www.erlang.org/doc.html On-line documentation Erlang/OTP R14B04 documentation Online www documentation for the run-time system as well as all the libraries. Searchable in the right column. Also available as an archive of HTML documents from the download page. Documentation for all releases is also available. Joseph Norton norton@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From hm@REDACTED Tue Dec 20 10:01:17 2011 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 20 Dec 2011 10:01:17 +0100 Subject: [erlang-bugs] internal error in v3_life Message-ID: # erlc foo.erl Function: split_cases/3 ./foo.erl:none: internal error in v3_life; crash reason: {{case_clause, {'EXIT', {{case_clause,{{k_internal,[],match_fail,1}}}, [{v3_life,call_op,1}, {v3_life,expr,3}, {v3_life,body,3}, {v3_life,body,3}, {v3_life,match,5}, {v3_life,val_clause,5}, {v3_life,'-type_clause/5-lc$^0/1-0-',5}, {v3_life,type_clause,5}]}}}, [{compile,'-select_passes/2-anonymous-2-',2}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} ./foo.erl:25: Warning: no clause will ever match /H?kan -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.erl Type: text/x-erlang Size: 2830 bytes Desc: not available URL: From ess@REDACTED Tue Dec 20 10:56:03 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 20 Dec 2011 10:56:03 +0100 Subject: [erlang-bugs] internal error in v3_life In-Reply-To: References: Message-ID: <4EF05BB3.1070603@trifork.com> A simplified version: -module(comperr). -compile([export_all]). split_cases(A) -> case A of x -> Z = dummy1; _ -> Z = dummy2, a=b end, case Z of _ -> ok end. This fails with erts-5.8.4. On 20-12-2011 10:01, H?kan Mattsson wrote: > -module(foo). > -compile([export_all]). > > split_cases(IsRecursive, [Case | Cases], Acc) -> > case binary:split(Case,<<":">>) of > [<<"qmt file", _/binary>> |_] -> > Qmt = Case, > case Cases of > [Case2 | Cases2] -> > Sections = binary:split(Case2,<<"\n">>, [global]); > [] -> > Sections = binary:split(Case,<<"\n">>, []), > Cases2 = [] > end; > [<<"test case", _/binary>> |_] -> > Qmt =<<>>, > Sections = binary:split(Case,<<"\n">>, [global]), > Cases2 = Cases; > [<<>>] -> > > io:format("DEBUG: ~p ~p\n", [Case, Cases]), > Qmt =<<>>, > Sections = [], > Cases2 = [], > a=b > end, > case Sections of > [Reason] -> > case binary:split(Qmt,<<":">>) of > [_, QmtFile] -> ok; > [] -> QmtFile = Qmt > end, > Res = {result_case, QmtFile,<<"ERROR">>, Reason}, > split_cases(IsRecursive, Cases2, [Res | Acc]); > [QmtCase, Reason] -> > [_, QmtFile] = binary:split(QmtCase,<<":">>), > Res = > case binary:split(Reason,<<":">>) of > [<<"result", _/binary>>, Reason2] -> > {result_case, QmtFile, Reason2, Reason}; > [<<"error", _/binary>>, Reason2] -> > {result_case, QmtFile,<<"ERROR">>, Reason2} > end, > split_cases(IsRecursive, Cases2, [Res | Acc]); > [QmtCase, ScriptCase, EventCase | DocAndResult] -> > [_, QmtFile] = binary:split(QmtCase,<<":">>), > [_, ScriptFile] = binary:split(ScriptCase,<<":">>), > [_, EventFile] = binary:split(EventCase,<<":">>), > EventLog = binary_to_list(EventFile), > case IsRecursive of > true -> > case annotate_log(EventLog) of > ok -> > ok; > {error, _, Reason} -> > io:format("ERROR in ~s\n\~p\n", [EventLog, Reason]) > end; > false -> > ignore > end, > {Doc, ResultCase} = split_doc(DocAndResult, []), > Result = parse_result(ResultCase), > HtmlLog = EventLog ++ ".html", > Res = {test_case, QmtFile, Qmt, ScriptFile, EventLog, Doc, > HtmlLog, Result}, > split_cases(IsRecursive, Cases2, [Res | Acc]) > end; > split_cases(_IsRecursive, [], Acc) -> > lists:reverse(Acc). > > annotate_log(_EventLog) -> > dummy. > > split_doc(_DocAndResult, _Acc) -> > {dummy, dummy}. > > parse_result(_ResultCase) -> > dummy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Tue Dec 20 11:00:32 2011 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 20 Dec 2011 11:00:32 +0100 Subject: [erlang-bugs] internal error in v3_life In-Reply-To: <4EF05BB3.1070603@trifork.com> References: <4EF05BB3.1070603@trifork.com> Message-ID: <4EF05CC0.8000306@trifork.com> And simpler still: split_cases(A) -> case A of x -> Z = dummy1; _ -> Z = dummy2, a=b end, Z. On 20-12-2011 10:56, Erik S?e S?rensen wrote: > A simplified version: > > -module(comperr). > -compile([export_all]). > > split_cases(A) -> > case A of > x -> Z = dummy1; > _ -> Z = dummy2, > a=b > end, > case Z of > _ -> ok > end. > > This fails with erts-5.8.4. > > On 20-12-2011 10:01, H?kan Mattsson wrote: >> -module(foo). >> -compile([export_all]). >> >> split_cases(IsRecursive, [Case | Cases], Acc) -> >> case binary:split(Case,<<":">>) of >> [<<"qmt file", _/binary>> |_] -> >> Qmt = Case, >> case Cases of >> [Case2 | Cases2] -> >> Sections = binary:split(Case2,<<"\n">>, [global]); >> [] -> >> Sections = binary:split(Case,<<"\n">>, []), >> Cases2 = [] >> end; >> [<<"test case", _/binary>> |_] -> >> Qmt =<<>>, >> Sections = binary:split(Case,<<"\n">>, [global]), >> Cases2 = Cases; >> [<<>>] -> >> >> io:format("DEBUG: ~p ~p\n", [Case, Cases]), >> Qmt =<<>>, >> Sections = [], >> Cases2 = [], >> a=b >> end, >> case Sections of >> [Reason] -> >> case binary:split(Qmt,<<":">>) of >> [_, QmtFile] -> ok; >> [] -> QmtFile = Qmt >> end, >> Res = {result_case, QmtFile,<<"ERROR">>, Reason}, >> split_cases(IsRecursive, Cases2, [Res | Acc]); >> [QmtCase, Reason] -> >> [_, QmtFile] = binary:split(QmtCase,<<":">>), >> Res = >> case binary:split(Reason,<<":">>) of >> [<<"result", _/binary>>, Reason2] -> >> {result_case, QmtFile, Reason2, Reason}; >> [<<"error", _/binary>>, Reason2] -> >> {result_case, QmtFile,<<"ERROR">>, Reason2} >> end, >> split_cases(IsRecursive, Cases2, [Res | Acc]); >> [QmtCase, ScriptCase, EventCase | DocAndResult] -> >> [_, QmtFile] = binary:split(QmtCase,<<":">>), >> [_, ScriptFile] = binary:split(ScriptCase,<<":">>), >> [_, EventFile] = binary:split(EventCase,<<":">>), >> EventLog = binary_to_list(EventFile), >> case IsRecursive of >> true -> >> case annotate_log(EventLog) of >> ok -> >> ok; >> {error, _, Reason} -> >> io:format("ERROR in ~s\n\~p\n", [EventLog, Reason]) >> end; >> false -> >> ignore >> end, >> {Doc, ResultCase} = split_doc(DocAndResult, []), >> Result = parse_result(ResultCase), >> HtmlLog = EventLog ++ ".html", >> Res = {test_case, QmtFile, Qmt, ScriptFile, EventLog, Doc, >> HtmlLog, Result}, >> split_cases(IsRecursive, Cases2, [Res | Acc]) >> end; >> split_cases(_IsRecursive, [], Acc) -> >> lists:reverse(Acc). >> >> annotate_log(_EventLog) -> >> dummy. >> >> split_doc(_DocAndResult, _Acc) -> >> {dummy, dummy}. >> >> parse_result(_ResultCase) -> >> dummy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Dec 20 11:54:48 2011 From: henrik@REDACTED (Henrik Nord) Date: Tue, 20 Dec 2011 11:54:48 +0100 Subject: [erlang-bugs] www.erlang.org On-line documentation title out of date In-Reply-To: <583D8C47-E682-47DC-A5F6-B81A361EDEAF@lovely.email.ne.jp> References: <583D8C47-E682-47DC-A5F6-B81A361EDEAF@lovely.email.ne.jp> Message-ID: <4EF06978.7020507@erlang.org> It was a cache issue, that is now resolved, and the documentation page received a small polish. Thank you! On 12/19/2011 02:22 AM, Joseph Norton wrote: > > The title for On-line documentation is out of date. The link points > to R15B documentation. > > http://www.erlang.org/doc.html > > On-line documentation > > *Erlang/OTP R14B04 documentation* > Online www documentation for the run-time system as well as all > the libraries. Searchable in the > right column. Also available as an archive of HTML documents from > the download page . > Documentation for all releases > is also available. > > > Joseph Norton > norton@REDACTED > > > > > > _______________________________________________ > 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 bgustavsson@REDACTED Tue Dec 20 13:52:17 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 20 Dec 2011 13:52:17 +0100 Subject: [erlang-bugs] internal error in v3_life In-Reply-To: <4EF05CC0.8000306@trifork.com> References: <4EF05BB3.1070603@trifork.com> <4EF05CC0.8000306@trifork.com> Message-ID: Thanks for the bug report and for the minimized test case. /Bjorn On 12/20/11, Erik S?e S?rensen wrote: > And simpler still: > > split_cases(A) -> > case A of > x -> Z = dummy1; > _ -> Z = dummy2, > a=b > end, > Z. > > > > On 20-12-2011 10:56, Erik S?e S?rensen wrote: >> A simplified version: >> >> -module(comperr). >> -compile([export_all]). >> >> split_cases(A) -> >> case A of >> x -> Z = dummy1; >> _ -> Z = dummy2, >> a=b >> end, >> case Z of >> _ -> ok >> end. >> >> This fails with erts-5.8.4. >> >> On 20-12-2011 10:01, H?kan Mattsson wrote: >>> -module(foo). >>> -compile([export_all]). >>> >>> split_cases(IsRecursive, [Case | Cases], Acc) -> >>> case binary:split(Case,<<":">>) of >>> [<<"qmt file", _/binary>> |_] -> >>> Qmt = Case, >>> case Cases of >>> [Case2 | Cases2] -> >>> Sections = binary:split(Case2,<<"\n">>, [global]); >>> [] -> >>> Sections = binary:split(Case,<<"\n">>, []), >>> Cases2 = [] >>> end; >>> [<<"test case", _/binary>> |_] -> >>> Qmt =<<>>, >>> Sections = binary:split(Case,<<"\n">>, [global]), >>> Cases2 = Cases; >>> [<<>>] -> >>> >>> io:format("DEBUG: ~p ~p\n", [Case, Cases]), >>> Qmt =<<>>, >>> Sections = [], >>> Cases2 = [], >>> a=b >>> end, >>> case Sections of >>> [Reason] -> >>> case binary:split(Qmt,<<":">>) of >>> [_, QmtFile] -> ok; >>> [] -> QmtFile = Qmt >>> end, >>> Res = {result_case, QmtFile,<<"ERROR">>, Reason}, >>> split_cases(IsRecursive, Cases2, [Res | Acc]); >>> [QmtCase, Reason] -> >>> [_, QmtFile] = binary:split(QmtCase,<<":">>), >>> Res = >>> case binary:split(Reason,<<":">>) of >>> [<<"result", _/binary>>, Reason2] -> >>> {result_case, QmtFile, Reason2, Reason}; >>> [<<"error", _/binary>>, Reason2] -> >>> {result_case, QmtFile,<<"ERROR">>, Reason2} >>> end, >>> split_cases(IsRecursive, Cases2, [Res | Acc]); >>> [QmtCase, ScriptCase, EventCase | DocAndResult] -> >>> [_, QmtFile] = binary:split(QmtCase,<<":">>), >>> [_, ScriptFile] = binary:split(ScriptCase,<<":">>), >>> [_, EventFile] = binary:split(EventCase,<<":">>), >>> EventLog = binary_to_list(EventFile), >>> case IsRecursive of >>> true -> >>> case annotate_log(EventLog) of >>> ok -> >>> ok; >>> {error, _, Reason} -> >>> io:format("ERROR in ~s\n\~p\n", [EventLog, >>> Reason]) >>> end; >>> false -> >>> ignore >>> end, >>> {Doc, ResultCase} = split_doc(DocAndResult, []), >>> Result = parse_result(ResultCase), >>> HtmlLog = EventLog ++ ".html", >>> Res = {test_case, QmtFile, Qmt, ScriptFile, EventLog, Doc, >>> HtmlLog, Result}, >>> split_cases(IsRecursive, Cases2, [Res | Acc]) >>> end; >>> split_cases(_IsRecursive, [], Acc) -> >>> lists:reverse(Acc). >>> >>> annotate_log(_EventLog) -> >>> dummy. >>> >>> split_doc(_DocAndResult, _Acc) -> >>> {dummy, dummy}. >>> >>> parse_result(_ResultCase) -> >>> dummy. >> > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From erlangsiri@REDACTED Wed Dec 21 14:59:20 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 21 Dec 2011 14:59:20 +0100 Subject: [erlang-bugs] Check sys.config in release_handler In-Reply-To: References: Message-ID: Hi Andrew - this is just to inform you that an improvement of this behavior has been implemented for the coming R15B01 release. systools now checks that sys.config is readable and consists of erlang terms. Regards /siri 2011/9/14 Siri Hansen > Hi Andrew - Thanks for reporting this. I'll look into it. > Regards > /siri > > 2011/9/14 Andrew Gopienko > >> If sys.config in release-upgrade-tarball contains non term data you won't >> see any errors when will do release upgrade >> (release_handler:unpack_release, release_handler:install_release, >> release_handler:make_permanent). >> But sys.config successfully be copied in releases/VSN and at next restart >> the node won't be launched. >> You will get something like that >> >> Crash dump was written to: erl_crash.dump >> could not start kernel pid (application_controller) (error in config file >> "/.../releases/VSN/sys.config" (1): bad term) >> >> >> Andrew Gopienko >> Threeline LLC >> >> >> _______________________________________________ >> 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 Tue Dec 27 23:30:48 2011 From: baryluk@REDACTED (Witold Baryluk) Date: Tue, 27 Dec 2011 23:30:48 +0100 Subject: [erlang-bugs] IEEE-754 subnormals parsing and handling problems and bugs Message-ID: <20111227223048.GE11045@smp.if.uj.edu.pl> Hello, I found problem when parsing small numbers 1> list_to_float("0."++lists:duplicate(322, $0)++"1"). 1.0e-323 2> list_to_float("0."++lists:duplicate(323, $0)++"1"). 0.0 This is contrasting difference to the handling of big numbers 3> list_to_float("1"++lists:duplicate(308, $0)++".0"). 1.0e308 4> list_to_float("1"++lists:duplicate(309, $0)++".0"). ** exception error: bad argument in function list_to_float/1 called as list_to_float("1000000...[lots of zeros removed]......000000000.0") Example 2, shourly should throw error. But actually example 1 also, becaus it create so called subnormal numbers (aka denormal numbers, underflow value). Take look at this two examples: 5> list_to_float("0."++lists:duplicate(322, $0)++"123456789"). 1.0e-323 6> list_to_float("0."++lists:duplicate(300, $0)++"123456789"). 1.23456789e-301 One can check how arithmetic exception handling is working here: 7> 1.0e200 * 1.0e200. ** exception error: bad argument in an arithmetic expression in operator */2 called as 1.0e200 * 1.0e200 but this doesn't happen for small numbers 8> 0.123456789e-300. 1.23456789e-301 9> 0.123456789e-400. 0.0 10> 0.123456789e-320. 1.235e-321 11> 0.123456789e-100 * 0.123456789e-100. 1.524157875019052e-202 12> 0.123456789e-200 * 0.123456789e-200. 0.0 Why infinities are trapped, but subnormals not? Because there is no good syntax for NaNs and Infinites, but there is for subnormals and zero? As of speed in fact subnormal processing is much more slower, than infinities. This means, that for example adding lots of numbers near 1.0e-320 can be few times slower, than normal numbers. Other oprations, like square root, trigonometry or multiplications can have even bigger performance impact. 13> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-200)]). {164756,1.0000000000056682e-195} 14> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-300)]). {163616,9.99999999972789e-296} 15> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-310)]). {238753,1.0000000000158536e-305} 16> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-320)]). {471354,9.98012605e-316} 17> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-321)]). {471283,9.881313e-317} 18> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-322)]). {471398,9.881313e-318} 19> timer:tc(lists, sum, [lists:duplicate(1000000, 0.1e-323)]). {164053,0.0} % on my machine (Athlon_. I tested on Intel Core2 in 32-bits, and % differences are much bigger, up to 20 times slower! Similar behaviour I found in erl_scan:string/1. This is also very different behaviour than erl_scan:string/1, used by compiler to parse shell input and source files. 20> erl_scan:string("1"++lists:duplicate(309, $0)++".0"). {error,{1,erl_scan,{illegal,float}},1} 21> erl_scan:string("1"++lists:duplicate(308, $0)++".0"). {ok,[{float,1,1.0e308}],1} Everything fine, infinities are trapped. Unfortunetly, for underflows compiler similary behaves wrong 22> erl_scan:string("0."++lists:duplicate(322, $0)++"1"). {ok,[{float,1,1.0e-323}],1} % should return error 23> erl_scan:string("0."++lists:duplicate(323, $0)++"1"). {ok,[{float,1,0.0}],1} % should return error Also string:to_float behaves in same way: 24> string:to_float("0."++lists:duplicate(322, $0)++"1"). {1.0e-323,[]} % should return error 25> string:to_float("0."++lists:duplicate(323, $0)++"1"). {0.0,[]} % should return error 26> string:to_float("1"++lists:duplicate(308, $0)++".0"). {1.0e308,[]} 27> string:to_float("1"++lists:duplicate(309, $0)++".0"). {error,no_float} I think it should be fixed, so more reliable software can be written, like statistics software (subnormals can for example easilly appear when summing and multipling small numbers, however it is normally rear, and should throw error, to not produce bad results, because even using smart summation algorithms, like Kahan scheme, will not fix this problem). For sure such floats should not be allowed in source code, or when parsing from string. And probably also not be allowed to appear using any builting arithmetic functions. Another example: 30> math:exp(100). 2.6881171418161356e43 31> math:exp(1000). ** exception error: bad argument in an arithmetic expression in function math:exp/1 called as math:exp(1000) infinity trapped, but subnormal not: 32> math:exp(-100). 3.720075976020836e-44 33> math:exp(-1000). 0.0 I also found that scientific notation behaves in same way: 34> list_to_float("1.123456789e-320"). 1.1235e-320 35> list_to_float("1.123456789e-330"). 0.0 My last argument will be about hardware support. For example many new ARM processors, supports hardware floating point computations, but often without support for subnormals! This makes them not fully IEEE-754 compilant, unless running in software floating point mode, which is slower, especially if it also need to handle subnormals! I'm using 32-bit cpu: model name : AMD Athlon(tm) stepping : 2 cpu MHz : 1154.450 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up Erlang version 1:14.b.4-dfsg-1 installed from Debian/GNU Linux testing. Do not know exact complation flags, but here is small info 1> erlang:system_info(system_version). "Erlang R14B04 (erts-5.8.5) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false]\n" 2> erlang:system_info(system_architecture). "i486-pc-linux-gnu" 3> erlang:system_info(build_type). opt 4> erlang:system_info(c_compiler_used). {gnuc,{4,6,1}} 5> erlang:system_info(debug_compiled). false 6> erlang:system_info(smp_support). false 7> erlang:system_info(threads). true speed differences of subnormals on Intel Core2 (32-bit mode), same compiler, same options. 1> timer:tc(lists, sum, [lists:duplicate(10000000, 0.1e-300)]). {278703,9.999999998591641e-295} 3> timer:tc(lists, sum, [lists:duplicate(10000000, 0.1e-310)]). {1049095,9.999999997470606e-305} 5> timer:tc(lists, sum, [lists:duplicate(10000000, 0.1e-320)]). {3501330,9.980126046e-315} % about 12 times slower, and obviously loss of precission. Beyond infinities, nan, and denormalized numbers, there also signed zero, but this is handled without problem: 10> list_to_float("0.0") =:= list_to_float("-0.0"). true 11> math:sqrt(list_to_float("-0.0")). 0.0 This is acceptable, because signed zero is mostly usefull with NaN and infinites support, and because we do not have them, it is good solution to ignore signed zero problem. I found no discussion on erlang-questions list in the past, so hope it is worth discussing. Also Erlang Reference Manual User's Guide, doesn't mention anything on the matter. Regards, Witek -- Witold Baryluk From eric.pailleau@REDACTED Wed Dec 28 23:01:33 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 28 Dec 2011 23:01:33 +0100 Subject: [erlang-bugs] R15B observer crash while clicking on 'Table information' Message-ID: <4EFB91BD.2050500@wanadoo.fr> Hello, I was playing with the new observer application on R15B . Tab 'Table Viewer', then Menu->View->Mnesia Tables By clicking on a particular table that is perfectly working , I got a crash like below : ---------8<------------------------------------------------------ Erlang R15B (erts-5.9) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Child crashed exiting: <0.141.0> {function_clause, [{observer_tv_wx,list_to_strings, [5], [{file,"observer_tv_wx.erl"},{line,314}]}, {observer_tv_wx,list_to_strings,1, [{file,"observer_tv_wx.erl"},{line,317}]}, {observer_tv_wx,display_table_info,4, [{file,"observer_tv_wx.erl"},{line,295}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"}, {line,369}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]} 5> =ERROR REPORT==== 28-Dec-2011::22:40:37 === ** wx object server <0.144.0> terminating ** Last message in was {wx,400, {wx_ref,267,wxFrame,[]}, [], {wxCommand,command_menu_selected,[],0,0}} ** When Server state == {state, {wx_ref,218,wxListCtrl,[]}, {wx_ref,267,wxFrame,[]}, {wx_ref,293,wxListCtrl,[]}, {wx_ref,284,wxStatusBar,[]}, {wx_ref,292,wxBoxSizer,[]}, {search,true, {wx_ref,294,wxBoxSizer,[]}, 'Search Area', {wx_ref,297,wxTextCtrl,[]}, {wx_ref,308,wxTextCtrl,[]}, {{wx_ref,299,wxRadioButton,[]}, {wx_ref,301,wxRadioButton,[]}, {wx_ref,303,wxCheckBox,[]}}, undefined}, undefined,nonode@REDACTED,10,<0.145.0>,mnesia, {tab,my_test_table,ignore,9,4208,<0.67.0>, mnesia_monitor,public,set,2,none,false,false, disc_copies, [4,5]}, {attrs, {wx_ref,286,wxListItemAttr,[]}, {wx_ref,287,wxListItemAttr,[]}, {wx_ref,288,wxListItemAttr,[]}, {wx_ref,289,wxListItemAttr,[]}, {wx_ref,290,wxListItemAttr,[]}}, undefined} ** Reason for termination == ** {function_clause, [{observer_tv_wx,list_to_strings, [5], [{file,"observer_tv_wx.erl"},{line,314}]}, {observer_tv_wx,list_to_strings,1, [{file,"observer_tv_wx.erl"},{line,317}]}, {observer_tv_wx,display_table_info,4, [{file,"observer_tv_wx.erl"},{line,295}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"},{line,369}]}, {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} ---------8<----------------------------------------------------- The table is containing a column with strings that are displayed as lists instead of readable string (like tv), that is not very useful to see the table content... Moreover the error is likely a 'list_to_strings' one but other tables are containing columns with strings without this behaviour... the lonely difference with other tables is a column with a binary string made of an erlang:md5 hash and two other columns with records into it. Best regards. From eric.pailleau@REDACTED Wed Dec 28 23:24:43 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 28 Dec 2011 23:24:43 +0100 Subject: [erlang-bugs] R15B observer crash while refreshing the state of a stopped application In-Reply-To: <4EFB91BD.2050500@wanadoo.fr> References: <4EFB91BD.2050500@wanadoo.fr> Message-ID: <4EFB972B.3010805@wanadoo.fr> Hello, I got another crash when refreshing the process' state of an application that is temporary stopped. I think a test that the current application is still alive should be performed before trying to refresh a vanished application. ----------------8<---------------------------------------------- Child crashed exiting: <0.11300.0> {function_clause, [{proplists,get_value, [initial_call,undefined,undefined], [{file,"proplists.erl"},{line,222}]}, {observer_lib,fill_info,2, [{file,"observer_lib.erl"},{line,122}]}, {observer_lib,fill_info,2, [{file,"observer_lib.erl"},{line,127}]}, {observer_procinfo, '-init_process_page/2-fun-0-',2, [{file,"observer_procinfo.erl"}, {line,129}]}, {observer_procinfo, '-handle_event/2-lc$^0/1-0-',1, [{file,"observer_procinfo.erl"}, {line,98}]}, {observer_procinfo,handle_event,2, [{file,"observer_procinfo.erl"}, {line,98}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]} ----------------8<---------------------------------------------- best regards. From magnus.klaar@REDACTED Thu Dec 29 17:26:45 2011 From: magnus.klaar@REDACTED (Magnus Klaar) Date: Thu, 29 Dec 2011 17:26:45 +0100 Subject: [erlang-bugs] Errors when using file:sendfile/2 Message-ID: Hi! I'm encountered the following errors while testing a module using file:sendfile/2. It appears to be quite rare. 17 errors were logged for 11000 requests sent to the server. This is using "Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]" running on "Linux $(hostname) 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux". =ERROR REPORT==== 29-Dec-2011::16:55:15 === driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) by tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before stop_select was called for driver efile =ERROR REPORT==== 29-Dec-2011::16:55:20 === driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) by tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before stop_select was called for driver efile The code is not merged into the main project yet and test is rather ad-hoc, I'm defaulting to not providing it unless you specifically ask for it. Let me know if you need and I'll write a summary for downloading and running it if the error messages are not informative enough. MVH Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu Dec 29 19:36:15 2011 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 29 Dec 2011 19:36:15 +0100 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: References: Message-ID: On Thu, Dec 29, 2011 at 5:26 PM, Magnus Klaar wrote: > Hi! > > I'm encountered the following errors while testing a module using > file:sendfile/2. It appears to be quite rare. 17 errors were logged > for 11000 requests sent to the server. This is using "Erlang R15B > (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] > [kernel-poll:false]" running on "Linux $(hostname) 3.0.0-1-amd64 #1 > SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux". > > =ERROR REPORT==== 29-Dec-2011::16:55:15 === > driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) > by tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before > stop_select was called for driver efile > > > =ERROR REPORT==== 29-Dec-2011::16:55:20 === > driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) > by tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before > stop_select was called for driver efile > > > The code is not merged into the main project yet and test is rather > ad-hoc, I'm defaulting to not providing it unless you specifically > ask for it. Let me know if you need and I'll write a summary for > downloading and running it if the error messages are not informative > enough. Can you try with +A2? From magnus.klaar@REDACTED Thu Dec 29 20:04:41 2011 From: magnus.klaar@REDACTED (Magnus Klaar) Date: Thu, 29 Dec 2011 20:04:41 +0100 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: References: Message-ID: On Thu, Dec 29, 2011 at 7:36 PM, Tuncer Ayaz wrote: > > Can you try with +A2? > Hi! The errors don't occur when the erlang node is started with +A 2 or +A 16. I did a few more long running test using 500k requests to verify that it didn't just reduce the frequency of the errors just enough to make my previous test look ok. MVH Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.melin@REDACTED Thu Dec 29 23:10:50 2011 From: per.melin@REDACTED (Per Melin) Date: Thu, 29 Dec 2011 23:10:50 +0100 Subject: [erlang-bugs] Inets(5.5.1) http client keep alive mode doesn't follow RFC2616 In-Reply-To: <6C827D0F-815B-4070-A5CE-280F1406ABF4@lightpole.net> References: <6C827D0F-815B-4070-A5CE-280F1406ABF4@lightpole.net> Message-ID: On Nov 16, 2011, at 10:31 , caox wrote: > Have this bug been fixed in the latest version? I did a test with R15B and it looks like it hasn't been fixed. I reported this already back in May 2009 for R13B. At that time this bug would make the http client crash when connecting to a server that didn't support pipelining. Now it seems to instead retry the failed connections after about a minute. >> ???: 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 >>>> >>> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Dec 30 16:38:52 2011 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 30 Dec 2011 16:38:52 +0100 Subject: [erlang-bugs] edoc mangles parameterized function specs Message-ID: <0B487779-F11F-4A13-BFD0-8FB16E05A043@feuerlabs.com> I was made aware that EDoc doesn't present parameterized types, so I started looking into that. I first thought that it generalizes the types, but it actually truncates them! This will invariably result in a wrong type being documented. For example: -module(t). -export([f/1]). -spec f(a) -> 1; (b) -> 2. f(a) -> 1; f(b) -> 2. If I document this with R15B Edoc, the rendered type signature will be: f(X1::a) -> 1 ?which is simply wrong. I have traced it down to edoc_extract.erl selected_specs([], Ts) -> Ts; selected_specs([F], [_ | Ts]) -> [edoc_specs:spec(F, _Clause=1) | Ts]. Only the first clause is extracted. Is that deliberate? BR, Ulf W