From kenji.rikitake@REDACTED Sat Nov 1 01:42:28 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sat, 1 Nov 2008 09:42:28 +0900 Subject: [erlang-bugs] Revised version: Re: leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: <9B23E0C2-40EB-4ED5-A8F4-578A332BD4D3@kallisys.net> References: <9B23E0C2-40EB-4ED5-A8F4-578A332BD4D3@kallisys.net> Message-ID: <20081101004228.GA48406@k2r.org> Paul (and the erlang-bugs list): I had found the similar one (as I remember), but the {{1969,12,31}...} part of calendar:local_time_to_universal_time_dst/1 looks quite strange to me. I cannot test the code since my 7.0R system is TAI-based (zoneinfo compiled with LEAPSECOND flag). How did you compile the program? Mine is with the port (/usr/ports/lang/erlang), with stock gcc-4.2.1 and HiPE disabled. (I experienced a loading error of BEAM files so I disabled the HiPE.) Also I suggest you to test erlang:localtime_to_universaltime/1 and erlang:universaltime_to_localtime/1 for whether they provide symmetric results. Regards, Kenji Rikitake In the message <9B23E0C2-40EB-4ED5-A8F4-578A332BD4D3@REDACTED> dated Fri, Oct 31, 2008 at 06:51:52PM +0100, Paul Guyot writes: > I have just noticed that httpd_util:rfc1123_date/1 does not work at > all on FreeBSD 7.0 with erlang R12B4 unpatched. > > 1> httpd_util:rfc1123_date({{2008, 10, 31}, {18, 47, 0}}). > ** 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 > in call from httpd_util:rfc1123_date/1 > > Is it a symtom of the bug you fixed? > > Paul From pguyot@REDACTED Sat Nov 1 07:07:59 2008 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 1 Nov 2008 07:07:59 +0100 Subject: [erlang-bugs] Revised version: Re: leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: <20081101004228.GA48406@k2r.org> References: <9B23E0C2-40EB-4ED5-A8F4-578A332BD4D3@kallisys.net> <20081101004228.GA48406@k2r.org> Message-ID: <13741300-DBB9-4403-9C9F-2F289526EBFC@kallisys.net> Le 1 nov. 08 ? 01:42, Kenji Rikitake a ?crit : > Paul (and the erlang-bugs list): > > I had found the similar one (as I remember), > but the {{1969,12,31}...} part of > calendar:local_time_to_universal_time_dst/1 > looks quite strange to me. > I cannot test the code since my 7.0R system > is TAI-based (zoneinfo compiled with LEAPSECOND flag). > > How did you compile the program? > Mine is with the port (/usr/ports/lang/erlang), > with stock gcc-4.2.1 and HiPE disabled. > (I experienced a loading error of BEAM files > so I disabled the HiPE.) > > Also I suggest you to test > erlang:localtime_to_universaltime/1 > and > erlang:universaltime_to_localtime/1 > for whether they provide symmetric results. I looked at the problem further, and the crash I have is definitely not related to Erlang's lack of support for leap seconds. Paul From pguyot@REDACTED Sat Nov 1 07:50:22 2008 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 1 Nov 2008 07:50:22 +0100 Subject: [erlang-bugs] Bug: local_to_univ does not handle -1 result from mktime (with patch) Message-ID: <23B2C08A-4A52-482E-96D1-27189F0A8C19@kallisys.net> Hello, I found a bug in Erlang/OTP R12B-4 that occurs on FreeBSD 7.0 with TZ set to UTC. On such systems, mktime(3) returns -1 when is_dst is set to true. According to SUSv3, the OS can return -1 when the time since Epoch cannot be represented, and therefore FreeBSD is perfectly allowed to do so. http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html In other words, erlang:localtime_to_universaltime/2 may return {{1969, 12, 31}, {23, 59, 59}} (-1) whenever the (DateTime, IsDST) combination is invalid (DateTime is invalid or IsDST is true and there is no valid DST representation for the given DateTime). This function is called by calendar:local_time_to_universal_time_dst/1 which unexpectedly fails. FreeBSD 7.0 with TZ set to UTC: 1> calendar:local_time_to_universal_time_dst({{2008, 8, 1}, {0, 0, 0}}). ** 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 FreeBSD 7.0 with TZ set to Asia/Tokyo: 1> calendar:local_time_to_universal_time_dst({{2008, 8, 1}, {0, 0, 0}}). [{{2008,7,31},{15,0,0}}] The problem does not occur on MacOS X 10.5, with TZ set to UTC: 1> calendar:local_time_to_universal_time_dst({{2008, 8, 1}, {0, 0, 0}}). [{{2008,8,1},{0,0,0}}] The attached patch fixes the bug by modifying local_to_univ, so it returns 0 when mktime returns -1. As a consequence, erlang:localtime_to_universaltime/2 no longer returns {{1969, 12, 31}, {23, 59, 59}} but raises {error, badarg} instead. The patch also modifies calendar:local_time_to_universal_time_dst/1, so it handles the badarg exception thrown by erlang:localtime_to_universaltime/2. If an exception is thrown, calendar:local_time_to_universal_time_dst/1 returns []. I chose to do so because it already is what is returned if the provided date is invalid (a local time during a period that cannot happen because of DST change). Finally, I suggest to document the fact that badarg error can be raised if the Date, Time and IsDst combination is invalid : - Failure: badarg if Date1 or Time1 do not denote a valid date or time. + Failure: badarg if Date1, Time1 and IsDst do not denote a valid date or time. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_mktime.diff Type: application/octet-stream Size: 1506 bytes Desc: not available URL: -------------- next part -------------- From kenji.rikitake@REDACTED Sat Nov 1 13:56:14 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sat, 1 Nov 2008 21:56:14 +0900 Subject: [erlang-bugs] Bug: local_to_univ does not handle -1 result from mktime (with patch) In-Reply-To: <23B2C08A-4A52-482E-96D1-27189F0A8C19@kallisys.net> References: <23B2C08A-4A52-482E-96D1-27189F0A8C19@kallisys.net> Message-ID: <20081101125614.GA55974@k2r.org> Confirmed the following bug behavior on FreeBSD 6.3-RELEASE too. See FreeBSD /usr/src/lib/libc/stdtime/localtime.c for the details. (mktime() and time1()) FYI Kenji Rikitake In the message <23B2C08A-4A52-482E-96D1-27189F0A8C19@REDACTED> dated Sat, Nov 01, 2008 at 07:49:59AM +0100, Paul Guyot writes: > Hello, > > I found a bug in Erlang/OTP R12B-4 that occurs on FreeBSD 7.0 with TZ > set to UTC. On such systems, mktime(3) returns -1 when is_dst is set > to true. According to SUSv3, the OS can return -1 when the time since > Epoch cannot be represented, and therefore FreeBSD is perfectly > allowed to do so. > > http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html > > In other words, erlang:localtime_to_universaltime/2 may return {{1969, > 12, 31}, {23, 59, 59}} (-1) whenever the (DateTime, IsDST) combination > is invalid (DateTime is invalid or IsDST is true and there is no valid > DST representation for the given DateTime). This function is called by > calendar:local_time_to_universal_time_dst/1 which unexpectedly fails. > > FreeBSD 7.0 with TZ set to UTC: > 1> calendar:local_time_to_universal_time_dst({{2008, 8, 1}, {0, 0, 0}}). > ** 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 [rest deleted] From n39052@REDACTED Wed Nov 5 00:19:20 2008 From: n39052@REDACTED (Sergey A.) Date: Tue, 4 Nov 2008 15:19:20 -0800 Subject: [erlang-bugs] Some bugs in "OTP Design Principles" article Message-ID: <3bff71aa0811041519k45ccf1e4k69e4471ad89dfc41@mail.gmail.com> Hello. When I was reading "OTP Design Principles", I found two small bugs (in fact, both are very trifling). #1. See the source of the module file_logger, introduced in paragraph "4.2 Example". I think that file in fun init/1 should be open with "write" attribute instead of "read" one. #2. It's just a misprint in "4.4 Adding an Event Handler". "state fo the event handler." -> "state for the event handler." (letter "r" of "for" is missed) From n39052@REDACTED Wed Nov 5 00:41:25 2008 From: n39052@REDACTED (Sergey A.) Date: Tue, 4 Nov 2008 15:41:25 -0800 Subject: [erlang-bugs] Some bugs in "OTP Design Principles" article In-Reply-To: <3bff71aa0811041519k45ccf1e4k69e4471ad89dfc41@mail.gmail.com> References: <3bff71aa0811041519k45ccf1e4k69e4471ad89dfc41@mail.gmail.com> Message-ID: <3bff71aa0811041541vd5ef78ck81ed9a94634723fc@mail.gmail.com> Hello. I've found yet another misprint in "OTP Design Principles": #3. "5.5 Child Specification" contains service html sequence (>), representing "greater" symbol: "integer() >=0 | infinity" I'm not sure this list is the right place for those "bugs". if this is the case, please let me know. -- Sergey. From matt.handler@REDACTED Thu Nov 6 02:59:06 2008 From: matt.handler@REDACTED (Matt Handler) Date: Wed, 5 Nov 2008 20:59:06 -0500 Subject: [erlang-bugs] try..catch unsafe variable Message-ID: <49427c610811051759s3a5e0dddu7e63c73ac6bbd42d@mail.gmail.com> using R12B-2 i've been staring at this but I can't figure out what is wrong with it: test() -> try expression of Val -> Reply = value catch _:_ -> Reply = exception end, {ok, Reply, state}. test2() -> Reply = try expression catch _:_ -> exception end, {ok, Reply, state}. test() gives a compile error: "...variable 'Reply' unsafe in 'try' (line ..." test2() does not. can anyone clear this up for me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Nov 6 06:51:20 2008 From: vances@REDACTED (Vance Shipley) Date: Thu, 6 Nov 2008 06:51:20 +0100 Subject: [erlang-bugs] try..catch unsafe variable In-Reply-To: <49427c610811051759s3a5e0dddu7e63c73ac6bbd42d@mail.gmail.com> References: <49427c610811051759s3a5e0dddu7e63c73ac6bbd42d@mail.gmail.com> Message-ID: <20081106055119.GD185@aluminum.local> Matt, http://www.erlang.org/doc/reference_manual/expressions.html#6.3: "For the try expression introduced in Erlang 5.4/OTP-R10B, variable scoping is limited so that variables bound in the expression are always 'unsafe' outside the expression. This will be improved." -Vance On Wed, Nov 05, 2008 at 08:59:06PM -0500, Matt Handler wrote: } try expression of } Val -> Reply = value } catch } _:_ -> Reply = exception } end, } {ok, Reply, state}. From raimo+erlang-bugs@REDACTED Thu Nov 6 12:28:51 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 6 Nov 2008 12:28:51 +0100 Subject: [erlang-bugs] try..catch unsafe variable In-Reply-To: <49427c610811051759s3a5e0dddu7e63c73ac6bbd42d@mail.gmail.com> References: <49427c610811051759s3a5e0dddu7e63c73ac6bbd42d@mail.gmail.com> Message-ID: <20081106112851.GB3853@erix.ericsson.se> On Wed, Nov 05, 2008 at 08:59:06PM -0500, Matt Handler wrote: > using R12B-2 > > > i've been staring at this but I can't figure out what is wrong with it: > > test() -> > try expression of > Val -> Reply = value > catch > _:_ -> Reply = exception > end, > {ok, Reply, state}. > > test2() -> > Reply = try expression > catch > _:_ -> exception > end, > {ok, Reply, state}. > > test() gives a compile error: "...variable 'Reply' unsafe in 'try' (line > ..." > test2() does not. can anyone clear this up for me? You are thinking right. But when try..catch was implemented it firstly became very messy in the compiler to export variables from the try..end block, plus it by many is regarded as cleaner to use the returned value making it explicit what is used in the outer block. Your problem gets rather messy in the general case. try A = a() of _ -> B = A catch _:_ -> B = b() after C = B end, {B,C} Note that A is unsafe in the catch block since the execution might have jumped from anywhere in the try block. B would be valid in the after block and after the end if it is exported from all try and catch clauses. And C would always be valid after the end. The feature to export from the after block would be the most desirable since there is no way today to get a value out other than sending to yourself or storing in Ets or the process dictionary. To complicate the matter a bit more - the after feature is today implemented using nested try..catch..end blocks, so to get export from after..end to work, some more complicated export probably will have to work first. Anyway, when try..end was implemented it was postponed to tidy up these consequenses. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From pfisher@REDACTED Thu Nov 6 15:20:08 2008 From: pfisher@REDACTED (Paul Fisher) Date: Thu, 06 Nov 2008 08:20:08 -0600 Subject: [erlang-bugs] embedded pcre vs linked-in drivers Message-ID: <4912FD18.7020605@alertlogic.net> We have run into an issue with the embedded pcre and linked-in drivers that use the libpcre.so. Apparently the embedded version of pcre changes the size of the pcre_extra structure, uses those extra fields in pcre_exec.c AND continues to use the same pcre_xxxx function entry point names. (All protected by ERLANG_INTEGRATION #define.) When loaded the linked-in drivers bind to the pcre_xxxx functions provided by vm executable, and because the code of the linked-in driver was built with the system headers (without the extra fields in the pcre_extra structure) the pcre_xxxx functions proceed to step over storage that was not intended for them. Corruption ensues. I believe that one of two things needs to happen: 1) change pcre_xxxx entry points to erl_pcre_xxx (or something), therefore not conflicting with the system pcre linked-in drivers may depend on. 2) provided the functionality for these fields outside of the pcre_xxxx code in order to allow their use by linked-in drivers. -- paul From mikpe@REDACTED Fri Nov 7 22:07:36 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 7 Nov 2008 22:07:36 +0100 Subject: [erlang-bugs] R12B-5 odbc build failure on MacOSX 10.3 Message-ID: <18708.44568.316127.120688@harpo.it.uu.se> gcc -g -O2 -I. -I/usr/lib/include -I/home/mikpe/macosx/otp_src_R12B-5/lib/erl_interface/include -DUNIX -o ../priv/obj/powerpc-apple-darwin7.9.0/odbcserver.o -c odbcserver.c In file included from odbcserver.c:122: odbcserver.h:124: error: expected specifier-qualifier-list before 'SQLLEN' odbcserver.c: In function 'db_select_count': odbcserver.c:619: error: 'SQLLEN' undeclared (first use in this function) odbcserver.c:619: error: (Each undeclared identifier is reported only once odbcserver.c:619: error: for each function it appears in.) odbcserver.c:619: error: expected ';' before 'num_of_rows' odbcserver.c:656: error: 'num_of_rows' undeclared (first use in this function) odbcserver.c: In function 'db_describe_table': odbcserver.c:850: error: 'SQLLEN' undeclared (first use in this function) odbcserver.c:850: error: expected ';' before 'size' odbcserver.c:891: error: 'size' undeclared (first use in this function) odbcserver.c: In function 'encode_result': odbcserver.c:976: error: 'SQLLEN' undeclared (first use in this function) odbcserver.c:976: error: expected ';' before 'RowCountPtr' odbcserver.c:999: error: 'RowCountPtr' undeclared (first use in this function) odbcserver.c: In function 'encode_out_params': odbcserver.c:1083: error: 'col_type' has no member named 'len' odbcserver.c:1084: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:1090: error: 'col_type' has no member named 'len' odbcserver.c: In function 'encode_column_name_list': odbcserver.c:1157: error: 'SQLLEN' undeclared (first use in this function) odbcserver.c:1157: error: expected ';' before 'size' odbcserver.c:1169: error: 'size' undeclared (first use in this function) odbcserver.c:1184: error: 'col_type' has no member named 'len' odbcserver.c:1186: error: 'col_type' has no member named 'len' odbcserver.c:1197: error: 'col_type' has no member named 'len' odbcserver.c:1198: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:1205: error: 'col_type' has no member named 'len' odbcserver.c: In function 'encode_column_dyn': odbcserver.c:1347: error: 'col_type' has no member named 'len' odbcserver.c:1348: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c: In function 'decode_params': odbcserver.c:1497: error: 'col_type' has no member named 'len' odbcserver.c:1498: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c: In function 'connect_to_erlang': odbcserver.c:1625: error: storage size of 'sin' isn't known odbcserver.c: In function 'free_params': odbcserver.c:1887: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c:1888: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c: In function 'init_param_column': odbcserver.c:1969: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:1970: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c:1977: error: 'col_type' has no member named 'len' odbcserver.c:1980: error: 'col_type' has no member named 'len' odbcserver.c:1985: error: 'col_type' has no member named 'len' odbcserver.c:1988: error: 'col_type' has no member named 'len' odbcserver.c:1993: error: 'col_type' has no member named 'len' odbcserver.c:1996: error: 'col_type' has no member named 'len' odbcserver.c:2010: error: 'col_type' has no member named 'len' odbcserver.c:2013: error: 'col_type' has no member named 'len' odbcserver.c:2015: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c:2016: error: 'SQLLEN' undeclared (first use in this function) odbcserver.c:2016: error: expected expression before ')' token odbcserver.c:2019: error: 'col_type' has no member named 'len' odbcserver.c:2031: error: 'col_type' has no member named 'len' odbcserver.c:2034: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c:2035: error: expected expression before ')' token odbcserver.c:2038: error: 'col_type' has no member named 'len' odbcserver.c:2044: error: 'col_type' has no member named 'len' odbcserver.c:2048: error: 'col_type' has no member named 'len' odbcserver.c:2053: error: 'col_type' has no member named 'len' odbcserver.c:2056: error: 'col_type' has no member named 'len' odbcserver.c:2061: error: 'col_type' has no member named 'len' odbcserver.c:2064: error: 'col_type' has no member named 'len' odbcserver.c:2069: error: 'col_type' has no member named 'len' odbcserver.c:2070: error: 'col_type' has no member named 'len' odbcserver.c:2072: error: 'col_type' has no member named 'len' odbcserver.c: In function 'map_dec_num_2_c_column': odbcserver.c:2148: error: 'col_type' has no member named 'len' odbcserver.c:2151: error: 'col_type' has no member named 'len' odbcserver.c:2155: error: 'col_type' has no member named 'len' odbcserver.c:2158: error: 'col_type' has no member named 'len' odbcserver.c: In function 'map_sql_2_c_column': odbcserver.c:2178: error: 'col_type' has no member named 'len' odbcserver.c:2182: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2188: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2193: error: 'col_type' has no member named 'len' odbcserver.c:2195: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2200: error: 'col_type' has no member named 'len' odbcserver.c:2202: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2207: error: 'col_type' has no member named 'len' odbcserver.c:2210: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2213: error: 'col_type' has no member named 'len' odbcserver.c:2215: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2218: error: 'col_type' has no member named 'len' odbcserver.c:2220: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c: In function 'bind_parameter_arrays': odbcserver.c:2284: error: 'col_type' has no member named 'len' odbcserver.c:2285: error: 'col_type' has no member named 'strlen_or_indptr_array' odbcserver.c: In function 'retrive_binary_data': odbcserver.c:2325: error: 'col_type' has no member named 'len' odbcserver.c:2329: error: 'col_type' has no member named 'strlen_or_indptr' odbcserver.c:2336: error: 'col_type' has no member named 'len' odbcserver.c:2337: error: 'col_type' has no member named 'len' odbcserver.c:2339: error: 'col_type' has no member named 'len' odbcserver.c:2344: error: 'col_type' has no member named 'strlen_or_indptr' make[4]: *** [../priv/obj/powerpc-apple-darwin7.9.0/odbcserver.o] Error 1 make[4]: Leaving directory `/Users/mikpeadm/otp_src_R12B-5/lib/odbc/c_src' make[3]: *** [opt] Error 2 make[3]: Leaving directory `/Users/mikpeadm/otp_src_R12B-5/lib/odbc/c_src' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/Users/mikpeadm/otp_src_R12B-5/lib/odbc' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/Users/mikpeadm/otp_src_R12B-5/lib' make: *** [libs] Error 2 I don't really care if it builds odbc or not, but if it can't build it ./configure should create a SKIP file there so the entire build doesn't break. From nexes300@REDACTED Mon Nov 10 16:17:45 2008 From: nexes300@REDACTED (Charles Ahn) Date: Mon, 10 Nov 2008 07:17:45 -0800 Subject: [erlang-bugs] Bugs in SSH Message-ID: <7A60401C-7844-4E4C-9284-8EE0FAB6AEF0@gmail.com> Hello, The ssh daemon will not function correctly (logging in fails) with only ssh_host_rsa_key and ssh_host_rsa_key.pub in system_dir. However, ssh_host_dsa_key and ssh_host_dsa_key.pub are sufficient by themselves for the ssh daemon to function correctly. This means that the ssh daemon does start if both keys exist but there seems to be no way to force the daemon to use the RSA keys. Also, I have some code using the daemon in which two users connecting to the server (different logins), cause the server to close all open connections. (Ie, logging in as admin and root, and having admin type quit will close both connections). I wouldn't be surprised if this is because I am doing something wrong though: -module(ssh_example). -export([start/0, dispatch/0, dispatch_init/0, recv_loop/1]). -include("ssh_example.hrl"). start() -> crypto:start(), ssh:start(), ssh:daemon({0,0,0,0}, 1122, [{shell, {?MODULE, dispatch, []}}, {user_passwords, [{"admin", "admin"}, {"root", "admin"}]}, {system_dir, "/erlang_test"}]). dispatch() -> spawn(?MODULE, dispatch_init, []). dispatch_init() -> io:format("Hello user!\n"), Rec = spawn_link(?MODULE, recv_loop, [self()]), loop(Rec). loop(Rec) -> receive {Rec, Line} -> io:format("~s~s",[?FG_GREEN, Line]) end, case Line of "quit\n" -> io:format("Good bye!\n"), exit(Rec, ok); _ -> loop(Rec) end. recv_loop(Dispatcher) -> Prompt = "> ", Line = io:get_line(?RESET ++ Prompt), Dispatcher ! {self(), Line}, ?MODULE:recv_loop(Dispatcher). Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: From bgustavsson@REDACTED Mon Nov 10 16:21:49 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Mon, 10 Nov 2008 16:21:49 +0100 Subject: [erlang-bugs] [Doc/Code] Misspelled atom in pool:attach/1 In-Reply-To: <6672d0160810160112n1514f234u79e11058d61c854c@mail.gmail.com> References: <6c2563b20810122139i5c432808u8ba84845430ac0ee@mail.gmail.com> <6672d0160810160112n1514f234u79e11058d61c854c@mail.gmail.com> Message-ID: <6672d0160811100721o22973cc0xf8913fba4ce4b337@mail.gmail.com> On Thu, Oct 16, 2008 at 9:12 AM, Bjorn Gustavsson wrote: > 2008/10/13 Edwin Fine >> >> pool:attach/1 returns either 'attached' or 'allready_attached'; >> 'allready_attached' should be spelled 'already_attached'. It is misspelled >> in the doc too. At least the code and the documentation agree :) > > Thanks for pointing this out. We will correct the misspelling in both the > code and the documentation in R12B-5. > Unfortunately I made a mistake so that only the correction in the documentation (not in pool.erl) was included in R12B-5. The correction in pool.erl will be included in the next release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n39052@REDACTED Mon Nov 10 16:41:49 2008 From: n39052@REDACTED (Sergey A.) Date: Mon, 10 Nov 2008 07:41:49 -0800 Subject: [erlang-bugs] The best way to write user-friendly log from an OTP application Message-ID: <3bff71aa0811100741v6f165521u26f16ed237b82799@mail.gmail.com> Hello. I'm looking for the best way to write a plain text log containing the reasons of some well-known errors happening in my OTP applications. The log should be like this: --------------------------------8<-------------------------------- [2008-11-6 23:0:53] Such an ip and port already in use. [2008-11-6 23:1:45] Login or password is wrong --------------------------------8<-------------------------------- Here is what I'm doing just now to achieve this behaviour: I use a gen_event module connected to the error_logger as a handler to catch all the errors (and it is where I write my log). But there are two mutually exclusive ways to denote that error has happened: 1) Do nothing. Just let the crash happen. A process will crash and you'll get a huuuuge message in your gen_event handler: {error, _, {_, _, [_, {_, _, {pg_error, [_, {code, "28000"}, {message, Message}, _, _, _]}}, _, _, authentication_error]}} all's OK, but working with messages like this is somewhat weary. 2) Decide the point where an error happen, and then call: error_logger:error_msg({my_error, Reason}) In this case, the message to catch in gen_event module will be like this: {error, _, {_, {my_error, Reason}, _}} [+] That message is much more easy to operate. [-] You need to call fun error_logger:error_msg/1 by hand (which sometimes can involve some tricky code) Is there any other way to catch errors in a centralised manner? What of the ways listed above is the best in your opinon and why? -- Sergey. From nexes300@REDACTED Mon Nov 10 12:51:47 2008 From: nexes300@REDACTED (Charles Ahn) Date: Mon, 10 Nov 2008 03:51:47 -0800 Subject: [erlang-bugs] Bugs in SSH Message-ID: <0FB2F25C-2D34-4C00-9F1C-A930C68F0AC2@gmail.com> Hello, The ssh daemon will not function correctly (logging in fails) with only ssh_host_rsa_key and ssh_host_rsa_key.pub in system_dir. However, ssh_host_dsa_key and ssh_host_dsa_key.pub are sufficient by themselves for the ssh daemon to function correctly. This means that the ssh daemon does start if both keys exist but there seems to be no way to force the daemon to use the RSA keys. Also, I have some code using the daemon in which two users connecting to the server (different logins), cause the server to close all open connections. (Ie, logging in as admin and root, and having admin type quit will close both connections). I wouldn't be surprised if this is because I am doing something wrong though: -module(ssh_example). -export([start/0, dispatch/0, dispatch_init/0, recv_loop/1]). -include("ssh_example.hrl"). start() -> crypto:start(), ssh:start(), ssh:daemon({0,0,0,0}, 1122, [{shell, {?MODULE, dispatch, []}}, {user_passwords, [{"admin", "admin"}, {"root", "admin"}]}, {system_dir, "/erlang_test"}]). dispatch() -> spawn(?MODULE, dispatch_init, []). dispatch_init() -> io:format("Hello user!\n"), Rec = spawn_link(?MODULE, recv_loop, [self()]), loop(Rec). loop(Rec) -> receive {Rec, Line} -> io:format("~s~s",[?FG_GREEN, Line]) end, case Line of "quit\n" -> io:format("Good bye!\n"), exit(Rec, ok); _ -> loop(Rec) end. recv_loop(Dispatcher) -> Prompt = "> ", Line = io:get_line(?RESET ++ Prompt), Dispatcher ! {self(), Line}, ?MODULE:recv_loop(Dispatcher). Charles -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: From ingela@REDACTED Wed Nov 12 08:21:24 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 12 Nov 2008 08:21:24 +0100 Subject: [erlang-bugs] [erlang-questions] Upgrading gen_tcp socket to ssl In-Reply-To: <4919E986.9040506@hyber.org> References: <49114933.5090405@erix.ericsson.se> <4919E986.9040506@hyber.org> Message-ID: <491A83F4.4010800@erix.ericsson.se> Hi! Claes Wikstrom wrote: > Ingela Anderton Andin wrote: > >> >> Ssl-3.10 will soon be out in R12B-5 and then the new ssl-implementation >> will be much more complete but still there are a few limitations left >> before it can completely replace the old ssl. You are welcome to try it >> and we are of course interested in any feedback that you might have. > > Tried to try out the new ssl implementation for Yaws. Seems as if > a server is required to specify the cacertfile. This should not > be necessary. Most ssl servers don't have a cacert, just a cert and > a key. cacert should be optional. > Thank you for the feedback, we will make it optional for the upcoming ssl-version. Regards Ingela Erlang/OTP - Ericsson [...] From n39052@REDACTED Thu Nov 13 01:39:23 2008 From: n39052@REDACTED (Sergey A.) Date: Wed, 12 Nov 2008 16:39:23 -0800 Subject: [erlang-bugs] A small bug in man for rb Message-ID: <3bff71aa0811121639n4676e750ndd2356783d1a74f3@mail.gmail.com> Hello. I think I've found something that wasn't mentioned in man for rb. The descripton of the rb:list(Type) function tells that Type must be one of the following atoms: type() = crash_report | supervisor_report | error | progress But in fact you also can use error_report atom as Type here (at least rb:list(error_report) works as expected). That is true for Erlang R12B.5. -- Sergey From oscar@REDACTED Tue Nov 18 18:00:46 2008 From: oscar@REDACTED (=?ISO-8859-1?Q?Oscar_Hellstr=F6m?=) Date: Tue, 18 Nov 2008 17:00:46 +0000 Subject: [erlang-bugs] port/1 undocumented in ssl module Message-ID: <4922F4BE.2050105@erlang-consulting.com> Hi, The documentation for listen/2 says that "If Port is zero, listen/2 picks an available port number (use port/1 to retreive it)" but port/1 doesn't exist in the documentation. ssl:module_info(exports) gives: [..., {port,1}, ...] What port/1 does, and how I should use it not really an issue for me, but I first thought there was no equivalence to the inet:port/1 function and had to read through listen/1 to find out that it really does exist. It could also have fooled me to believe that I need to use sockname/1 to find out which port I got. Best regards -- Oscar Hellstr?m, oscar@REDACTED Office: +44 20 7655 0337 Mobile: +44 798 45 44 773 Erlang Training and Consulting http://www.erlang-consulting.com/ From mthibaut@REDACTED Tue Nov 18 21:02:38 2008 From: mthibaut@REDACTED (Maarten Thibaut) Date: Tue, 18 Nov 2008 21:02:38 +0100 Subject: [erlang-bugs] DESTDIR installation breaks erlang scripts Message-ID: <70356FBF-219C-47AB-9FC5-F244C79EBE64@cisco.com> Hi, I have recently installed erlang R12B-5, and noticed several issues wrt INSTALL_PREFIX. The scripts that are installed and setup links to the actual binaries end up using INSTALL_PREFIX. For instance, I built using: ./configure --prefix=/opt/local make make install INSTALL_PREFIX=/home/mthibaut/compile/otp-install After this, lib/erlang/bin/erl (and several other ones) contains: ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang Obviously this should be: ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang In other words, ROOTDIR should be setup using $PREFIX, not $INSTALL_PREFIX. Is this a known bug? Thanks, maarten -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthibaut@REDACTED Wed Nov 19 00:49:02 2008 From: mthibaut@REDACTED (Maarten Thibaut) Date: Wed, 19 Nov 2008 00:49:02 +0100 Subject: [erlang-bugs] DESTDIR installation breaks erlang scripts In-Reply-To: <70356FBF-219C-47AB-9FC5-F244C79EBE64@cisco.com> References: <70356FBF-219C-47AB-9FC5-F244C79EBE64@cisco.com> Message-ID: <8DF21217-2EC1-4A24-ABE2-9A8570D14AA1@cisco.com> Hi, Typo: > After this, lib/erlang/bin/erl (and several other ones) contains: > > ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang > > Obviously this should be: > > ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang 2nd one should read: ROOTDIR=/opt/local/lib/erlang -- maarten -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfisher@REDACTED Wed Nov 19 15:01:25 2008 From: pfisher@REDACTED (Paul Fisher) Date: Wed, 19 Nov 2008 08:01:25 -0600 Subject: [erlang-bugs] 64-bit solaris build failures on R12B-5 Message-ID: <49241C35.5010503@alertlogic.net> I am attempting to build a 64-bit solaris version of the R12B-5 release using only the CC/LD/CFLAGS/LDFLAGS overrides as discussed on the list, and this is not working. I configure with the following: CC='gcc' LD='gcc' CFLAGS='-m64' LDFLAGS='-m64' LIBS='-lumem' ./configure --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --disable-megaco-flex-scanner-drvlineno I disable a bunch of stuff I do not want with: touch lib/common_test/SKIP touch lib/cosEvent/SKIP touch lib/cosEventDomain/SKIP touch lib/cosFileTransfer/SKIP touch lib/cosNotification/SKIP touch lib/cosProperty/SKIP touch lib/cosTime/SKIP touch lib/cosTransactions/SKIP touch lib/megaco/SKIP touch lib/odbc/SKIP touch lib/orber/SKIP I then run make, and eventually get: gcc -c -I/export/home/pfisher/bld/otp_src_R12B-5/erts/emulator/beam -I/export/home/pfisher/bld/otp_src_R12B-5/erts/emulator/sys/unix -I/export/home/pfisher/bld/otp_src_R12B-5/lib/erl_interface/include -m64 -I/export/home/pfisher/bld/otp_src_R12B-5/erts/i386-pc-solaris2.11 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -fPIC -o /export/home/pfisher/bld/otp_src_R12B-5/lib/asn1/priv/obj/i386-pc-solaris2.11/asn1_erl_drv.o asn1_erl_driver.c ld -G -L/export/home/pfisher/bld/otp_src_R12B-5/lib/erl_interface/obj/i386-pc-solaris2.11 -o /export/home/pfisher/bld/otp_src_R12B-5/lib/asn1/priv/lib/i386-pc-solaris2.11/asn1_erl_drv.so /export/home/pfisher/bld/otp_src_R12B-5/lib/asn1/priv/obj/i386-pc-solaris2.11/asn1_erl_drv.o -lei -lc -ldl -lm -lumem -lsocket -lnsl ld: skipping incompatible /export/home/pfisher/bld/otp_src_R12B-5/lib/erl_interface/obj/i386-pc-solaris2.11/libei.a when searching for -lei ld: cannot find -lei make[4]: *** [/export/home/pfisher/bld/otp_src_R12B-5/lib/asn1/priv/lib/i386-pc-solaris2.11/asn1_erl_drv.so] Error 1 Basically, libei.a was properly built as a 64-bit library, but the asn1 driver is not. If I disable asn1 and enable common_test, the same basic thing happens where the driver is built 32-bit. Is there something that I am missing, or did the work to make CFLAGS/LDFLAGS work not make it into R12B-5? -- paul From art_den@REDACTED Thu Nov 20 13:06:31 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Thu, 20 Nov 2008 15:06:31 +0300 Subject: [erlang-bugs] =?koi8-r?b?UHJvYmxlbXMgd2l0aCBTU0wgc3NsX2Vzb2NrLmV4?= =?koi8-r?b?ZSAoUjEyQi01IGFuZCBSMTJCLTQp?= Message-ID: I started to test erlang SSL library and find some unpleasant stuff: sometimes ssl_esock.exe starts to use 100% of CPU time on MS Windows. After some searching I found same problems in russian ejabberd forum. Researched a little, I found out that 100% load of CPU arises after uncorrect closing of SSL connection (when only socket connection is closed, not a SSL one). If to close SSL connection carefully, there is no any problem then. *** How to reproduce the problem *** The erlang program have to work as SSL server. The problem arise after to connect to server and to disconnect (uncorrectly). Erlang listing of server.erl: ================================================================== -module(server). -export([start/0]). start() -> application:start(ssl), ssl:seed("jhdnfkjernfeijkrnferkjn"), Options = [{active, true}, {verify, 2}, {mode, binary}, {depth, 2}, {cacertfile, "SnmpManagerProServ.pem"}, % My ssl keys and sertificates {certfile, "SnmpManagerProServ.pem"}, {keyfile, "SnmpManagerProServ-key.pem"}, {password, "1234567890"} ], {Res, LSock} = ssl:listen(8888, Options), io:fwrite("Res=~p~n", [Res]), accept(LSock) . accept(LSock) -> {ok, ASock} = ssl:transport_accept(LSock), io:fwrite("ssl:transport_accept, ASock=~p~n", [ASock]), AccRes = ssl:ssl_accept(ASock), io:fwrite("ssl:ssl_accept, AccRes=~p~n", [AccRes]), spawn(fun() -> accept(LSock) end), read(ASock). read(Sock) -> receive {ssl_closed, _} -> ssl:close(Sock); Data -> io:fwrite("Received=~p ~n", [Data]), read(Sock) end. ================================================================== To start server, just execute server:start() To connect to erlang SSL server, I used buildin OpenSSL s_client. To close SSL connection uncorrect, it is enough to connect and then press "Ctrl+C" in OpenSSL s_client window. Immediately ssl_esock.exe start to "eat" of 100% CPU. *** Simple solution *** I recompiled ssl_esock.exe with debug data, run it from debugger and saw that 100% cpu load happens in esock.c file. esock_poll_fd_isset_read(&pollfd, cp->fd) is alwais signaled that it is possible to read: else if (esock_poll_fd_isset_read(&pollfd, cp->fd)) { /* Read from SSL and write to proxy */ DEBUGF(("-----------------------------------\n")); DEBUGF(("JOINED: read from ssl fd = %d\n", cp->fd)); cc = esock_ssl_read(cp, rwbuf, RWBUFLEN); DEBUGF(("read from fd = %d, cc = %d\n", cp->fd, cc)); but esock_ssl_read reads nothing and returns -1. I insert simple condition to avoid it: else if (esock_poll_fd_isset_read(&pollfd, cp->fd)) { /* Read from SSL and write to proxy */ DEBUGF(("-----------------------------------\n")); DEBUGF(("JOINED: read from ssl fd = %d\n", cp->fd)); cc = esock_ssl_read(cp, rwbuf, RWBUFLEN); DEBUGF(("read from fd = %d, cc = %d\n", cp->fd, cc)); /* My solution */ if (cc < 0) { close_and_remove_connection(cp); } and it start to work fine for me (I know of cource this is treatment of symptoms, not of major problem) Hope developers will fix this bug soon. PS: Sorry for my bad English :) PPS: Win XP RUS SP2 or Win XP RUS SP3, OpenSSL 0.9.8i taken from http://www.slproweb.com/products/Win32OpenSSL.html , Erlang for MS Widnows R12B-5 or R12B-4 From john.hughes@REDACTED Thu Nov 20 16:36:08 2008 From: john.hughes@REDACTED (John Hughes) Date: Thu, 20 Nov 2008 16:36:08 +0100 Subject: [erlang-bugs] Control-C in werl References: Message-ID: Pressing control-C no longer interrupts execution in werl--it's just ignored. Is this intentional? (It's a bit of a nuisance). I'm using the Nov 5th R12B under Windows XP. John From huntermorris@REDACTED Thu Nov 20 19:26:17 2008 From: huntermorris@REDACTED (Hunter Morris) Date: Thu, 20 Nov 2008 18:26:17 +0000 Subject: [erlang-bugs] Compiler crash in compile:fold_comp/3 Message-ID: <87tza2dzjq.fsf@gmail.com> The following code (tested with R12B4 or R12B5, vanilla compiler options) produces a compiler crash. It's nonsensical, and I realise that andalso can be quite evil, but it's a crash nonetheless. -module(test). -export([foo/1]). foo(Bar) when is_integer(Bar) andalso Bar =:= 0; Bar =:= 1 -> ok. The crash looks like: Function foo/1 refers to undefined label 6 ./test.erl:none: internal error in beam_dead; crash reason: {{case_clause,{'EXIT',{undefined_label,6}}}, [{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}]} Best regards, ~Hunter Morris From bgustavsson@REDACTED Fri Nov 21 09:31:25 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 21 Nov 2008 09:31:25 +0100 Subject: [erlang-bugs] Compiler crash in compile:fold_comp/3 In-Reply-To: <87tza2dzjq.fsf@gmail.com> References: <87tza2dzjq.fsf@gmail.com> Message-ID: <6672d0160811210031i25d28af2s9a9f0088e2558489@mail.gmail.com> On Thu, Nov 20, 2008 at 7:26 PM, Hunter Morris wrote: > The following code (tested with R12B4 or R12B5, vanilla compiler > options) produces a compiler crash. It's nonsensical, and I realise > that andalso can be quite evil, but it's a crash nonetheless. Thanks for reporting this bug. I will investigate and correct the bug in the R13A release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kxynos@REDACTED Sun Nov 23 17:54:42 2008 From: kxynos@REDACTED (Xynos K (AT)) Date: Sun, 23 Nov 2008 16:54:42 -0000 Subject: [erlang-bugs] erlang documentation error Message-ID: <0BA7EE4D4646E0409D458D347C508B78013F9ACF@MAILSERV1.uni.glam.ac.uk> In the documentation 'Getting Started With Erlang' Version 5.6.5 at http://www.erlang.org/doc/getting_started/part_frame.html under the section 2.3 'Atoms' there is a mistake on the error message demonstration shell function v/1. The error on the function convert/2 occurs at line 12: 12> tut2:convert(3, miles). ** exception error: no function clause matching tut2:convert(3,miles) and the yet documentation points the shell function v/1 to line 13, instead of line 12 13> v(13) {'EXIT',{function_clause,[{tut2,convert,[3,miles]}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]}} therefore the argument to v/2 should be 12: 13> v(12) {'EXIT',{function_clause,[{tut2,convert,[3,miles]}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]}} Konstantinos Xynos ISRG Blog: http://isrg.weblog.glam.ac.uk Web Site: http://security.research.glam.ac.uk/people/kxynos -------------- next part -------------- An HTML attachment was scrubbed... URL: From pguyot@REDACTED Mon Nov 24 07:07:33 2008 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 24 Nov 2008 07:07:33 +0100 Subject: [erlang-bugs] jinterface 1.4.2 : OtpErlangRef missing hashCode method Message-ID: <564676F1-2773-4F7F-A7C4-FA81401C0F91@kallisys.net> Hello, OtpErlangRef class (and probably others) is missing the hashCode method, while it overrides the equal method. As a result, refs cannot be put in a hash structure (e.g. HashMap). final HashMap myMap = new HashMap(); myMap.put(ref1, obj1); assertNotNull(myMap.get(ref1)); // <-- fails The attached patch adds an implementation of hashCode for OtpErlangRef, which is compatible with the equal method. Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-lib_jinterface_java_src_com_ericsson_otp_erlang_OtpErlangRef.java.diff Type: application/octet-stream Size: 772 bytes Desc: not available URL: -------------- next part -------------- From hans.bolinder@REDACTED Mon Nov 24 13:05:51 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 24 Nov 2008 13:05:51 +0100 Subject: [erlang-bugs] erlang documentation error In-Reply-To: <0BA7EE4D4646E0409D458D347C508B78013F9ACF@MAILSERV1.uni.glam.ac.uk> References: <0BA7EE4D4646E0409D458D347C508B78013F9ACF@MAILSERV1.uni.glam.ac.uk> Message-ID: <18730.39071.334572.251676@ornendil.du.uab.ericsson.se> [Xynos K (AT):] > In the documentation 'Getting Started With Erlang' Version 5.6.5 at > http://www.erlang.org/doc/getting_started/part_frame.html under the > section 2.3 'Atoms' there is a mistake on the error message > demonstration shell function v/1. Thanks. It will be corrected in R13A. Best regards, Hans Bolinder, Erlang/OTP, Ericsson From nc@REDACTED Mon Nov 24 14:18:28 2008 From: nc@REDACTED (Nicolas Charpentier) Date: Mon, 24 Nov 2008 14:18:28 +0100 Subject: [erlang-bugs] SASL can't store events larger than 64k Message-ID: <492AA9A4.9060606@charpi.net> Hi, This bug is already known in R11B-5 (http://www.erlang.org/pipermail/erlang-patches/2007-August/000186.html) and still exist in R12B-5. The main problem this bug is that after a 'large event' the whole log file is corrupted. I propose you a patch, compatible with existing log files, which ensure that we don't log too large events. In case of a 'too large' event, I just log {corrupted,Binary}. Binary is the beginning of the binary representation of the event. With this patch, the log file isn't corrupted and we still can find (and debugg) which events are too long. Regards, --- Nicolas Charpentier http://charpi.net -------------- next part -------------- A non-text attachment was scrubbed... Name: log_mf_h.erl.patch Type: text/x-patch Size: 1915 bytes Desc: not available URL: From masse@REDACTED Thu Nov 27 14:30:33 2008 From: masse@REDACTED (mats cronqvist) Date: Thu, 27 Nov 2008 14:30:33 +0100 Subject: [erlang-bugs] proc_lib relies on immutable dictionary Message-ID: <87d4ghnvnq.fsf@sterlett.hq.kred> an excellent one-liner in R12-3 (and earlier); 1> proc_lib:spawn_link(fun()->erase(),a=b end). ** exception exit: {badmatch,b} and in R12B-5; 1> proc_lib:spawn_link(fun()->erase(),a=b end). =ERROR REPORT==== 27-Nov-2008::14:25:41 === Error in process <0.192.0> on node 'erl@REDACTED' with exit value: {{badmatch,undefined},[{proc_lib,exit_p,2}]} ** exception error: no match of right hand side value undefined in function proc_lib:exit_p/2 the relevant function in R12B-4; exit_p(Class, Reason, StartF) -> _ = crash_report(Class, Reason, StartF), exit(Reason). and in R12B-5; exit_p(Class, Reason) -> {M,F,A} = get('$initial_call'), MFA = {M,F,make_dummy_args(A, [])}, crash_report(Class, Reason, MFA), exit(Reason). exit_p now (for no apparent reason) relies on the user not clearing the dictionary. mats From bgustavsson@REDACTED Thu Nov 27 15:08:36 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Thu, 27 Nov 2008 15:08:36 +0100 Subject: [erlang-bugs] proc_lib relies on immutable dictionary In-Reply-To: <87d4ghnvnq.fsf@sterlett.hq.kred> References: <87d4ghnvnq.fsf@sterlett.hq.kred> Message-ID: <6672d0160811270608t24466cbdqcf47e13ab59ed306@mail.gmail.com> On Thu, Nov 27, 2008 at 2:30 PM, mats cronqvist wrote: > > exit_p(Class, Reason) -> > {M,F,A} = get('$initial_call'), > MFA = {M,F,make_dummy_args(A, [])}, > crash_report(Class, Reason, MFA), > exit(Reason). > > exit_p now (for no apparent reason) relies on the user not clearing > the dictionary. My fault. I noticed that the initial MFA was passed around in the loop just to be just when the process exited, which I found wasteful as the the value could just as well be retrieved from the process dictionary. If there is a good reason for clearing the process dictionary, I could change back the implementation in R13. Note that from R12B-5, the entire initial arguments are not saved in the process dictionary: OTP-7531 Processes spawned using proc_lib (including gen_server and other library modules that use proc_lib) no longer keep the entire argument list for the initial call, but only the arity. Also, if proc_lib:spawn/1 is used to spawn a fun, the actual fun is not kept, but only module, function name, and arity of the function that implements the fun. The reason for the change is that keeping the initial fun (or a fun in an argument list), would prevent upgrading the code for the module. A secondary reason is that keeping the fun and function arguments could waste a significant amount of memory. The drawback with the change is that the crash reports will provide less precise information about the initial call (only Module:Function/Arity instead of Module:Function(Arguments)). The function proc_lib:initial_call/1 still returns a list, but each argument has been replaced with a dummy atom. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mthibaut@REDACTED Thu Nov 27 20:10:50 2008 From: mthibaut@REDACTED (Maarten Thibaut) Date: Thu, 27 Nov 2008 20:10:50 +0100 Subject: [erlang-bugs] DESTDIR installation breaks erlang scripts In-Reply-To: <8DF21217-2EC1-4A24-ABE2-9A8570D14AA1@cisco.com> References: <70356FBF-219C-47AB-9FC5-F244C79EBE64@cisco.com> <8DF21217-2EC1-4A24-ABE2-9A8570D14AA1@cisco.com> Message-ID: Hi, No reply received... Am I mistaken in my analysis? Did someone take this up as a bug to fix? thanks, maarten On Nov 19, 2008, at 12:49 AM, Maarten Thibaut wrote: > Hi, > > Typo: > >> After this, lib/erlang/bin/erl (and several other ones) contains: >> >> ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang >> >> Obviously this should be: >> >> ROOTDIR=/home/mthibaut/compile/otp-install/opt/local/lib/erlang > > 2nd one should read: > > ROOTDIR=/opt/local/lib/erlang > > -- > maarten -------------- next part -------------- An HTML attachment was scrubbed... URL: From art_den@REDACTED Fri Nov 28 06:43:40 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Fri, 28 Nov 2008 08:43:40 +0300 Subject: [erlang-bugs] =?koi8-r?b?T0RCQyBSMTJCLTUgV2luMzI6IFNlbGVjdCBzdGF0?= =?koi8-r?b?ZW1lbnQgZG9lc24ndCB3b3Jr?= Message-ID: Hello everyone. I tested how Erlang's ODBC works and find out that very simple example from Erlang ODBC documentation doesn't work. odbc:sql_query with SELECT statement, always returns {error,"Column type not supported"} if resulting columns contain varchar of char types. How to reproduce it: ============================================================================ odbc:start(), ConnRes = odbc:connect("Driver={MySQL ODBC 5.1 Driver};Server=localhost;Database=test_db;User=root;Password=root;", []), io:format("ConnRes=~p~n", [ConnRes]), {ok, Ref} = ConnRes, CTres = odbc:sql_query( Ref, "CREATE TABLE EMPLOYEE (" "NR integer, " "FIRSTNAME varchar(32), " "LASTNAME varchar(32), " "GENDER char(1), " "PRIMARY KEY(NR)" ")" ), io:format("CTres=~p~n", [CTres]), INSres = odbc:sql_query(Ref, "INSERT INTO EMPLOYEE VALUES(1, 'Jane', 'Doe', 'F')"), io:format("INSres=~p~n", [INSres]), SelectResult = odbc:sql_query(Ref, "SELECT * FROM EMPLOYEE"), io:format("SelectResult=~p~n", [SelectResult]), odbc:disconnect(Ref), ============================================================================ SelectResult will return {error,"Column type not supported"} for this example. If to select integer column: SELECT NR FROM EMPLOYEE it will work properly then. If to select any char or varchar column: SELECT FIRSTNAME FROM EMPLOYEE odbc:sql_query will return error then. I tested it on Erlang R12B-5, WinXP x86 SP3 Tested databases: * Postgresql-8.3.3-2 and ODBC: PostgreSQL Unicode 8.03.04.00 * Firebird Firebird-2.1.1.17910 and Firebird_ODBC 2.0.0.148 * Mysql-5.1.30 and Mysql-connector-odbc-5.1.5 All databases were created with UTF8 character coding From masse@REDACTED Thu Nov 27 16:02:15 2008 From: masse@REDACTED (mats cronqvist) Date: Thu, 27 Nov 2008 16:02:15 +0100 Subject: [erlang-bugs] proc_lib relies on immutable dictionary In-Reply-To: <6672d0160811270608t24466cbdqcf47e13ab59ed306@mail.gmail.com> (Bjorn Gustavsson's message of "Thu\, 27 Nov 2008 15\:08\:36 +0100") References: <87d4ghnvnq.fsf@sterlett.hq.kred> <6672d0160811270608t24466cbdqcf47e13ab59ed306@mail.gmail.com> Message-ID: <87d4gh2ow8.fsf@sterlett.hq.kred> From masse@REDACTED Fri Nov 28 09:02:25 2008 From: masse@REDACTED (mats cronqvist) Date: Fri, 28 Nov 2008 09:02:25 +0100 Subject: [erlang-bugs] proc_lib relies on immutable dictionary In-Reply-To: <6672d0160811270608t24466cbdqcf47e13ab59ed306@mail.gmail.com> (Bjorn Gustavsson's message of "Thu\, 27 Nov 2008 15\:08\:36 +0100") References: <87d4ghnvnq.fsf@sterlett.hq.kred> <6672d0160811270608t24466cbdqcf47e13ab59ed306@mail.gmail.com> Message-ID: <87wseo1dny.fsf@sterlett.hq.kred> "Bjorn Gustavsson" writes: > On Thu, Nov 27, 2008 at 2:30 PM, mats cronqvist wrote: >> >> exit_p(Class, Reason) -> >> {M,F,A} = get('$initial_call'), >> MFA = {M,F,make_dummy_args(A, [])}, >> crash_report(Class, Reason, MFA), >> exit(Reason). >> >> exit_p now (for no apparent reason) relies on the user not clearing >> the dictionary. > > My fault. I noticed that the initial MFA was passed around in the loop > just to be just when the process > exited, which I found wasteful as the the value could just as well be > retrieved from the process dictionary. i can think of one semi-good reason; process pools. E.g, yaws has a pool of acceptor processes. this btw is how i found it. otoh, i don't think proc_lib should break, no matter how silly it might be to clear the dictionary. mats