From anders.nygren@REDACTED Sun May 4 21:02:15 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Sun, 4 May 2008 14:02:15 -0500 Subject: [erlang-bugs] odbc:param_query Message-ID: I am having a problem with parameterized queries Erlang R12B-2 on Linux (SuSE 10.3) MySQL 5.0.45 myodbc 3.51 unixODBC 2.2.12 Reply = odbc:param_query(State#state.cref, "insert into Users (userId, password, " "userType, name) values (?,?,?,?)", [{{sql_varchar,20},[UserId]}, {{sql_varchar,20},[Passwd]}, {{sql_char,6},[Type]}, {{sql_varchar,100},[Name]}]), Sometimes I get {updated, 1}, but most of the time I get the following error {error,"No SQL-driver information available."} but the data has been inserted. The table is created with CREATE TABLE IF NOT EXISTS `npas`.`Users` ( `userId` VARCHAR(20) NOT NULL , `password` VARCHAR(20) NOT NULL , `userType` ENUM('admin','normal','read') NOT NULL , `name` VARCHAR(100) NOT NULL , PRIMARY KEY (`userId`) ) ENGINE = InnoDB PACK_KEYS = 0 ROW_FORMAT = DEFAULT; From ingela@REDACTED Mon May 5 10:57:41 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 05 May 2008 10:57:41 +0200 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] Message-ID: <481ECC05.6000903@erix.ericsson.se> -------------- next part -------------- An embedded message was scrubbed... From: Ingela Anderton Andin Subject: Re: [erlang-bugs] odbc:param_query Date: Mon, 05 May 2008 10:56:40 +0200 Size: 2352 URL: From anders.nygren@REDACTED Mon May 5 15:01:36 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Mon, 5 May 2008 08:01:36 -0500 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] In-Reply-To: <481ECC05.6000903@erix.ericsson.se> References: <481ECC05.6000903@erix.ericsson.se> Message-ID: 2008/5/5 Ingela Anderton Andin : > > > Hi! > > As a part of bigger patch (for 64 bit-odbc) I got the following change to > param-queries in odbcserver.c. This might help your case, it would > be great if you could try that out for me. I am not very found of the ODBC > API (or the implementations of it anyway) it does surprising things > at times. > Hi Ingela After a quick test, it looks like it is working fine with the patch. Thanks a lot. /Anders > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte *buffer, > db_state *state) > switch (param_status.param_status_array[i]) { > case SQL_PARAM_SUCCESS: > case SQL_PARAM_SUCCESS_WITH_INFO: > + case SQL_PARAM_DIAG_UNAVAILABLE: > break; > default: > diagnos = > > > Regards Ingela - OTP team > > Anders Nygren wrote: > > > I am having a problem with parameterized queries > > Erlang R12B-2 on Linux (SuSE 10.3) > > MySQL 5.0.45 > > myodbc 3.51 > > unixODBC 2.2.12 > > > > > > Reply = odbc:param_query(State#state.cref, > > "insert into Users (userId, password, " > > "userType, name) values (?,?,?,?)", > > [{{sql_varchar,20},[UserId]}, > > {{sql_varchar,20},[Passwd]}, > > {{sql_char,6},[Type]}, > > {{sql_varchar,100},[Name]}]), > > > > > > Sometimes I get {updated, 1}, but most of the time I get the following > error > > {error,"No SQL-driver information available."} but the data has been > inserted. > > > > The table is created with > > CREATE TABLE IF NOT EXISTS `npas`.`Users` ( > > `userId` VARCHAR(20) NOT NULL , > > `password` VARCHAR(20) NOT NULL , > > `userType` ENUM('admin','normal','read') NOT NULL , > > `name` VARCHAR(100) NOT NULL , > > PRIMARY KEY (`userId`) ) > > ENGINE = InnoDB > > PACK_KEYS = 0 > > ROW_FORMAT = DEFAULT; > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From sverker@REDACTED Mon May 5 16:31:53 2008 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 05 May 2008 16:31:53 +0200 Subject: [erlang-bugs] Patch to build with --as-needed in LDFLAGS In-Reply-To: <20080429020735.111355e8@gentoo.org> References: <20080429020735.111355e8@gentoo.org> Message-ID: <481F1A59.6030805@erix.ericsson.se> Christian Faulhammer wrote: > Hi, > > as I wrote some weeks ago, Erlang is badly broken if a system is built > with --as-neede in LDFLAGS. Attached patch corrects this. > --- erts/configure.in.orig 2008-04-24 23:16:09.000000000 +0400 > +++ erts/configure.in 2008-04-24 23:17:05.000000000 +0400 > @@ -2874,8 +2874,10 @@ > else > saveCFLAGS="$CFLAGS" > saveLDFLAGS="$LDFLAGS" > + saveLIBS="$LIBS" > CFLAGS="$CFLAGS $SSL_INCLUDE" > - LDFLAGS="$LDFLAGS -L$SSL_LIBDIR -lcrypto" > + LDFLAGS="$LDFLAGS -L$SSL_LIBDIR" > + LIBS="-lcrypto" > AC_TRY_LINK([ > #include > #include ], > @@ -2887,6 +2889,7 @@ > [ssl_linkable=no]) > CFLAGS="$saveCFLAGS" > LDFLAGS="$saveLDFLAGS" > + LIBS="$saveLIBS" > fi > fi I've incorporated this patch. Planned to be released in R12B-3. Seems like the right way to do it anyway, regardless of --as-needed or any other linker flags. /Sverker, Erlang/OTP, Ericsson From rvirding@REDACTED Tue May 6 00:00:16 2008 From: rvirding@REDACTED (Robert Virding) Date: Tue, 6 May 2008 00:00:16 +0200 Subject: [erlang-bugs] string:to_float/1 and string:to_integer/1 Message-ID: <3dbc6d1c0805051500g54101631i5ade7f4d153e8b89@mail.gmail.com> The two functions, to_float/1 and to_integer/1, in string are seriously broken as they don't raise an error on wrong type of input data but return an error value. This is inconsistent with the rest of the string module and most other module in the standard libraries. The norm is that bad input data is considered an error. I know it is documented but that just makes it a documented bug. They should be either changed or removed. Or the rest of string changed to be consistent. I personally think that these functions anyway should not be in string, io or io_lib is a better place for them. Should there be a string:to_atom which parses its input string and returns the atom which may be at the beginning of the string. Sorry for being sarcastic they *are* very weird functions. I would also debate the error return if there is no integer or float, the user should know what they are doing. Also returning an {error,E} tuple and not an {ok,I,Rest} tuple is completely inconsistent, both should be tagged. As it now you cannot just matched against the success case: {Int,Rest} = string:to_integer(String) but must use a case as both tuples are the same size and only one is tagged. This also breaks a common idiom. In all these functions cannot be considered as anything other than mis formed bugs. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Tue May 6 06:58:29 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 06 May 2008 06:58:29 +0200 Subject: [erlang-bugs] string:to_float/1 and string:to_integer/1 In-Reply-To: <3dbc6d1c0805051500g54101631i5ade7f4d153e8b89@mail.gmail.com> References: <3dbc6d1c0805051500g54101631i5ade7f4d153e8b89@mail.gmail.com> Message-ID: <1210049909.14607.77.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, Since it would be backwards incompatible to just change the existing functions I would like to suggest deprecating them and instead encourage the use of io_lib:fread/2 (or erlang:list_to_integer/1 and erlang:list_to_float/1). bengt On Tue, 2008-05-06 at 00:00 +0200, Robert Virding wrote: > The two functions, to_float/1 and to_integer/1, in string are > seriously broken as they don't raise an error on wrong type of input > data but return an error value. This is inconsistent with the rest of > the string module and most other module in the standard libraries. The > norm is that bad input data is considered an error. I know it is > documented but that just makes it a documented bug. They should be > either changed or removed. Or the rest of string changed to be > consistent. > > I personally think that these functions anyway should not be in > string, io or io_lib is a better place for them. Should there be a > string:to_atom which parses its input string and returns the atom > which may be at the beginning of the string. Sorry for being sarcastic > they *are* very weird functions. > > I would also debate the error return if there is no integer or float, > the user should know what they are doing. Also returning an {error,E} > tuple and not an {ok,I,Rest} tuple is completely inconsistent, both > should be tagged. As it now you cannot just matched against the > success case: > > {Int,Rest} = string:to_integer(String) > > but must use a case as both tuples are the same size and only one is > tagged. This also breaks a common idiom. > > In all these functions cannot be considered as anything other than mis > formed bugs. > > Robert > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From anders.nygren@REDACTED Tue May 6 18:29:25 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 6 May 2008 11:29:25 -0500 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] In-Reply-To: References: <481ECC05.6000903@erix.ericsson.se> Message-ID: On Mon, May 5, 2008 at 8:01 AM, Anders Nygren wrote: > 2008/5/5 Ingela Anderton Andin : > > > > > > > Hi! > > > > As a part of bigger patch (for 64 bit-odbc) I got the following change to > > param-queries in odbcserver.c. This might help your case, it would > > be great if you could try that out for me. I am not very found of the ODBC > > API (or the implementations of it anyway) it does surprising things > > at times. > > > > Hi Ingela > After a quick test, it looks like it is working fine with the patch. > Thanks a lot. > > /Anders After some more testing I have seen that the problem remains. /Anders > > > > > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte *buffer, > > db_state *state) > > switch (param_status.param_status_array[i]) { > > case SQL_PARAM_SUCCESS: > > case SQL_PARAM_SUCCESS_WITH_INFO: > > + case SQL_PARAM_DIAG_UNAVAILABLE: > > break; > > default: > > diagnos = > > > > > > Regards Ingela - OTP team > > > > Anders Nygren wrote: > > > > > I am having a problem with parameterized queries > > > Erlang R12B-2 on Linux (SuSE 10.3) > > > MySQL 5.0.45 > > > myodbc 3.51 > > > unixODBC 2.2.12 > > > > > > > > > Reply = odbc:param_query(State#state.cref, > > > "insert into Users (userId, password, " > > > "userType, name) values (?,?,?,?)", > > > [{{sql_varchar,20},[UserId]}, > > > {{sql_varchar,20},[Passwd]}, > > > {{sql_char,6},[Type]}, > > > {{sql_varchar,100},[Name]}]), > > > > > > > > > Sometimes I get {updated, 1}, but most of the time I get the following > > error > > > {error,"No SQL-driver information available."} but the data has been > > inserted. > > > > > > The table is created with > > > CREATE TABLE IF NOT EXISTS `npas`.`Users` ( > > > `userId` VARCHAR(20) NOT NULL , > > > `password` VARCHAR(20) NOT NULL , > > > `userType` ENUM('admin','normal','read') NOT NULL , > > > `name` VARCHAR(100) NOT NULL , > > > PRIMARY KEY (`userId`) ) > > > ENGINE = InnoDB > > > PACK_KEYS = 0 > > > ROW_FORMAT = DEFAULT; > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > > > > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > From ingela@REDACTED Wed May 7 09:34:09 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 07 May 2008 09:34:09 +0200 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] In-Reply-To: References: <481ECC05.6000903@erix.ericsson.se> Message-ID: <48215B71.4020802@erix.ericsson.se> Anders Nygren wrote: > On Mon, May 5, 2008 at 8:01 AM, Anders Nygren wrote: > >> 2008/5/5 Ingela Anderton Andin : >> >> >> > >> > Hi! >> > >> > As a part of bigger patch (for 64 bit-odbc) I got the following change to >> > param-queries in odbcserver.c. This might help your case, it would >> > be great if you could try that out for me. I am not very found of the ODBC >> > API (or the implementations of it anyway) it does surprising things >> > at times. >> > >> >> Hi Ingela >> After a quick test, it looks like it is working fine with the patch. >> Thanks a lot. >> >> /Anders >> > > After some more testing I have seen that the problem remains. > > Humm... could you be a little more specific? I guess that the problem still occurs but not as often?! (As you seemed to think that it helped at first.) Maybe there are more special cases that occur with the use of some drivers but not others. Alas we can not test with all existing drivers and all existing backends. We test with the databases SQLServer on windows systems and Postgress on unix systems. When I get time I will try to test with the table you supplied below in our environment. But if the problem is driver specific it might work just fine. (Our existing test on param-queries does.) Just a few questions, does it fail in a predictably way? Always the n:th time you try or after you did something elese or does it seem to be random? It would be good to have a minimal test case to provoke the error. Setting up a mysql-environment will however not be a top priority for us. In the meantime if you should stumble on some solution yourself we will of course accept patches a as long as they do not break anything else and seem reasonable. Regards Ingela, Erlang/OTP Ericsson >> >> > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte *buffer, >> > db_state *state) >> > switch (param_status.param_status_array[i]) { >> > case SQL_PARAM_SUCCESS: >> > case SQL_PARAM_SUCCESS_WITH_INFO: >> > + case SQL_PARAM_DIAG_UNAVAILABLE: >> > break; >> > default: >> > diagnos = >> > >> > >> > Regards Ingela - OTP team >> > >> > Anders Nygren wrote: >> > >> > > I am having a problem with parameterized queries >> > > Erlang R12B-2 on Linux (SuSE 10.3) >> > > MySQL 5.0.45 >> > > myodbc 3.51 >> > > unixODBC 2.2.12 >> > > >> > > >> > > Reply = odbc:param_query(State#state.cref, >> > > "insert into Users (userId, password, " >> > > "userType, name) values (?,?,?,?)", >> > > [{{sql_varchar,20},[UserId]}, >> > > {{sql_varchar,20},[Passwd]}, >> > > {{sql_char,6},[Type]}, >> > > {{sql_varchar,100},[Name]}]), >> > > >> > > >> > > Sometimes I get {updated, 1}, but most of the time I get the following >> > error >> > > {error,"No SQL-driver information available."} but the data has been >> > inserted. >> > > >> > > The table is created with >> > > CREATE TABLE IF NOT EXISTS `npas`.`Users` ( >> > > `userId` VARCHAR(20) NOT NULL , >> > > `password` VARCHAR(20) NOT NULL , >> > > `userType` ENUM('admin','normal','read') NOT NULL , >> > > `name` VARCHAR(100) NOT NULL , >> > > PRIMARY KEY (`userId`) ) >> > > ENGINE = InnoDB >> > > PACK_KEYS = 0 >> > > ROW_FORMAT = DEFAULT; >> > > _______________________________________________ >> > > erlang-bugs mailing list >> > > erlang-bugs@REDACTED >> > > http://www.erlang.org/mailman/listinfo/erlang-bugs >> > > >> > > >> > > >> > >> > >> > >> > _______________________________________________ >> > erlang-bugs mailing list >> > erlang-bugs@REDACTED >> > http://www.erlang.org/mailman/listinfo/erlang-bugs >> > >> >> > > From anders.nygren@REDACTED Wed May 7 18:07:51 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 7 May 2008 11:07:51 -0500 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] In-Reply-To: <48215B71.4020802@erix.ericsson.se> References: <481ECC05.6000903@erix.ericsson.se> <48215B71.4020802@erix.ericsson.se> Message-ID: On Wed, May 7, 2008 at 2:34 AM, Ingela Anderton Andin wrote: > Anders Nygren wrote: > > > On Mon, May 5, 2008 at 8:01 AM, Anders Nygren > wrote: > > > > > > > 2008/5/5 Ingela Anderton Andin : > > > > > > > > > > > Hi! > > > > > > > > As a part of bigger patch (for 64 bit-odbc) I got the following > change to > > > > param-queries in odbcserver.c. This might help your case, it would > > > > be great if you could try that out for me. I am not very found of > the ODBC > > > > API (or the implementations of it anyway) it does surprising things > > > > at times. > > > > > > > > > > Hi Ingela > > > After a quick test, it looks like it is working fine with the patch. > > > Thanks a lot. > > > > > > /Anders > > > > > > > > > > After some more testing I have seen that the problem remains. > > > > > > > > Humm... could you be a little more specific? I guess that the problem > still occurs but > not as often?! (As you seemed to think that it helped at first.) At first it failed most of the time, maybe 75%, but apparently randomly. After the patch I tested doing maybe 10 insert of one row each and all were successful. That was when I reported that the patch seemed to work. But later when I was testing another param_query it failed again. And also the original query started to fail again. I had originally said that even when I got the error the data was inserted. But that was not completely correct. If I try to insert one row it gets inserted. But if I try to INSERT several rows with one param_query and it gives the error only the first row is inserted. Unfortunately I do not have time right now to look into this in more detail, so I have just switched to using sql_query instead. Maybe I will be able to do some more tests in the beginning of June. /Anders > Maybe there are more special > cases that occur with the use of some drivers but not others. Alas we can > not test with all existing > drivers and all existing backends. We test with the databases > SQLServer on windows systems and Postgress on unix systems. When I get > time I will try to test with the table you supplied below in our > environment. But if the problem > is driver specific it might work just fine. (Our existing test on > param-queries does.) > Just a few questions, does it fail in a predictably way? Always the n:th > time you try or after you did something > elese or does it seem to be random? It would be good to have a minimal test > case to provoke the error. > Setting up a mysql-environment will however not be a top priority for us. > In the meantime if you should stumble on some solution yourself we will > of course accept patches a as long as they do not > break anything else and seem reasonable. > > Regards Ingela, Erlang/OTP Ericsson > > > > > > > > > > > > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte > *buffer, > > > > db_state *state) > > > > switch (param_status.param_status_array[i]) { > > > > case SQL_PARAM_SUCCESS: > > > > case SQL_PARAM_SUCCESS_WITH_INFO: > > > > + case SQL_PARAM_DIAG_UNAVAILABLE: > > > > break; > > > > default: > > > > diagnos = > > > > > > > > > > > > Regards Ingela - OTP team > > > > > > > > Anders Nygren wrote: > > > > > > > > > I am having a problem with parameterized queries > > > > > Erlang R12B-2 on Linux (SuSE 10.3) > > > > > MySQL 5.0.45 > > > > > myodbc 3.51 > > > > > unixODBC 2.2.12 > > > > > > > > > > > > > > > Reply = odbc:param_query(State#state.cref, > > > > > "insert into Users (userId, password, " > > > > > "userType, name) values (?,?,?,?)", > > > > > [{{sql_varchar,20},[UserId]}, > > > > > {{sql_varchar,20},[Passwd]}, > > > > > {{sql_char,6},[Type]}, > > > > > {{sql_varchar,100},[Name]}]), > > > > > > > > > > > > > > > Sometimes I get {updated, 1}, but most of the time I get the > following > > > > error > > > > > {error,"No SQL-driver information available."} but the data has > been > > > > inserted. > > > > > > > > > > The table is created with > > > > > CREATE TABLE IF NOT EXISTS `npas`.`Users` ( > > > > > `userId` VARCHAR(20) NOT NULL , > > > > > `password` VARCHAR(20) NOT NULL , > > > > > `userType` ENUM('admin','normal','read') NOT NULL , > > > > > `name` VARCHAR(100) NOT NULL , > > > > > PRIMARY KEY (`userId`) ) > > > > > ENGINE = InnoDB > > > > > PACK_KEYS = 0 > > > > > ROW_FORMAT = DEFAULT; > > > > > _______________________________________________ > > > > > erlang-bugs mailing list > > > > > erlang-bugs@REDACTED > > > > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > erlang-bugs mailing list > > > > erlang-bugs@REDACTED > > > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > > > > > > > > > > > > From tobias.kraentzer@REDACTED Mon May 5 15:14:10 2008 From: tobias.kraentzer@REDACTED (Tobias =?ISO-8859-1?Q?Kr=E4ntzer?=) Date: Mon, 05 May 2008 13:14:10 +0000 Subject: [erlang-bugs] odbc and 64 bit linux Message-ID: <1209993250.6811.37.camel@bigfoot> Hi, while developing an application with erlang that should connect to PostgreSQL over odbc I encountered a bug on the 64 bit Linux implementation. The Problem: The result from a query with odbc:sql_query/2 and odbc:param_query/3 are not given back. Using odbc:select_query/2 works. >>> {ok, C} = odbc:connect(...). {ok,<0.39.0>} >>> odbc:sql_query(C, "select * from test"). [{selected,[],[]},{},{}] With isql or similar I get my two rows. Searching for a solution I found a post from Laura M. Castro [1] describing the same problem, but now answer. Is there anybody working on a solution or patch? If not, I will give it a try. Regards, Tobias Kr?ntzer [1] -- Linux 2.6.22-14-xen #1 SMP x86_64 GNU/Linux (Debian Etch) Erlang (ASYNC_THREADS) (BEAM) emulator version 5.5.5 odbc 2.0.7 postgresql 8.2 -- Dipl.-Ing. (FH) Tobias Kr?ntzer, Fraunhofer-Institut f?r Software- und Systemtechnik ISST Location-based Services, Wissenschaftlicher Mitarbeiter Mollstrasse 1, 10178 Berlin, Germany Telefon: +49-30-24306-348 From tobias.kraentzer@REDACTED Tue May 6 09:48:28 2008 From: tobias.kraentzer@REDACTED (Tobias =?ISO-8859-1?Q?Kr=E4ntzer?=) Date: Tue, 06 May 2008 09:48:28 +0200 Subject: [erlang-bugs] odbc:sql_query on 64 bit linux Message-ID: <1210060108.6753.3.camel@bigfoot> Hi, while developing an application with erlang that should connect to PostgreSQL over odbc I encountered a bug on the 64 bit Linux implementation. The Problem: The result from a query with odbc:sql_query/2 and odbc:param_query/3 are not given back on a 64 bit Linux. Using odbc:select_query/2 works. On 32 bit Linux, everything is ok. >>> {ok, C} = odbc:connect(...). {ok,<0.39.0>} >>> odbc:sql_query(C, "select * from test"). [{selected,[],[]},{},{}] With isql or similar I get my two rows. Searching for a solution I found a post from Laura M. Castro [1] describing the same problem, but now answer. Is there anybody working on a solution or patch? If not, I will give it a try. Regards, Tobias Kr?ntzer [1] -- Linux 2.6.22-14-xen #1 SMP x86_64 GNU/Linux (Debian Etch) Erlang (ASYNC_THREADS) (BEAM) emulator version 5.5.5 odbc 2.0.7 postgresql 8.2 -- Dipl.-Ing. (FH) Tobias Kr?ntzer, Fraunhofer-Institut f?r Software- und Systemtechnik ISST Location-based Services, Wissenschaftlicher Mitarbeiter Mollstrasse 1, 10178 Berlin, Germany Telefon: +49-30-24306-348 From matthew@REDACTED Thu May 8 04:28:41 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 7 May 2008 19:28:41 -0700 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: <18431.9227.133848.989614@gargle.gargle.HOWL> <18435.1529.209488.50485@gargle.gargle.HOWL> <18437.48350.271334.980195@gargle.gargle.HOWL> Message-ID: Has there been any progress on this? This bug bit us again today. :-( (A pid from a node on a machine that had been decommissioned and not running any Erlang code for months now but still present on our network was still lurking in one of our pg2 groups. Yesterday we finally repurposed this machine, removing it from our network, which had the unexpected side effect of causing Pid ! Msg in some heavily used code to start adding several seconds of delay due to the runtime attempting to autoconnect to that long-dead node.) On Fri, Apr 18, 2008 at 1:23 AM, Matthew Dempsky wrote: > On Wed, Apr 16, 2008 at 1:46 AM, Hans Bolinder > > wrote: > > > I think pg2 should monitor all pids rather than link to local pids > > only. Carefully setting up monitors, like Global does since R11B-4, > > should work. > > Sounds good to me. Can we hope to see this in R12B-3? :-) > From ingela@REDACTED Fri May 9 10:36:38 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 09 May 2008 10:36:38 +0200 Subject: [erlang-bugs] [Fwd: Re: odbc:param_query] In-Reply-To: References: <481ECC05.6000903@erix.ericsson.se> <48215B71.4020802@erix.ericsson.se> Message-ID: <48240D16.3000900@erix.ericsson.se> Hi! After some further correspondence with the 64-bit patch maker (Willi) the conclusion is that this is actually the patch for your problem. @@ -1977,8 +1940,15 @@ static void init_param_column(param_array *params, byte * buffer, int *index, static void init_param_statement(int cols, int num_param_values, db_state *state, param_status *status) { + int i; + status -> param_status_array = (SQLUSMALLINT *)safe_malloc(num_param_values * sizeof(SQLUSMALLINT)); + + for(i=0; i param_status_array[i] = SQL_PARAM_PROCEED; + } But if I understand him correctly there will still be a problem with inserting more than one row with the MySql-driver. This is not a problem with postgress or sql-server. Willi says: "Seems like mysql do not touch param_status_array at all, and server bails out on garbage data when checking for SQLExec termination status. As erlang-bugs reporter pointed, this is not the only problem with mysql driver. I can confirm, when binding arrays mysql picks only first value." Regards Ingela Erlang/OTP Ericsson Anders Nygren wrote: > On Wed, May 7, 2008 at 2:34 AM, Ingela Anderton Andin > wrote: > >> Anders Nygren wrote: >> >> >>> On Mon, May 5, 2008 at 8:01 AM, Anders Nygren >>> >> wrote: >> >>> >>>> 2008/5/5 Ingela Anderton Andin : >>>> >>>> > >>>> > Hi! >>>> > >>>> > As a part of bigger patch (for 64 bit-odbc) I got the following >>>> >> change to >> >>>> > param-queries in odbcserver.c. This might help your case, it would >>>> > be great if you could try that out for me. I am not very found of >>>> >> the ODBC >> >>>> > API (or the implementations of it anyway) it does surprising things >>>> > at times. >>>> > >>>> >>>> Hi Ingela >>>> After a quick test, it looks like it is working fine with the patch. >>>> Thanks a lot. >>>> >>>> /Anders >>>> >>>> >>>> >>> After some more testing I have seen that the problem remains. >>> >>> >>> >>> >> Humm... could you be a little more specific? I guess that the problem >> still occurs but >> not as often?! (As you seemed to think that it helped at first.) >> > > At first it failed most of the time, maybe 75%, but apparently randomly. > After the patch I tested doing maybe 10 insert of one row each and > all were successful. That was when I reported that the patch seemed > to work. > But later when I was testing another param_query it failed again. And > also the original query started to fail again. > I had originally said that even when I got the error the data was inserted. > But that was not completely correct. If I try to insert one row it > gets inserted. > But if I try to INSERT several rows with one param_query and it gives the error > only the first row is inserted. > > Unfortunately I do not have time right now to look into this in more detail, > so I have just switched to using sql_query instead. > Maybe I will be able to do some more tests in the beginning of June. > > /Anders > > >> Maybe there are more special >> cases that occur with the use of some drivers but not others. Alas we can >> not test with all existing >> drivers and all existing backends. We test with the databases >> SQLServer on windows systems and Postgress on unix systems. When I get >> time I will try to test with the table you supplied below in our >> environment. But if the problem >> is driver specific it might work just fine. (Our existing test on >> param-queries does.) >> Just a few questions, does it fail in a predictably way? Always the n:th >> time you try or after you did something >> elese or does it seem to be random? It would be good to have a minimal test >> case to provoke the error. >> Setting up a mysql-environment will however not be a top priority for us. >> In the meantime if you should stumble on some solution yourself we will >> of course accept patches a as long as they do not >> break anything else and seem reasonable. >> >> Regards Ingela, Erlang/OTP Ericsson >> >> >> >> >>>> > @@ -760,6 +758,7 @@ static db_result_msg db_param_query(byte >>>> >> *buffer, >> >>>> > db_state *state) >>>> > switch (param_status.param_status_array[i]) { >>>> > case SQL_PARAM_SUCCESS: >>>> > case SQL_PARAM_SUCCESS_WITH_INFO: >>>> > + case SQL_PARAM_DIAG_UNAVAILABLE: >>>> > break; >>>> > default: >>>> > diagnos = >>>> > >>>> > >>>> > Regards Ingela - OTP team >>>> > >>>> > Anders Nygren wrote: >>>> > >>>> > > I am having a problem with parameterized queries >>>> > > Erlang R12B-2 on Linux (SuSE 10.3) >>>> > > MySQL 5.0.45 >>>> > > myodbc 3.51 >>>> > > unixODBC 2.2.12 >>>> > > >>>> > > >>>> > > Reply = odbc:param_query(State#state.cref, >>>> > > "insert into Users (userId, password, " >>>> > > "userType, name) values (?,?,?,?)", >>>> > > [{{sql_varchar,20},[UserId]}, >>>> > > {{sql_varchar,20},[Passwd]}, >>>> > > {{sql_char,6},[Type]}, >>>> > > {{sql_varchar,100},[Name]}]), >>>> > > >>>> > > >>>> > > Sometimes I get {updated, 1}, but most of the time I get the >>>> >> following >> >>>> > error >>>> > > {error,"No SQL-driver information available."} but the data has >>>> >> been >> >>>> > inserted. >>>> > > >>>> > > The table is created with >>>> > > CREATE TABLE IF NOT EXISTS `npas`.`Users` ( >>>> > > `userId` VARCHAR(20) NOT NULL , >>>> > > `password` VARCHAR(20) NOT NULL , >>>> > > `userType` ENUM('admin','normal','read') NOT NULL , >>>> > > `name` VARCHAR(100) NOT NULL , >>>> > > PRIMARY KEY (`userId`) ) >>>> > > ENGINE = InnoDB >>>> > > PACK_KEYS = 0 >>>> > > ROW_FORMAT = DEFAULT; >>>> > > _______________________________________________ >>>> > > erlang-bugs mailing list >>>> > > erlang-bugs@REDACTED >>>> > > http://www.erlang.org/mailman/listinfo/erlang-bugs >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > erlang-bugs mailing list >>>> > erlang-bugs@REDACTED >>>> > http://www.erlang.org/mailman/listinfo/erlang-bugs >>>> > >>>> >>>> >>>> >>>> >>> >>> >> > > From tobias.kraentzer@REDACTED Fri May 9 10:53:05 2008 From: tobias.kraentzer@REDACTED (Tobias Kraentzer) Date: Fri, 09 May 2008 08:53:05 +0000 Subject: [erlang-bugs] odbc:sql_query on 64 bit linux In-Reply-To: <48240958.8050703@erix.ericsson.se> References: <1210060108.6753.3.camel@bigfoot> <48240958.8050703@erix.ericsson.se> Message-ID: <1210323185.6368.1.camel@bigfoot> Thanks a lot, I will give it a try next week an report the result. Regards, Tobias Kr?ntzer Am Freitag, den 09.05.2008, 10:20 +0200 schrieb Ingela Anderton Andin: > Hi Tobias! > > There is no one working on this particular problem at the moment. > E.i. it is not on top of the priority list. There has however > been some improvements regarding 64-bit support. > If those would solve your problem I do not know, but even if > they do not it would be better if you start working from the latest > version of the code. There will be a new OTP-release in the begining of > June. > But for now I will send you the latest version of odbcserver.c and > odbcserver.h > Good luck. > > Regards Ingela, Erlang/OTP Ericsson > > Tobias Kr?ntzer wrote: > > Hi, > > > > while developing an application with erlang that should connect to > > PostgreSQL over odbc I encountered a bug on the 64 bit Linux > > implementation. > > > > The Problem: The result from a query with odbc:sql_query/2 and > > odbc:param_query/3 are not given back on a 64 bit Linux. Using > > odbc:select_query/2 works. On 32 bit Linux, everything is ok. > > > > > >>>> {ok, C} = odbc:connect(...). > >>>> > > {ok,<0.39.0>} > > > >>>> odbc:sql_query(C, "select * from test"). > >>>> > > [{selected,[],[]},{},{}] > > > > With isql or similar I get my two rows. > > > > Searching for a solution I found a post from Laura M. Castro [1] > > describing the same problem, but now answer. > > > > Is there anybody working on a solution or patch? > > If not, I will give it a try. > > > > Regards, > > Tobias Kr?ntzer > > > > [1] > > > > -- > > Linux 2.6.22-14-xen #1 SMP x86_64 GNU/Linux (Debian Etch) > > Erlang (ASYNC_THREADS) (BEAM) emulator version 5.5.5 > > odbc 2.0.7 > > postgresql 8.2 > > > > > -- Dipl.-Ing. (FH) Tobias Kr?ntzer, Fraunhofer-Institut f?r Software- und Systemtechnik ISST Location-based Services, Wissenschaftlicher Mitarbeiter Mollstrasse 1, 10178 Berlin, Germany Telefon: +49-30-24306-348 From ingela@REDACTED Fri May 9 10:20:40 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 09 May 2008 10:20:40 +0200 Subject: [erlang-bugs] odbc:sql_query on 64 bit linux In-Reply-To: <1210060108.6753.3.camel@bigfoot> References: <1210060108.6753.3.camel@bigfoot> Message-ID: <48240958.8050703@erix.ericsson.se> Hi Tobias! There is no one working on this particular problem at the moment. E.i. it is not on top of the priority list. There has however been some improvements regarding 64-bit support. If those would solve your problem I do not know, but even if they do not it would be better if you start working from the latest version of the code. There will be a new OTP-release in the begining of June. But for now I will send you the latest version of odbcserver.c and odbcserver.h Good luck. Regards Ingela, Erlang/OTP Ericsson Tobias Kr?ntzer wrote: > Hi, > > while developing an application with erlang that should connect to > PostgreSQL over odbc I encountered a bug on the 64 bit Linux > implementation. > > The Problem: The result from a query with odbc:sql_query/2 and > odbc:param_query/3 are not given back on a 64 bit Linux. Using > odbc:select_query/2 works. On 32 bit Linux, everything is ok. > > >>>> {ok, C} = odbc:connect(...). >>>> > {ok,<0.39.0>} > >>>> odbc:sql_query(C, "select * from test"). >>>> > [{selected,[],[]},{},{}] > > With isql or similar I get my two rows. > > Searching for a solution I found a post from Laura M. Castro [1] > describing the same problem, but now answer. > > Is there anybody working on a solution or patch? > If not, I will give it a try. > > Regards, > Tobias Kr?ntzer > > [1] > > -- > Linux 2.6.22-14-xen #1 SMP x86_64 GNU/Linux (Debian Etch) > Erlang (ASYNC_THREADS) (BEAM) emulator version 5.5.5 > odbc 2.0.7 > postgresql 8.2 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: odbcserver.h Type: text/x-chdr Size: 5375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: odbcserver.c Type: text/x-csrc Size: 71344 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Fri May 9 16:45:22 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 9 May 2008 16:45:22 +0200 Subject: [erlang-bugs] : [BUG] SCTP_ADDR_CONFIRMED event not handled In-Reply-To: <1208258451.25766.5.camel@localhost> References: <1207909031.16445.13.camel@localhost> <20080411141216.GA18674@erix.ericsson.se> <1208258451.25766.5.camel@localhost> Message-ID: <20080509144522.GA22576@erix.ericsson.se> On Tue, Apr 15, 2008 at 01:20:51PM +0200, Balint Reczey wrote: > Hi, > > Sergei Golovan updated the patch, now it builds with older lksctp-tools > without SCTP_ADDR_CONFIRMED definition, too: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475540#10 > > Regards, > Balint > I can confirm that his patch looks almost exactly as what I have running in our daily builds now, except that I do not have to patch erts/config.h.in since it is an autoconf build result here, and I did not bother to conditionalize the definition and initialization of am_addr_confirmed in erts/emulator/drivers/common/inet_drv.c, which should not matter at all. Patch by Balint Reczey adds SCTP_ADDR_CONFIRMED SCTP_PEER_ADDR_CHANGE event to Erlang API. Patch is modified by Sergei Golovan to work only with older SCTP also. --- erlang-12.b.2.orig/bootstrap/lib/kernel/include/inet_sctp.hrl +++ erlang-12.b.2/bootstrap/lib/kernel/include/inet_sctp.hrl @@ -73,7 +73,7 @@ %% sctp_paddr_change: Peer address is a list. Possible "state" values: %% addr_available, addr_unreachable, %% addr_removed, addr_added, -%% addr_made_prim +%% addr_made_prim, addr_confirmed -record(sctp_paddr_change, { addr = [0,0,0,0], --- erlang-12.b.2.orig/erts/config.h.in +++ erlang-12.b.2/erts/config.h.in @@ -160,6 +160,10 @@ /* Define to 1 if you have the declaration of `SCTP_UNORDERED', and to 0 if you don't. */ #undef HAVE_DECL_SCTP_UNORDERED + +/* Define to 1 if you have the declaration of `SCTP_ADDR_CONFIRMED', and to 0 if + you don't. */ +#undef HAVE_DECL_SCTP_ADDR_CONFIRMED /* Define to 1 if you have the header file, and it defines `DIR'. */ --- erlang-12.b.2.orig/erts/configure.in +++ erlang-12.b.2/erts/configure.in @@ -1115,7 +1115,7 @@ #endif ]) AC_CHECK_DECLS([SCTP_UNORDERED, SCTP_ADDR_OVER, SCTP_ABORT, - SCTP_EOF, SCTP_SENDALL], [], [], + SCTP_EOF, SCTP_SENDALL, SCTP_ADDR_CONFIRMED], [], [], [#if HAVE_SYS_SOCKET_H #include #endif --- erlang-12.b.2.orig/erts/emulator/drivers/common/inet_drv.c +++ erlang-12.b.2/erts/emulator/drivers/common/inet_drv.c @@ -2752,7 +2752,10 @@ /* For #sctp_paddr_change{}: */ am_addr_available, am_addr_unreachable, am_addr_removed, am_addr_added, - am_addr_made_prim, + am_addr_made_prim, +#if HAVE_DECL_SCTP_ADDR_CONFIRMED + am_addr_confirmed, +#endif /* For #sctp_remote_error{}: */ am_short_recv, am_wrong_anc_data, @@ -3007,6 +3010,11 @@ case SCTP_ADDR_MADE_PRIM: i = LOAD_ATOM (spec, i, am_addr_made_prim); break; +#if HAVE_DECL_SCTP_ADDR_CONFIRMED + case SCTP_ADDR_CONFIRMED: + i = LOAD_ATOM (spec, i, am_addr_confirmed); + break; +#endif default: ASSERT(0); } @@ -3840,6 +3848,9 @@ INIT_ATOM(addr_removed); INIT_ATOM(addr_added); INIT_ATOM(addr_made_prim); +#if HAVE_DECL_SCTP_ADDR_CONFIRMED + INIT_ATOM(addr_confirmed); +#endif INIT_ATOM(short_recv); INIT_ATOM(wrong_anc_data); --- erlang-12.b.2.orig/lib/kernel/include/inet_sctp.hrl +++ erlang-12.b.2/lib/kernel/include/inet_sctp.hrl @@ -73,7 +73,7 @@ %% sctp_paddr_change: Peer address is a list. Possible "state" values: %% addr_available, addr_unreachable, %% addr_removed, addr_added, -%% addr_made_prim +%% addr_made_prim, addr_confirmed -record(sctp_paddr_change, { addr = [0,0,0,0], -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From paul-trapexit@REDACTED Sat May 10 20:22:38 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 10 May 2008 11:22:38 -0700 (PDT) Subject: [erlang-bugs] table referred to by foreign key does not have node pool properly cleaned up when a node is removed from the schema Message-ID: the attachment has a minimal demonstration. this bug causes substantial problems trying to maintain the table going forward since (as indicated in the attachment), manual maintainence of the node pool list is also not possible once this occurs. if we had not been able to create a machine that had the same node name as the one removed, i'm not quite sure how we would have navigated around this in our production system, short of restore from backup. i'm using mnesia-4.3.5 and erlang-otp r11b5. thanks, -- p In an artificial world, only extremists live naturally. -- Paul Graham -------------- next part -------------- A non-text attachment was scrubbed... Name: foreign-key-bug.sh Type: application/x-sh Size: 2684 bytes Desc: URL: From kenneth.lundin@REDACTED Mon May 12 14:57:04 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 12 May 2008 14:57:04 +0200 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: <18431.9227.133848.989614@gargle.gargle.HOWL> <18435.1529.209488.50485@gargle.gargle.HOWL> <18437.48350.271334.980195@gargle.gargle.HOWL> Message-ID: Hi, pg2 is in deep need of systematic tests and a number of bugfixes (at least the one discussed here). The status of pg2 is like that because the module has obviously not been used much at all. The only use of pg2 within OTP is from disk_log (the distributed logs part which also is rarely used). We can not promise when we will have time to improve the pg2 module, it does not come very high up in our priority list. What we can say is that it is a far better chance to get it fixed sooner as part of an OTP release if a patch and test suite is provided by someone in the community. /Regards Kenneth Erlang/OTP, Ericsson On 5/8/08, Andy Gross wrote: > > We also use pg2 heavily in our production network, and are also > interested in seeing a resolution to this bug. It hasn't popped up in > production yet, but when we moved offices we spent a couple of days > trying to purge our pg2 groups of old, stale pids running on IP > addresses from the old office space, to no avail. Eventually each > developer just switched cookies to prevent whatever rogue pg2 instance > was poisoning the group membership. > > Could someone in-the-know describe the monitoring changes made to > global mentioned below? Would a patch from the community with a test > suite be considered for inclusion in any R12-X release? > > - Andy > > > On May 7, 2008, at 10:28 PM, Matthew Dempsky wrote: > > > Has there been any progress on this? This bug bit us again today. :-( > > > > (A pid from a node on a machine that had been decommissioned and not > > running any Erlang code for months now but still present on our > > network was still lurking in one of our pg2 groups. Yesterday we > > finally repurposed this machine, removing it from our network, which > > had the unexpected side effect of causing Pid ! Msg in some heavily > > used code to start adding several seconds of delay due to the runtime > > attempting to autoconnect to that long-dead node.) > > > > On Fri, Apr 18, 2008 at 1:23 AM, Matthew Dempsky > > wrote: > >> On Wed, Apr 16, 2008 at 1:46 AM, Hans Bolinder > >> > >> wrote: > >> > >>> I think pg2 should monitor all pids rather than link to local pids > >>> only. Carefully setting up monitors, like Global does since R11B-4, > >>> should work. > >> > >> Sounds good to me. Can we hope to see this in R12B-3? :-) > >> > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-questions > From tienlex@REDACTED Tue May 13 18:07:23 2008 From: tienlex@REDACTED (tien lex) Date: Tue, 13 May 2008 23:07:23 +0700 Subject: [erlang-bugs] erlang:localtime_to_universaltime return wrong value when pass "true" to the second parameter. Message-ID: Hi, Here is my environment: ti@~: uname -a FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Apr 8 07:57:43 ICT 2008 ti@REDACTED:/usr/obj/usr/src/sys/EXTCOMPAT i386 1> os:getenv("TZ"). "Asia/Saigon" 7> DateTime = {{2008,5,5},{1,1,1}}. {{2008,5,5},{1,1,1}} 9> calendar:local_time_to_universal_time_dst(DateTime). ** exception error: bad argument in function erlang:universaltime_to_localtime/1 called as erlang:universaltime_to_localtime({{1969,12,31},{23,59,59}}) in call from calendar:local_time_to_universal_time_dst/1 10> erlang:localtime_to_universaltime(DateTime, true). {{1969,12,31},{23,59,59}} 11> erlang:localtime_to_universaltime(DateTime, false). {{2008,5,4},{18,1,1}} And below is the result of zdump command on /etc/localtime file: ti@~: zdump -v /etc/localtime /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:52:32 1901 LMT isdst=0 gmtoff=25600 /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:52:32 1901 LMT isdst=0 gmtoff=25600 /etc/localtime Fri Jun 8 16:53:19 1906 UTC = Fri Jun 8 23:59:59 1906 LMT isdst=0 gmtoff=25600 /etc/localtime Fri Jun 8 16:53:20 1906 UTC = Fri Jun 8 23:59:40 1906 SMT isdst=0 gmtoff=25580 /etc/localtime Fri Mar 10 16:54:39 1911 UTC = Sat Mar 11 00:00:59 1911 SMT isdst=0 gmtoff=25580 /etc/localtime Fri Mar 10 16:54:40 1911 UTC = Fri Mar 10 23:54:40 1911 ICT isdst=0 gmtoff=25200 /etc/localtime Tue Apr 30 16:59:59 1912 UTC = Tue Apr 30 23:59:59 1912 ICT isdst=0 gmtoff=25200 /etc/localtime Tue Apr 30 17:00:00 1912 UTC = Wed May 1 01:00:00 1912 ICT isdst=0 gmtoff=28800 /etc/localtime Thu Apr 30 15:59:59 1931 UTC = Thu Apr 30 23:59:59 1931 ICT isdst=0 gmtoff=28800 /etc/localtime Thu Apr 30 16:00:00 1931 UTC = Thu Apr 30 23:00:00 1931 ICT isdst=0 gmtoff=25200 /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 10:14:07 2038 ICT isdst=0 gmtoff=25200 /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 10:14:07 2038 ICT isdst=0 gmtoff=25200 ti@~: It worked great before i change the time zone. Regards, Tien -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed May 14 09:53:25 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 14 May 2008 09:53:25 +0200 Subject: [erlang-bugs] erlang:localtime_to_universaltime return wrong value when pass "true" to the second parameter. In-Reply-To: References: Message-ID: <1210751606.1111.14.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, If it helps I can report that the examplea work _without_ errors on my machine: Linux seasc0642 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007 i686 i686 i386 GNU/Linux bengt On Tue, 2008-05-13 at 23:07 +0700, tien lex wrote: > Hi, > Here is my environment: > ti@~: uname -a > FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Apr 8 07:57:43 ICT > 2008 ti@REDACTED:/usr/obj/usr/src/sys/EXTCOMPAT i386 > > 1> os:getenv("TZ"). > "Asia/Saigon" > 7> DateTime = {{2008,5,5},{1,1,1}}. > {{2008,5,5},{1,1,1}} > 9> calendar:local_time_to_universal_time_dst(DateTime). > ** exception error: bad argument > in function erlang:universaltime_to_localtime/1 > called as > erlang:universaltime_to_localtime({{1969,12,31},{23,59,59}}) > in call from calendar:local_time_to_universal_time_dst/1 > > 10> erlang:localtime_to_universaltime(DateTime, true). > {{1969,12,31},{23,59,59}} > > 11> erlang:localtime_to_universaltime(DateTime, false). > {{2008,5,4},{18,1,1}} > > And below is the result of zdump command on /etc/localtime file: > ti@~: zdump -v /etc/localtime > /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:52:32 > 1901 LMT isdst=0 gmtoff=25600 > /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:52:32 > 1901 LMT isdst=0 gmtoff=25600 > /etc/localtime Fri Jun 8 16:53:19 1906 UTC = Fri Jun 8 23:59:59 > 1906 LMT isdst=0 gmtoff=25600 > /etc/localtime Fri Jun 8 16:53:20 1906 UTC = Fri Jun 8 23:59:40 > 1906 SMT isdst=0 gmtoff=25580 > /etc/localtime Fri Mar 10 16:54:39 1911 UTC = Sat Mar 11 00:00:59 > 1911 SMT isdst=0 gmtoff=25580 > /etc/localtime Fri Mar 10 16:54:40 1911 UTC = Fri Mar 10 23:54:40 > 1911 ICT isdst=0 gmtoff=25200 > /etc/localtime Tue Apr 30 16:59:59 1912 UTC = Tue Apr 30 23:59:59 > 1912 ICT isdst=0 gmtoff=25200 > /etc/localtime Tue Apr 30 17:00:00 1912 UTC = Wed May 1 01:00:00 > 1912 ICT isdst=0 gmtoff=28800 > /etc/localtime Thu Apr 30 15:59:59 1931 UTC = Thu Apr 30 23:59:59 > 1931 ICT isdst=0 gmtoff=28800 > /etc/localtime Thu Apr 30 16:00:00 1931 UTC = Thu Apr 30 23:00:00 > 1931 ICT isdst=0 gmtoff=25200 > /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 10:14:07 > 2038 ICT isdst=0 gmtoff=25200 > /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 10:14:07 > 2038 ICT isdst=0 gmtoff=25200 > ti@~: > > It worked great before i change the time zone. > > Regards, > Tien > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From raimo+erlang-bugs@REDACTED Wed May 14 10:24:07 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 14 May 2008 10:24:07 +0200 Subject: [erlang-bugs] erlang:localtime_to_universaltime return wrong value when pass "true" to the second parameter. In-Reply-To: References: Message-ID: <20080514082407.GA7111@erix.ericsson.se> Thank you for reporting this bug. It seemd Erlang should check the return values of OS calls mktime and gmtime better. Unfortunately the gmtime function on e.g OpenBSD is not documented to return NULL on failure. But in your case it is mktime that returns -1 and Erlang does not notice that but instead uses the value which results in the funny time {1969,12,31},{23,59,59}, one second before the Unix Epoch start. Asia/Saigon does not have any daylight saving time defined. erlang:localtim_to_universaltime(DateTime, true) should exit with badarg. Using perl: $ TZ='Asia/Saigon' perl -we 'use strict; use POSIX; tzset; my $t = mktime(1, 1, 1, 5, 4, 108, 0, 0, 1); if (defined $t) {my @g = gmtime($t); print "@g\n"} else {print "undef\n"};' undef $ TZ='Asia/Saigon' perl -we 'use strict; use POSIX; tzset; my @g = gmtime(-1); print "@g\n"' 59 59 23 31 11 69 3 364 0 # {{1969,12,31},{23,59,59}} $ TZ='Asia/Saigon' perl -we 'use strict; use POSIX; tzset; my $t = mktime(1, 1, 1, 5, 4, 108, 0, 0, 0); if (defined $t) {my @g = gmtime($t); print "@g\n"} else {print "undef\n"};' 1 1 18 5 4 108 6 123 0 # {{2008,5,5},{18,1,1}} On Tue, May 13, 2008 at 11:07:23PM +0700, tien lex wrote: > Hi, > Here is my environment: > ti@~: uname -a > FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Apr 8 07:57:43 ICT > 2008 ti@REDACTED:/usr/obj/usr/src/sys/EXTCOMPAT i386 > > 1> os:getenv("TZ"). > "Asia/Saigon" > 7> DateTime = {{2008,5,5},{1,1,1}}. > {{2008,5,5},{1,1,1}} > 9> calendar:local_time_to_universal_time_dst(DateTime). > ** exception error: bad argument > in function erlang:universaltime_to_localtime/1 > called as > erlang:universaltime_to_localtime({{1969,12,31},{23,59,59}}) > in call from calendar:local_time_to_universal_time_dst/1 > > 10> erlang:localtime_to_universaltime(DateTime, true). > {{1969,12,31},{23,59,59}} > > 11> erlang:localtime_to_universaltime(DateTime, false). > {{2008,5,4},{18,1,1}} > > And below is the result of zdump command on /etc/localtime file: > ti@~: zdump -v /etc/localtime > /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:52:32 1901 LMT > isdst=0 gmtoff=25600 > /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:52:32 1901 LMT > isdst=0 gmtoff=25600 > /etc/localtime Fri Jun 8 16:53:19 1906 UTC = Fri Jun 8 23:59:59 1906 LMT > isdst=0 gmtoff=25600 > /etc/localtime Fri Jun 8 16:53:20 1906 UTC = Fri Jun 8 23:59:40 1906 SMT > isdst=0 gmtoff=25580 > /etc/localtime Fri Mar 10 16:54:39 1911 UTC = Sat Mar 11 00:00:59 1911 SMT > isdst=0 gmtoff=25580 > /etc/localtime Fri Mar 10 16:54:40 1911 UTC = Fri Mar 10 23:54:40 1911 ICT > isdst=0 gmtoff=25200 > /etc/localtime Tue Apr 30 16:59:59 1912 UTC = Tue Apr 30 23:59:59 1912 ICT > isdst=0 gmtoff=25200 > /etc/localtime Tue Apr 30 17:00:00 1912 UTC = Wed May 1 01:00:00 1912 ICT > isdst=0 gmtoff=28800 > /etc/localtime Thu Apr 30 15:59:59 1931 UTC = Thu Apr 30 23:59:59 1931 ICT > isdst=0 gmtoff=28800 > /etc/localtime Thu Apr 30 16:00:00 1931 UTC = Thu Apr 30 23:00:00 1931 ICT > isdst=0 gmtoff=25200 > /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 10:14:07 2038 ICT > isdst=0 gmtoff=25200 > /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 10:14:07 2038 ICT > isdst=0 gmtoff=25200 > ti@~: > > It worked great before i change the time zone. > > Regards, > Tien > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mickael.remond@REDACTED Wed May 14 17:48:28 2008 From: mickael.remond@REDACTED (=?UTF-8?Q?Micka=C3=ABl_R=C3=A9mond?=) Date: Wed, 14 May 2008 17:48:28 +0200 Subject: [erlang-bugs] inet_res: unpredictable resolution failure ? Message-ID: <12DFF57F-A18C-410B-8FD1-A9D9D6958738@process-one.net> Hello, I suspect a bug in inet_res. When using this resolver it seems we get somewhat unpredictable results: - gethostbyname can fails sometime (nxdomain error) - connect sometimes fails with nxdomain error If retry immediately the query / connect most of the time succeed. I know that this module is not documented, but to my knowledge it is the only way to do DNS lookup on some specific type of records (mx or srv records). I can provide details if you need to. Thank you ! -- Micka?l R?mond http://www.process-one.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Thu May 15 09:33:16 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 15 May 2008 09:33:16 +0200 Subject: [erlang-bugs] inet_res: unpredictable resolution failure ? In-Reply-To: <12DFF57F-A18C-410B-8FD1-A9D9D6958738@process-one.net> References: <12DFF57F-A18C-410B-8FD1-A9D9D6958738@process-one.net> Message-ID: <20080515073316.GA31979@erix.ericsson.se> On Wed, May 14, 2008 at 05:48:28PM +0200, Micka?l R?mond wrote: > Hello, > > I suspect a bug in inet_res. When using this resolver it seems we get > somewhat unpredictable results: > - gethostbyname can fails sometime (nxdomain error) > - connect sometimes fails with nxdomain error You mean gen_tcp:connect when using inet_res as resolver? > If retry immediately the query / connect most of the time succeed. > > I know that this module is not documented, but to my knowledge it is > the only way to do DNS lookup on some specific type of records (mx or > srv records). > > I can provide details if you need to. Yes please! > > Thank you ! > > -- > Micka?l R?mond > http://www.process-one.net/ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mickael.remond@REDACTED Thu May 15 10:10:02 2008 From: mickael.remond@REDACTED (=?ISO-8859-1?Q?Micka=EBl_R=E9mond?=) Date: Thu, 15 May 2008 10:10:02 +0200 Subject: [erlang-bugs] inet_res: unpredictable resolution failure ? In-Reply-To: <20080515073316.GA31979@erix.ericsson.se> References: <12DFF57F-A18C-410B-8FD1-A9D9D6958738@process-one.net> <20080515073316.GA31979@erix.ericsson.se> Message-ID: <31F83401-EFD3-44A8-90C8-1FE06CF68581@process-one.net> Hello, Le 15 mai 08 ? 09:33, Raimo Niskanen a ?crit : > On Wed, May 14, 2008 at 05:48:28PM +0200, Micka?l R?mond wrote: >> Hello, >> >> I suspect a bug in inet_res. When using this resolver it seems we get >> somewhat unpredictable results: >> - gethostbyname can fails sometime (nxdomain error) >> - connect sometimes fails with nxdomain error > > You mean gen_tcp:connect when using inet_res as resolver? Yes. >> If retry immediately the query / connect most of the time succeed. >> >> I know that this module is not documented, but to my knowledge it is >> the only way to do DNS lookup on some specific type of records (mx or >> srv records). >> >> I can provide details if you need to. > > Yes please! What would you need ? Should I put the resolver in debug mode and do many connects until I reproduce the problem ? It happens on live system. Error seems to happens when a lot of different resolution are done at the same time. The result is that tcp_connect seems sometime to fail with nxdomain, and the retry one second later works. -- Micka?l R?mond http://www.process-one.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Thu May 15 11:09:54 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 15 May 2008 11:09:54 +0200 Subject: [erlang-bugs] : inet_res: unpredictable resolution failure ? In-Reply-To: <31F83401-EFD3-44A8-90C8-1FE06CF68581@process-one.net> References: <12DFF57F-A18C-410B-8FD1-A9D9D6958738@process-one.net> <20080515073316.GA31979@erix.ericsson.se> <31F83401-EFD3-44A8-90C8-1FE06CF68581@process-one.net> Message-ID: <20080515090954.GC613@erix.ericsson.se> On Thu, May 15, 2008 at 10:10:02AM +0200, Micka?l R?mond wrote: : > > >>If retry immediately the query / connect most of the time succeed. > >> > >>I know that this module is not documented, but to my knowledge it is > >>the only way to do DNS lookup on some specific type of records (mx or > >>srv records). > >> > >>I can provide details if you need to. > > > >Yes please! > > > What would you need ? The problem is that I do not know. > Should I put the resolver in debug mode and do many connects until I > reproduce the problem ? Yes why not, is there a debug mode? > It happens on live system. Error seems to happens when a lot of > different resolution are done at the same time. > The result is that tcp_connect seems sometime to fail with nxdomain, Some investigation on the failed name and type, how long time the failed lookup took. A debug or trace of just the failed lookup would of course be interesting. Narrowing the problem; just doing name lookups as the live system does - does it fail the same way? Is there a network problem? Does the failed call go to an external, DNS server, and is that one suddenly unreachable or doing strange things. Does the nxdomain reply origin locally? Many questions but no good idea how to answer them... > and the retry one second later works. > > -- > Micka?l R?mond > http://www.process-one.net/ > > > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From stonecypher@REDACTED Thu May 15 16:18:50 2008 From: stonecypher@REDACTED (John Haugeland) Date: Thu, 15 May 2008 08:18:50 -0600 Subject: [erlang-bugs] Math library defect? Message-ID: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> I believe I have found a defect in the math library. 24> io:format("~f",[math:pow(2,56)]). 72057594037927936.000000ok 25> io:format("~f",[math:pow(2,57)]). 144115188075855870.000000ok 26> 72057594037927936 * 2. 144115188075855872 You'll notice that the value given by step 25 is incorrect by two. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stonecypher@REDACTED Thu May 15 18:48:45 2008 From: stonecypher@REDACTED (John Haugeland) Date: Thu, 15 May 2008 10:48:45 -0600 Subject: [erlang-bugs] Please ignore the previous post Message-ID: <8f24f4b10805150948h76ac696ege0db0d9344cbe91f@mail.gmail.com> As many are now pointing out, my error is that floating point is a limited accuracy medium. I was under the misimpression that Erlang had infinite precision libraries in use for all numeric types; this turns out only to be true of integers. Pierpaolo, Tony, parsedtree, thank you each for your cluesticks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew@REDACTED Thu May 15 18:57:42 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 15 May 2008 09:57:42 -0700 Subject: [erlang-bugs] Math library defect? In-Reply-To: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> Message-ID: 2008/5/15 John Haugeland : > I believe I have found a defect in the math library. > > 24> io:format("~f",[math:pow(2,56)]). > 72057594037927936.000000ok > > 25> io:format("~f",[math:pow(2,57)]). > 144115188075855870.000000ok > > 26> 72057594037927936 * 2. > 144115188075855872 > > You'll notice that the value given by step 25 is incorrect by two. What version of OTP and what operating system are you using? It works fine for me with R12B-1 on OS X 10.5: 5> io:format("~f ~f.~n", [math:pow(2, 56), math:pow(2, 57)]). 72057594037927936.000000 144115188075855872.000000. From matthew@REDACTED Thu May 15 19:04:28 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 15 May 2008 10:04:28 -0700 Subject: [erlang-bugs] Please ignore the previous post In-Reply-To: <8f24f4b10805150948h76ac696ege0db0d9344cbe91f@mail.gmail.com> References: <8f24f4b10805150948h76ac696ege0db0d9344cbe91f@mail.gmail.com> Message-ID: 2008/5/15 John Haugeland : > As many are now pointing out, my error is that floating point is a limited > accuracy medium. I was under the misimpression that Erlang had infinite > precision libraries in use for all numeric types; this turns out only to be > true of integers. Assuming you're referring to the post about math:pow(2, 56) vs. math:pow(2, 57), those people are wrong unless you're using an computer that does not use IEEE floating point numbers. IEEE-754 can exactly represent powers of 2 (constrained by limitations of the exponent). From matthew@REDACTED Thu May 15 19:11:46 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 15 May 2008 10:11:46 -0700 Subject: [erlang-bugs] Math library defect? In-Reply-To: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> Message-ID: 2008/5/15 John Haugeland : > I believe I have found a defect in the math library. Erlang's math:pow function is implemented using the C math library's pow(3) function. Try compiling and running this program to test: $ cat > test.c < #include int main() { printf("%f\n", pow(2.0, 57.0) - 2 * pow(2.0, 56.0)); return 0; } EOF $ cc -o test test.c -lm $ ./test 0.000000 From hakan@REDACTED Fri May 16 16:30:32 2008 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 16 May 2008 16:30:32 +0200 (CEST) Subject: [erlang-bugs] table referred to by foreign key does not have node pool properly cleaned up when a node is removed from the schema (fwd) Message-ID: FYI. /H?kan --- H?kan Mattsson (uabhams) Erlang/OTP crew, Ericsson ---------- Forwarded message ---------- Date: Fri, 16 May 2008 16:19:13 +0200 (CEST) From: Hakan Mattsson To: Paul Mineiro Cc: Dan Gudmundsson Subject: Re: [erlang-bugs] table referred to by foreign key does not have node pool properly cleaned up when a node is removed from the schema Hi Paul! Thank you for reporting this error. It is now fixed and will be released in mnesia-4.4.3 (R12B-3). Put the attached file in some directory in your code path in order to get rid of the problem. /H?kan --- H?kan Mattsson (uabhams) Erlang/OTP crew, Ericsson On Thu, 15 May 2008, Dan Gudmundsson wrote: -------- Original Message -------- Subject: [erlang-bugs] table referred to by foreign key does not have node pool properly cleaned up when a node is removed from the schema Date: Sat, 10 May 2008 11:22:38 -0700 (PDT) From: Paul Mineiro To: erlang-bugs@REDACTED the attachment has a minimal demonstration. this bug causes substantial problems trying to maintain the table going forward since (as indicated in the attachment), manual maintainence of the node pool list is also not possible once this occurs. if we had not been able to create a machine that had the same node name as the one removed, i'm not quite sure how we would have navigated around this in our production system, short of restore from backup. i'm using mnesia-4.3.5 and erlang-otp r11b5. thanks, -- p In an artificial world, only extremists live naturally. -- Paul Graham -------------- next part -------------- A non-text attachment was scrubbed... Name: mnesia_frag.beam Type: application/octet-stream Size: 49052 bytes Desc: mnesia_frag.beam URL: From dot@REDACTED Thu May 15 17:50:05 2008 From: dot@REDACTED (Tony Finch) Date: Thu, 15 May 2008 16:50:05 +0100 Subject: [erlang-bugs] Math library defect? In-Reply-To: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> Message-ID: On Thu, 15 May 2008, John Haugeland wrote: > I believe I have found a defect in the math library. You have just discovered that floating point numbers have limited precision. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH UTSIRE: NORTHWESTERLY 5 TO 7. MODERATE. RAIN OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR. From matthew@REDACTED Sat May 17 20:38:32 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sat, 17 May 2008 11:38:32 -0700 Subject: [erlang-bugs] Math library defect? In-Reply-To: References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> Message-ID: (This is dated two days ago, but it just showed up in my inbox.) On Thu, May 15, 2008 at 8:50 AM, Tony Finch wrote: > On Thu, 15 May 2008, John Haugeland wrote: >> I believe I have found a defect in the math library. > > You have just discovered that floating point numbers have limited precision. That's irrelevant here. 2^{56} and 2^{57} can be represented exactly using IEEE-754 double precision floating point numbers. From matthew.dempsky@REDACTED Sun May 18 07:13:24 2008 From: matthew.dempsky@REDACTED (Matthew Dempsky) Date: Sat, 17 May 2008 22:13:24 -0700 Subject: [erlang-bugs] table referred to by foreign key does not have node pool properly cleaned up when a node is removed from the schema In-Reply-To: References: Message-ID: 2008/5/10 Paul Mineiro : > if we had not been > able to create a machine that had the same node name as the one removed, > i'm not quite sure how we would have navigated around this in our > production system, short of restore from backup. For what it's worth, at least when using long node names, you can assign whatever arbitrary name you want to a node. E.g., there's nothing stopping me from running "erl -name foo@REDACTED" or "erl -name bar@REDACTED" on my laptop right now. The only catch is that this node needs to be the one to initiate all distribution connections. From fw@REDACTED Mon May 19 07:19:38 2008 From: fw@REDACTED (Florian Weimer) Date: Mon, 19 May 2008 07:19:38 +0200 Subject: [erlang-bugs] Math library defect? In-Reply-To: (Matthew Dempsky's message of "Sat, 17 May 2008 11:38:32 -0700") References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> Message-ID: <87k5hqeuqd.fsf@mid.deneb.enyo.de> * Matthew Dempsky: > (This is dated two days ago, but it just showed up in my inbox.) > > On Thu, May 15, 2008 at 8:50 AM, Tony Finch wrote: >> On Thu, 15 May 2008, John Haugeland wrote: >>> I believe I have found a defect in the math library. >> >> You have just discovered that floating point numbers have limited precision. > > That's irrelevant here. 2^{56} and 2^{57} can be represented exactly > using IEEE-754 double precision floating point numbers. 144115188075855870.0 and 144115188075855872.0 are the same number as far as doubles are concerned. So if there's a bug, it's in the conversion to decimal, not in pow. From matthew@REDACTED Mon May 19 08:17:52 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sun, 18 May 2008 23:17:52 -0700 Subject: [erlang-bugs] Math library defect? In-Reply-To: <87k5hqeuqd.fsf@mid.deneb.enyo.de> References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> <87k5hqeuqd.fsf@mid.deneb.enyo.de> Message-ID: On Sun, May 18, 2008 at 10:19 PM, Florian Weimer wrote: > 144115188075855870.0 and 144115188075855872.0 are the same number as far > as doubles are concerned. So if there's a bug, it's in the conversion > to decimal, not in pow. Hm, good catch. From tobias.kraentzer@REDACTED Mon May 19 10:02:54 2008 From: tobias.kraentzer@REDACTED (Tobias Kraentzer) Date: Mon, 19 May 2008 10:02:54 +0200 Subject: [erlang-bugs] Found odbc 64 bit bug! In-Reply-To: <482A8FE3.7080609@erix.ericsson.se> References: <1210060108.6753.3.camel@bigfoot> <48240958.8050703@erix.ericsson.se> <1210323185.6368.1.camel@bigfoot> <482A8FE3.7080609@erix.ericsson.se> Message-ID: <1211184174.7664.6.camel@bigfoot> Hi Ingela, sorry for the delay, but I was working on an other topic. It seems, that the patch fixed the problem with odbc:sql_query/2 and odbc:param_query/3. Thanks a lot :-) Regards, Tobias Kr?ntzer Am Mittwoch, den 14.05.2008, 09:08 +0200 schrieb Ingela Anderton Andin: > Hi again! > > We have located the problem that I alerted you to the other day with > the 64-bit patch for integer handling. > The following applied to the the code I originally sent you should do > the trick. > > --- a/lib/odbc/c_src/odbcserver.c > +++ b/lib/odbc/c_src/odbcserver.c > @@ -1372,7 +1372,7 @@ static Boolean decode_params(byte *buffer, int > *index, param_array **params, > param_array* param; > > ei_get_type(buffer, index, &erl_type, &size); > - param = params[i]; > + param = &(*params)[i]; > > switch (param->type.c) { > case SQL_C_CHAR: > > > > Regards Ingela Erlang/OTP Ericsson > -- Dipl.-Ing. (FH) Tobias Kr?ntzer, Fraunhofer-Institut f?r Software- und Systemtechnik ISST Location-based Services, Wissenschaftlicher Mitarbeiter Mollstrasse 1, 10178 Berlin, Germany Telefon: +49-30-24306-348 From raimo+erlang-bugs@REDACTED Mon May 19 16:52:58 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 19 May 2008 16:52:58 +0200 Subject: [erlang-bugs] : Math library defect? In-Reply-To: References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> <87k5hqeuqd.fsf@mid.deneb.enyo.de> Message-ID: <20080519145258.GA9638@erix.ericsson.se> On Sun, May 18, 2008 at 11:17:52PM -0700, Matthew Dempsky wrote: > On Sun, May 18, 2008 at 10:19 PM, Florian Weimer wrote: > > 144115188075855870.0 and 144115188075855872.0 are the same number as far > > as doubles are concerned. So if there's a bug, it's in the conversion > > to decimal, not in pow. > > Hm, good catch. I can not reproduce the original problem. Using R12B-2: 1> io:format("~f~n", [math:pow(2,56)]). 72057594037927936.000000 ok 2> io:format("~f~n", [math:pow(2,57)]). 144115188075855872.000000 ok This is the correct number, but: 3> io:format("~p~n", [math:pow(2,57)]). 144115188075855870.0 ok ...gives the "incorrect" number the original poster claimed. And it is hard to call that number incorrect since: 4> math:pow(2,57) =:= float(144115188075855870). true 5> math:pow(2,57) =:= float(144115188075855872). true ...both are the same floating point number. 6> round(math:pow(2,57)). 144115188075855872 ...gives you the right integer. To elaborate ------------ io:format's ~e, ~f and ~g uses the C library sprintf(, "%.20e, ) for raw conversion and then does string manipulation on the result. io:format's ~p and ~P prints the minimal number of decimal digits required to reproduce the correct floating point number, so it fills with decimal zeros in the low end when required for large numbers. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Tue May 20 09:35:12 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 20 May 2008 09:35:12 +0200 Subject: [erlang-bugs] : : Math library defect? In-Reply-To: <18481.41240.243490.376165@antilipe.corelatus.se> References: <8f24f4b10805150718p3feaee37u19ab8479ffe9aaf7@mail.gmail.com> <87k5hqeuqd.fsf@mid.deneb.enyo.de> <20080519145258.GA9638@erix.ericsson.se> <18481.41240.243490.376165@antilipe.corelatus.se> Message-ID: <20080520073512.GA28214@erix.ericsson.se> On Mon, May 19, 2008 at 05:47:36PM +0200, Matthias Lang wrote: > Raimo Niskanen writes: > > > I can not reproduce the original problem. > > Using R12B-2: > > Ok, and the original poster just (an hour or two ago) told us that > he's using "erl5.5.5" which is probably R11B-5 on _windows_. > Sorry about that oversight. I was very tired yesterday, should not have answered at all... > And here's what I get on an XP machine with service pack 2, Hollywood > Content Protection System 9, Anti-Virus 15.871, SCO licence #7: Ehm? > > 1> init:script_id(). > {"OTP APN 181 01","R11B"} > 2> io:fwrite("~f\n", [math:pow(2,57)]). > 144115188075855870.000000 > > Raimo: > > 2> io:format("~f~n", [math:pow(2,57)]). > > 144115188075855872.000000 > > So, Windows, at least that particular variant on that particular > machine, seems to behave slightly differently. I don't have a C > compiler for Windows and I don't know if math library source is even > available. I can now confirm that OTP R12B-3 beta behaves the same, at least on XP probably SP 2. Eshell V5.6.3 (abort with ^G) 1> f(F), F = math:pow(2, 57). 144115188075855870.0 2> erlang:term_to_binary(F, [{minor_version, 1}]). <<131,70,67,128,0,0,0,0,0,0>> 3> round(F). 144115188075855872 4> trunc(F). 144115188075855872 5> io:format("~f~n", [F]). 144115188075855870.000000 ok 6> io:format("~.22e~n", [F]). 1.441151880758558700000e+17 ok 7> io:format("~.22g~n", [F]). 1.441151880758558700000e+17 ok Since the bit pattern of the float is correct as well as the values from round/1 and trunc/1; it is most probably C library sprintf(, "%.20e", ) that behaves differently from Unixes. > > Matt -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mbj@REDACTED Tue May 20 10:36:19 2008 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 20 May 2008 10:36:19 +0200 (CEST) Subject: [erlang-bugs] erlang:halt bug Message-ID: <20080520.103619.14808773.mbj@tail-f.com> Hi, Doing erlang:halt(lists:duplicate(199,$a)). halts the emulator just as it should. But erlang:halt(lists:duplicate(200,$a)). fails with badarg. The reason of that the halt_1 bif checks if the string is longer than 199 bytes; if it is it returns badarg. The documentation doesn't mention this at all. IMO, the bif should truncate the string if necessary. I noted that the code in init.erl truncates this in one case... /martin From yura.bronnikov@REDACTED Fri May 23 16:22:22 2008 From: yura.bronnikov@REDACTED (George Bronnikov) Date: Fri, 23 May 2008 18:22:22 +0400 Subject: [erlang-bugs] io_lib_format:fwrite_g/1 on arm Message-ID: <1e2dc6f60805230722h104c42a2p4ac9d42da43a815a@mail.gmail.com> In recent versions (since R12B0?), io_lib_format:fwrite_g/1, which is the default function for printing floats, analyzes its argument using a bit pattern (mantissa_exponent is a helper function called from fwrite_g): mantissa_exponent(F) -> case <> of <<_S:1, 0:11, M:52>> -> % denormalized E = log2floor(M), {M bsl (53 - E), E - 52 - 1075}; <<_S:1, BE:11, M:52>> when BE < 2047 -> {M + ?BIG_POW, BE - 1075} end. Unfortunately, on Linux/arm (at least in my configuration), a float has its 32-bit words swapped, so the function produces garbage. Reverting to the version from R11B-4 (which just calls fwrite_g/4 with appropriate defaults) gets rid of the bug. Configuration: iPaq3900, Familiar 0.8.4, Linux 2.4.19-rmk6-pxa1-hh41.1, glibc 2.3.90, gcc-3.4.4. George From mikpe@REDACTED Fri May 23 20:17:12 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 23 May 2008 20:17:12 +0200 Subject: [erlang-bugs] io_lib_format:fwrite_g/1 on arm In-Reply-To: <1e2dc6f60805230722h104c42a2p4ac9d42da43a815a@mail.gmail.com> References: <1e2dc6f60805230722h104c42a2p4ac9d42da43a815a@mail.gmail.com> Message-ID: <18487.2600.250225.929119@harpo.it.uu.se> George Bronnikov writes: > In recent versions (since R12B0?), io_lib_format:fwrite_g/1, which is > the default function for printing floats, analyzes its argument using > a bit pattern (mantissa_exponent is a helper function called from > fwrite_g): > > mantissa_exponent(F) -> > case <> of > <<_S:1, 0:11, M:52>> -> % denormalized > E = log2floor(M), > {M bsl (53 - E), E - 52 - 1075}; > <<_S:1, BE:11, M:52>> when BE < 2047 -> > {M + ?BIG_POW, BE - 1075} > end. > > Unfortunately, on Linux/arm (at least in my configuration), a float > has its 32-bit words swapped, so the function produces garbage. > Reverting to the version from R11B-4 (which just calls fwrite_g/4 with > appropriate defaults) gets rid of the bug. > > Configuration: iPaq3900, Familiar 0.8.4, Linux > 2.4.19-rmk6-pxa1-hh41.1, glibc 2.3.90, gcc-3.4.4. My guess is that your system uses the FPA floating-point format, and your CPU runs in big-endian mode. The problem on ARM is that the architecture initially didn't specify an FPU or the FP format. An early add-on FPU was the FPA, which used the standard IEEE 64-bit format but made it always little-endian even if the CPU was big-endian (I'm a bit uncertain about the details, but that's the essence of it). Only a minority of CPUs actually included the FPA, but the pathetic FPA instruction set and its broken FP format became standard, even for soft-float, at least in the Linux world. Later on ARM added the VFP FPU to some models. The VFP is much saner, and the FP format is standard IEEE 64-bit stored in the same endianess as the CPU uses, much like any other sane CPU. The problem now is that unless you know which FPU model your system is using (FPA or VFP; hard or soft doesn't matter), you cannot reliably inspect the bit-level representation of FP values. Personally I'd either rip out this mantissa_exponent/1 thing, or reimplement it in C where there are well-known preprocessor symbols that tell you which FP format it's using. /Mikael From badlop@REDACTED Wed May 28 13:27:50 2008 From: badlop@REDACTED (Badlop) Date: Wed, 28 May 2008 13:27:50 +0200 Subject: [erlang-bugs] Sum small floats and get erroneous result in R12B-2 Message-ID: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> Hi, It seems I found a bug in Erlang/OTP R12B-2 [1]. It only happens with certain operations and certain operands. I haven't investigated what is the cause, so I can only provide an example: $ erl Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1> 20.14 + 2.01. 22.15 2> 20.15 + 2.01. 22.159999999999997 3> 20.16 + 2.01. 22.17 4> 21.15 + 1.01. 22.16 5> 120.15 + 2.01. 122.16000000000001 6> 1120.15 + 2.01. 1122.16 We see that 1, 3, 4 and 6 provide the exact result. But the results of 2 and 5 look strange. Using OTP R11B-5 all works correctly: $ erl Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> 20.15 + 2.01. 22.1600 [1] It was reproducible with Debian package 1:12.b.2-dfsg-3 linux-x86 and macosx-intel. From kenji.rikitake@REDACTED Wed May 28 13:45:42 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 28 May 2008 20:45:42 +0900 Subject: [erlang-bugs] Sum small floats and get erroneous result in R12B-2 In-Reply-To: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> References: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> Message-ID: <20080528114542.GA29153@k2r.org> Also reproducible on R12B2 running on Windows XP SP3 (Japanese version) (Intel Core2Duo E6300) // Kenji Rikitake Erlang (BEAM) emulator version 5.6.2 [smp:2] [async-threads:0] Eshell V5.6.2 (abort with ^G) 1> 20.14+2.01 1> . 22.15 2> 20.15+2.01. 22.159999999999997 3> 20.16+2.01. 22.17 4> 21.15+2.01. 23.159999999999997 5> 120.15+2.01. 122.16000000000001 In the message <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@REDACTED> dated Wed, May 28, 2008 at 01:27:27PM +0200, Badlop writes: > Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] > [async-threads:0] [kernel-poll:false] > > Eshell V5.6.2 (abort with ^G) > 1> 20.14 + 2.01. > 22.15 > 2> 20.15 + 2.01. > 22.159999999999997 > 3> 20.16 + 2.01. > 22.17 > 4> 21.15 + 1.01. > 22.16 > 5> 120.15 + 2.01. > 122.16000000000001 > 6> 1120.15 + 2.01. > 1122.16 > > > We see that 1, 3, 4 and 6 provide the exact result. > But the results of 2 and 5 look strange. > > [1] It was reproducible with Debian package 1:12.b.2-dfsg-3 linux-x86 > and macosx-intel. From matthew@REDACTED Wed May 28 15:54:28 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 28 May 2008 06:54:28 -0700 Subject: [erlang-bugs] Sum small floats and get erroneous result in R12B-2 In-Reply-To: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> References: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> Message-ID: On Wed, May 28, 2008 at 4:27 AM, Badlop wrote: > It seems I found a bug in Erlang/OTP R12B-2 [1]. Search the archives or google about IEEE-754 floating point numbers. This question comes up every three days. From erlang-questions_efine@REDACTED Thu May 29 00:12:26 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Wed, 28 May 2008 18:12:26 -0400 Subject: [erlang-bugs] OTP-OS-MON-MIB bugs Message-ID: <6c2563b20805281512kd94b832r5b8473d9f0fd180d@mail.gmail.com> I need to thank Martin Bjorkland for helping me recognize this bug. I believe that the file OTP-OS-MON-MIB.mib has two sets of bugs, one more serious than the other. Fixing the first bug also showed up a potential third bug (see later). *The More Serious One* The following objects in OTP-OS-MON-MIB.mib are defined as type Gauge32, and cause problems when the values returned are actually greater than a 32-bit value can represent: loadSystemTotalMemory Gauge32, loadSystemUsedMemory Gauge32, loadLargestErlProcessUsedMemory Gauge32, To reproduce this problem, simply do an snmpwalk on a 64-bit system that has more than 4 GB of memory (mine is Ubuntu 7.10 x86_64 with 8 GB) and try to get the loadSystemTotalMemory.0 object. *Example of error:* $ snmpwalk -m ALL -u initial 127.0.0.1:4000 loadSystemTotalMemory.0 Error in packet. Reason: (genError) A general failure occured Failed object: OTP-OS-MON-MIB::loadSystemTotalMemory."" OTP-OS-MON-MIB::loadSystemTotalMemory."" = No Such Instance currently exists at this OID ------------- *Agent error message* I believe the agent error message below shows that the value of 8386678784 (not coincidentally, about 8 GB) is out of range. =ERROR REPORT==== 28-May-2008::00:26:03 === ** User error: Got 8386678784 from {os_mon_mib,load_table,[]}. Using wrongValue -------------- *Proposed Solution* The solution according to Martin is to change the Gauge32 types to be CounterBasedGauge64, from HCNUM-TC. I tried this in OTP-OS-MON-MIB as follows: 1. cd /usr/local/lib/erlang/lib/os_mon-2.1.5/mibs 2. cp OTP-OS-MON-MIB.mib OTP-OS-MON-MIB.mib.buggy 3. (Modified OTP-OS-MON-MIB.mib as shown in the diff output at the end of this email.) 4. cp /usr/share/snmp/mibs/HCNUM-TC.txt ./HCNUM-TC.mib 5. erlc -o ../priv/mibs/ -I ../priv/mibs -I ../../otp_mibs-1.0.4.1/priv/mibs HCNUM-TC.mib OTP-OS-MON-MIB.mib 6. Reloaded the agent This fixed the error, but exposed another possible bug. If otp-mib is not loaded into the agent, then the snmpwalk causes this error below. This is reproducible. I would think that if otp-mib was absent, the agent would at least show that a required dependency was not loaded and not crash. *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT LOG *** apply: os_mon_mib,disk_table,[get_next,[],[0]] *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT INFO *** Call to: Module: os_mon_mib Function: disk_table Args: [get_next,[],[0]] resulted in an exit {{badmatch,false}, [{snmp_generic,table_info,1}, {snmp_generic_mnesia,table_func,4}, {os_mon_mib,update_disk_table,0}, {snmp_shadow_table,update,3}, {snmp_shadow_table,table_func,4}, {snmpa_agent,dbg_apply,3}, {snmpa_agent,get_next_values_all_rows,6}, {snmpa_agent,get_next_table,4}]} =ERROR REPORT==== 28-May-2008::18:07:30 === ** User error: Invalid return value {'EXIT',{{badmatch,false},[{snmp_generic,table_info,1},{snmp_generic_mnesia,table_func,4},{os_mon_mib,update_disk_table,0},{snmp_shadow_table,update,3},{snmp_shadow_table,table_func,4},{snmpa_agent,dbg_apply,3},{snmpa_agent,get_next_values_all_rows,6},{snmpa_agent,get_next_table,4}]}} from {os_mon_mib,disk_table,[]} (get_next) -------------------------------------- ---------------------- $ diff -U 0 OTP-OS-MON-MIB.mib.buggy OTP-OS-MON-MIB.mib --- OTP-OS-MON-MIB.mib.buggy 2008-05-06 10:02:27.000000000 -0400 +++ OTP-OS-MON-MIB.mib 2008-05-28 17:28:42.000000000 -0400 @@ -14,0 +15,2 @@ + CounterBasedGauge64 + FROM HCNUM-TC @@ -111,2 +113,2 @@ - loadSystemTotalMemory Gauge32, - loadSystemUsedMemory Gauge32, + loadSystemTotalMemory CounterBasedGauge64, + loadSystemUsedMemory CounterBasedGauge64, @@ -114 +116 @@ - loadLargestErlProcessUsedMemory Gauge32, + loadLargestErlProcessUsedMemory CounterBasedGauge64, @@ -129 +131 @@ - SYNTAX Gauge32 + SYNTAX CounterBasedGauge64 @@ -138 +140 @@ - SYNTAX Gauge32 + SYNTAX CounterBasedGauge64 @@ -156 +158 @@ - SYNTAX Gauge32 + SYNTAX CounterBasedGauge64 @@ -283,4 +285,4 @@ - GROUP loadAlarmsGroup - DESCRIPTION - "This group is optional for systems implementing the - load supervison functionality." + --GROUP loadAlarmsGroup + --DESCRIPTION + -- "This group is optional for systems implementing the + -- load supervison functionality." @@ -291,4 +293,4 @@ - GROUP diskAlarmsGroup - DESCRIPTION - "This group is optional for systems implementing the - disk supervison functionality." + --GROUP diskAlarmsGroup + --DESCRIPTION + -- "This group is optional for systems implementing the + -- disk supervison functionality." -------------------------------------------- *The less serious bug *Maybe this is not a bug, but two groups are referenced that do not exist in OTP-OS-MON-MIB.mib: GROUP loadAlarmsGroup GROUP diskAlarmsGroup This causes snmpwalk to emit error messages. Commenting out the above lines seemed to have no effect other than stopping the snmpwalk error messages. Regards, Edwin Fine -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Thu May 29 04:10:00 2008 From: nem@REDACTED (Geoff Cant) Date: Thu, 29 May 2008 14:10:00 +1200 Subject: [erlang-bugs] Bus Error on Mac OS X 10.5.3 (R12B-2+hipe) Message-ID: Hi all, I just upgraded to mac os x 10.5.3 and all of a sudden all invocations of beam end immediately with a bus error. An example crash report is: Process: beam.smp [1134] Path: /Library/DarwinPorts/lib/erlang/erts-5.6.2/bin/beam.smp Identifier: beam.smp Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [382] Date/Time: 2008-05-29 11:55:25.772 +1200 OS Version: Mac OS X 10.5.3 (9D34) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000092665000 Crashed Thread: 0 Thread 0 Crashed: 0 beam.smp 0x0011a8a6 atomic_mov64 + 22 1 beam.smp 0x0011ae26 mach_override_ptr + 566 2 beam.smp 0x0011a0d4 hipe_signal_init + 164 3 beam.smp 0x000180d3 early_init + 617 4 beam.smp 0x000181c0 erl_start + 68 5 beam.smp 0x00001838 main + 24 6 beam.smp 0x000017e6 start + 54 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x56e58955 ebx: 0x99a001e9 ecx: 0x20ec836c edx: 0x20ec8353 edi: 0x00000000 esi: 0x92664ffa ebp: 0xbfffec08 esp: 0xbfffebf4 ss: 0x0000001f efl: 0x00010293 eip: 0x0011a8a6 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x92665000 Binary Images: 0x1000 - 0x14fff3 +beam.smp ??? (???) <31d88f4f6a8c9c57e4c9e0ade2481620> /Library/DarwinPorts/lib/erlang/erts-5.6.2/bin/beam.smp 0x1f7000 - 0x1f9fff libutil.dylib ??? (???) <5ac8a5517aae408d0fdb6da13a2faf89> /usr/lib/libutil.dylib 0x1fe000 - 0x229ff7 +libncurses.5.dylib ??? (???) /Library/DarwinPorts/lib/libncurses.5.dylib 0x8fe00000 - 0x8fe2da53 dyld 96.2 (???) <7af47d3b00b2268947563c7fa8c59a07> /usr/lib/dyld 0x90520000 - 0x90524fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x91170000 - 0x91177fe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x92625000 - 0x92785ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib As near as I can make out, this means that hipe_signal_init is trying to patch sigaction but mach_override_ptr is failing. Maybe this is some new page protection or something in macos? Rebuilding erlang r12b2 without hipe appears to avoid the problem. Also, gcc is complaining that we should be using dlopen/dlsym/dl... instead of NSCreateObjectFileImageFromFile and friends. Perhaps the macos specific calls to the Mach-O loader functions are no longer necessary. Cheers, -- Geoff Cant From hans.bolinder@REDACTED Thu May 29 09:06:54 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 29 May 2008 09:06:54 +0200 Subject: [erlang-bugs] Sum small floats and get erroneous result in R12B-2 In-Reply-To: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> References: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> Message-ID: <18494.22030.843744.50472@gargle.gargle.HOWL> [Badlop:] > 2> 20.15 + 2.01. > 22.159999999999997 [...] > But the results of 2 [...] look strange. The floats representing 20.15 and 2.01 are not exactly equal to 20.15 and 2.01 respectively. The sum is some other float than the one representing 22.16. Floats are printed accurately as the shortest, correctly rounded string. This is a new feature in R12B-2; io(3) erroneously states that the default g format is used, but that will be corrected in R12B-3. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From vitaly_barinov@REDACTED Thu May 29 19:29:46 2008 From: vitaly_barinov@REDACTED (Vitaly Barinov) Date: Thu, 29 May 2008 17:29:46 +0000 Subject: [erlang-bugs] io:format() call makes emulator hang Message-ID: I have discovered very annoying problem (which I would dare call a bug), present in R12B and several earlier releases on Windows:An attempt to output large enough string makes Erlang hang. %sample program -module( io_test ).-compile( export_all ).test()-> io:format( "~p~n", [lists:seq(1, 100000)] ). % Instead of list, it can be large enough binary etc.I've looked into source code with my right eye and my guess is that it is related to incorrect error handling in sys.c when using WriteFile() for overlapped I/O. What is especially unpleasant is that since output is internally done asynchronously, Erlang hangs not immediately but after some delay, while doing something different, so it took me some time to grasp the root cause. Is there any work-around for this? Vitaly _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Thu May 29 21:56:41 2008 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 29 May 2008 14:56:41 -0500 Subject: [erlang-bugs] io:format() call makes emulator hang In-Reply-To: Message of "Thu, 29 May 2008 17:29:46 -0000." Message-ID: <60481.1212091001@snookles.snookles.com> Vitaly Barinov wrote: vb> I have discovered very annoying problem (which I would dare call a vb> bug), present in R12B and several earlier releases on Windows: An vb> attempt to output large enough string makes Erlang hang. We've encountered this same problem with real/production data, not just test data that lists:seq(1, 100000) generates. In our case, it's been very large binaries (multi-megabyte) with non-printable bytes in them, so each byte is formatted as decimal numbers. An example of lists:seq(255, 100000) would consume even more memory. :-) At the moment, all I'm aware of is the same solution as the "Doctor, it hurts when I do this" problem. In our case, we combed through our custom error handler and either use "~P" formatting to limit formatting depth, or use size(term_to_binary(SuspiciousTerm)) to figure out if formatting is even worthwhile: term_to_binary() consumes RAM also, but not nearly as much as io:format or io_lib:format will. I agree with the VM's runtime policy of crashing when it can't allocate memory from the OS ... but it is quite surprising (and can be difficult to fix) when that same crash robs you of the VM's diagnostic tools. Any thoughts from The OTP Folks? -Scott