From kostis@REDACTED Fri Mar 4 15:51:36 2005 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 4 Mar 2005 15:51:36 +0100 (MET) Subject: Bug in stdlib Message-ID: <200503041451.j24Epahh026680@spikklubban.it.uu.se> Dialyzer found what we think is possibly a serious bug in stdlib/src/erl_eval.erl It complains about: {erl_eval,do_apply,5}: Fun application using type an atom instead of a fun! {erl_eval,do_apply,5}: Fun application using type an atom instead of a fun! In the first clause, the same variable F is used in two distinct ways: one in the head and in the patterns of the case statements. We *think* that the variable in the case patterns should be something else (e.g. F1). ======================================================================= do_apply({M,F}=Func, As, Bs0, Ef, RBs) when is_tuple(M), size(M) >= 1, is_atom(element(1, M)), is_atom(F) -> case Ef of none when RBs == value -> %% Make tail recursive calls when possible. apply(M, F, As); none -> ret_expr(apply(M, F, As), Bs0, RBs); {value,F} when RBs == value -> F(Func, As); {value,F} -> ret_expr(F(Func, As), Bs0, RBs) end; ======================================================================= Best, Kostis From alexey@REDACTED Sat Mar 5 00:44:33 2005 From: alexey@REDACTED (Alexey Shchepin) Date: Sat, 05 Mar 2005 01:44:33 +0200 Subject: Bug in inet_db.erl Message-ID: <87vf872cym.fsf@alex.sevcom.net> Hi! There exists such domain at this moment: % host -t srv _xmpp-server._tcp.centova.net _xmpp-server._tcp.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net cluster.centova.net CNAME cluster.centova.net Possible CNAME loop Now try to run % erl -name test > inet_res:getbyname("_xmpp-server._tcp.centova.net", srv). Erlang VM will eat a lot of memory and then produce erl_crash.dump. Quick fix: --- inet_db.erl.orig Sat Mar 5 01:31:50 2005 +++ inet_db.erl Sat Mar 5 01:47:49 2005 @@ -546,7 +546,12 @@ case res_lookup_type(Domain,?S_CNAME,RRs) of [] -> {error, nxdomain}; [CName | _] -> - res_hostent_by_domain(CName, [Domain | Aliases], Type, RRs) + case lists:member(CName, [Domain | Aliases]) of + true -> {error, nxdomain}; + false -> + res_hostent_by_domain(CName, [Domain | Aliases], + Type, RRs) + end end; Addrs -> {ok, make_hostent(Domain, Addrs, Aliases,Type)} From ulf.wiger@REDACTED Thu Mar 10 11:31:08 2005 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 10 Mar 2005 11:31:08 +0100 Subject: crypto:start() return value differs from manual Message-ID: crypto:start() -> ok. is what the manual states (OTP R10B-2), but the function can also return {error, {already_started,crypto}}. >From crypto.erl: start() -> application:start(crypto). The manual for application says: start(Application) -> ok | {error, Reason} I have made no patch. The code or the manual should be corrected. Regards, Uffe From geoffw@REDACTED Fri Mar 11 00:12:43 2005 From: geoffw@REDACTED (Geoff White) Date: Thu, 10 Mar 2005 15:12:43 -0800 Subject: Erlang port? R10B-3 on OpenBSD 3.7 Message-ID: <4230D46B.8090507@cybertribe.com> I noticed that the Erlan port is hopelessly out of date for OpenBSD. I've been using erlang on OpenBSD and I have a working installation of Erlang R10B-3 on OpenBSD 3.7 (beta) March 10, 2005. I'd like to volunteer to turn this into a port that can go into the ports tree. geoffw For starters, here are the notes on how to get the tar ball to compile and install on 3.7 (beta)... Erlang R10B-3 port to Open BSD 3.7 1. )/otp_src_R10B-3/lib/os_mon/c_src/memsup.c is different from the release, ---------------------------------------------------------------- --- memsup.c.old Thu Mar 10 12:03:28 2005 +++ memsup.c Thu Mar 10 12:02:49 2005 @@ -95,7 +95,11 @@ #ifdef BSD4_4 #include #include -#include +#ifdef __OpenBSD__ +#include +#else +#include +#endif #ifdef __FreeBSD__ #include #endif ------------------------------------------------------------------- 2. ) ./configure --disable-jinterface No jvm under OpenBSD in native mode. 3. ) /otp_src_R10B-3/erts/etc/unix/format_man_pages is BROKEN for OpenBSD, it tests for BSDness by searching for vmunix THERE ISN'T a vmunix file on OpenBSD so this test will fail! I have added a TARGET for OpenBSD. ----------------------------------------------------------------------- --- format_man_pages.orig Thu Mar 10 13:57:56 2005 +++ format_man_pages Thu Mar 10 14:30:59 2005 @@ -29,6 +29,8 @@ TARGET=sunos5 ;; Linux:*) TARGET=linux ;; + OpenBSD:3.*) + TARGET=openbsd ;; *) TARGET="" ;; esac @@ -106,6 +108,8 @@ else if [ -f "/vmunix" ]; then CATMAN=/usr/etc/catman + elif [ "$TARGET" = "openbsd" ]; then + CATMAN=/usr/sbin/catman else CATMAN=/usr/bin/catman fi -------------------------------------------------------------------------------- From tty@REDACTED Mon Mar 14 22:36:24 2005 From: tty@REDACTED (tty@REDACTED) Date: Mon, 14 Mar 2005 16:36:24 -0500 Subject: Erlang seg faults while running ejabberd Message-ID: Hi, Erlang seg. faults while running ejabberd. My particular environment is: SuSE v9.0 Linux 2.4.21-243-default gcc version 3.3.1 (SuSE Linux) Erlang (HIPE) (BEAM) emulator version 5.4.4 ejabberd 0.7.5 Backtrace result is: #0 0x4010fde8 in strcmp () from /lib/i686/libc.so.6 #1 0x40a28064 in obj_name_cmp () from /usr/lib/libcrypto.so.0.9.7 #2 0x40a7fc74 in ?? () #3 0x40638c74 in empty.0 () from /usr/lib/libssl.so.0.9.7 #4 0x000000ba in ?? () #5 0x080957b6 in driver_alloc (size=139071024) at erl_alloc.h:187 #6 0x03149d58 in ?? () #7 0x084a0a20 in ?? () #8 0x00008000 in ?? () #9 0x084a0e08 in ?? () #10 0x40a26e25 in lh_insert () from /usr/lib/libcrypto.so.0.9.7 #11 0x084a0a20 in ?? () #12 0x084a0e08 in ?? () #13 0xbfffec58 in ?? () #14 0x409b290e in OBJ_NAME_add () from /usr/lib/libcrypto.so.0.9.7 #15 0x40a52ce4 in __JCR_LIST__ () from /usr/lib/libcrypto.so.0.9.7 #16 0x00000001 in ?? () #17 0x00008000 in ?? () #18 0xbfffecb8 in ?? () #19 0x409b28c8 in OBJ_NAME_add () from /usr/lib/libcrypto.so.0.9.7 #20 0x080f0ee0 in erts_sys_alloc (t=139070968, x=0x84a0e20, sz=1083910344) at sys/unix/sys.c:3035 Previous frame inner to this frame (corrupt stack?) A list shows: 3035 void *res = malloc((size_t) sz); 3036 #if HAVE_ERTS_MSEG 3037 if (!res) { 3038 erts_mseg_clear_cache(); 3039 return malloc((size_t) sz); 3040 } 3041 #endif 3042 return res; 3043 } Reproducing this takes around 2-3 tries on average. Steps: 1. Setup a distributed ejabberd cluster (Node A and Node B). Both nodes have the same tables in mnesia distributed using the same type (eg route is ram_copies on both nodes, offline_msg disc_only_copies on both etc). 2. Login on both nodes with one client each (tkabber was use in this case), Ca - client on Node A, Cb - client on Node B. 3. Ca chats with Cb. 4. Shutdown Node A. 5. Bring Node A back up. 6. Cb logs off. 7. Cb logs in. At this point Node B should seg fault. As noted earlier it might require several attempts to obtain the seg fault. Thanks in advance totem From tty@REDACTED Mon Mar 14 22:44:19 2005 From: tty@REDACTED (tty@REDACTED) Date: Mon, 14 Mar 2005 16:44:19 -0500 Subject: Erlang seg faults while running ejabberd Message-ID: Hi, Apologies if this was sent twice. Erlang seg. faults while running ejabberd. My particular environment is: SuSE v9.0 Linux 2.4.21-243-default gcc version 3.3.1 (SuSE Linux) Erlang (HIPE) (BEAM) emulator version 5.4.4 ejabberd 0.7.5 Backtrace result is: #0 0x4010fde8 in strcmp () from /lib/i686/libc.so.6 #1 0x40a28064 in obj_name_cmp () from /usr/lib/libcrypto.so.0.9.7 #2 0x40a7fc74 in ?? () #3 0x40638c74 in empty.0 () from /usr/lib/libssl.so.0.9.7 #4 0x000000ba in ?? () #5 0x080957b6 in driver_alloc (size=139071024) at erl_alloc.h:187 #6 0x03149d58 in ?? () #7 0x084a0a20 in ?? () #8 0x00008000 in ?? () #9 0x084a0e08 in ?? () #10 0x40a26e25 in lh_insert () from /usr/lib/libcrypto.so.0.9.7 #11 0x084a0a20 in ?? () #12 0x084a0e08 in ?? () #13 0xbfffec58 in ?? () #14 0x409b290e in OBJ_NAME_add () from /usr/lib/libcrypto.so.0.9.7 #15 0x40a52ce4 in __JCR_LIST__ () from /usr/lib/libcrypto.so.0.9.7 #16 0x00000001 in ?? () #17 0x00008000 in ?? () #18 0xbfffecb8 in ?? () #19 0x409b28c8 in OBJ_NAME_add () from /usr/lib/libcrypto.so.0.9.7 #20 0x080f0ee0 in erts_sys_alloc (t=139070968, x=0x84a0e20, sz=1083910344) at sys/unix/sys.c:3035 Previous frame inner to this frame (corrupt stack?) A list shows: 3035 void *res = malloc((size_t) sz); 3036 #if HAVE_ERTS_MSEG 3037 if (!res) { 3038 erts_mseg_clear_cache(); 3039 return malloc((size_t) sz); 3040 } 3041 #endif 3042 return res; 3043 } Reproducing this takes around 2-3 tries on average. Steps: 1. Setup a distributed ejabberd cluster (Node A and Node B). Both nodes have the same tables in mnesia distributed using the same type (eg route is ram_copies on both nodes, offline_msg disc_only_copies on both etc). 2. Login on both nodes with one client each (tkabber was use in this case), Ca - client on Node A, Cb - client on Node B. 3. Ca chats with Cb. 4. Shutdown Node A. 5. Bring Node A back up. 6. Cb logs off. 7. Cb logs in. At this point Node B should seg fault. As noted earlier it might require several attempts to obtain the seg fault. Thanks in advance totem From alexey@REDACTED Tue Mar 15 09:10:07 2005 From: alexey@REDACTED (Alexey Shchepin) Date: Tue, 15 Mar 2005 10:10:07 +0200 Subject: Bug in inet_db.erl In-Reply-To: <87vf872cym.fsf@alex.sevcom.net> (Alexey Shchepin's message of "Sat, 05 Mar 2005 01:44:33 +0200") References: <87vf872cym.fsf@alex.sevcom.net> Message-ID: <878y4p49eo.fsf@alex.sevcom.net> Hi! On Sat, 05 Mar 2005 01:44:33 +0200, I said: AS> Now try to run AS> % erl -name test AS> > inet_res:getbyname("_xmpp-server._tcp.centova.net", srv). AS> Erlang VM will eat a lot of memory and then produce erl_crash.dump. AS> Quick fix: Sorry, it was incomplete fix. Corrected patch: --- inet_db.erl.orig Sat Mar 5 01:31:50 2005 +++ inet_db.erl Tue Mar 15 10:58:50 2005 @@ -511,7 +511,12 @@ case lookup_cname(Domain) of [] -> {error, nxdomain}; [CName | _] -> - hostent_by_domain(CName, [Domain | Aliases], Type) + case lists:member(CName, [Domain | Aliases]) of + true -> {error, nxdomain}; + false -> + hostent_by_domain(CName, [Domain | Aliases], + Type) + end end; Addrs -> {ok, make_hostent(Domain, Addrs, Aliases,Type)} @@ -546,7 +551,12 @@ case res_lookup_type(Domain,?S_CNAME,RRs) of [] -> {error, nxdomain}; [CName | _] -> - res_hostent_by_domain(CName, [Domain | Aliases], Type, RRs) + case lists:member(CName, [Domain | Aliases]) of + true -> {error, nxdomain}; + false -> + res_hostent_by_domain(CName, [Domain | Aliases], + Type, RRs) + end end; Addrs -> {ok, make_hostent(Domain, Addrs, Aliases,Type)} From erlang-list@REDACTED Mon Mar 21 22:16:58 2005 From: erlang-list@REDACTED (Dominic Williams) Date: Mon, 21 Mar 2005 22:16:58 +0100 Subject: Bug with module_info in R10B-3 Message-ID: <423F39CA.40409@dominicwilliams.net> Hello, The following bug appeared sometime after R9C, and is at least present in R10B-3 under Windows XP: when recompiling a modified module, its old exports appear to be kept by module_info. E.g., after compiling test.erl: ----------------- -module(test). -export([foo/0]). foo() -> ok. ----------------- test:module_info(exports) returns [{foo,0},{module_info,0},{module_info,1}] After modifying and recompiling test.erl thus: ----------------- -module(test). -export([bar/0]). bar() -> ok. ----------------- test:module_info(exports) now returns [{foo,0},{bar,0},{module_info,0},{module_info,1}] Regards, Dominic, on behalf of the www.xpdojo.org team. From tpatro@REDACTED Thu Mar 24 12:29:48 2005 From: tpatro@REDACTED (Tamas Patrovics) Date: Thu, 24 Mar 2005 12:29:48 +0100 Subject: badarg in erl_recomment:recomment_forms Message-ID: I tried scanning all the .erl files in the Erlang distribution and extract documentation from them. Generally it works fine, however if I pass any of these files otp_src_R10B-3/lib/kernel/src/error_handler.erl otp_src_R10B-3/lib/compiler/src/beam_disasm.erl otp_src_R10B-3/lib/compiler/src/sys_pre_expand.erl otp_src_R10B-3/lib/compiler/src/v3_core.erl otp_src_R10B-3/lib/compiler/src/beam_validator.erl otp_src_R10B-3/lib/debugger/src/dbg_ieval.erl otp_src_R10B-3/lib/hipe/cerl/cerl_typesig.erl otp_src_R10B-3/lib/stdlib/src/erl_eval.erl otp_src_R10B-3/lib/compiler/src/sys_core_fold.erl to this simple module -module(doc). -export([start/1]). start(Path) -> {ok, Source} = epp:parse_file(Path, [], []), Comments = erl_comment_scan:file(Path), erl_recomment:recomment_forms(Source, Comments). then I get a badarg error like this one Error in process <0.74.0> with exit value: {{badarg,{try,723,[{call,723,{atom,723,apply},[{atom,723,erlang},{var,723,'Name'},{var,723,'As'}]}],[{clause,724,[{var,724,'Value'}],[[{op,724,'==',{var,724,'Lc'},{atom,724,true}}]],[{tuple,725,[{atom,725,value},{var,725,'Value'},{var,725,'Bs'}]}]},{clause,726,[{var,726,'Value'}],[],[{call,727,... /Tamas From vances@REDACTED Fri Mar 25 23:35:40 2005 From: vances@REDACTED (Vance Shipley) Date: Fri, 25 Mar 2005 17:35:40 -0500 Subject: wrong path for config.cache Message-ID: <20050325223540.GA19758@frogman.motivity.ca> In the recently released R10B-4 the configure files are creating a config.cache file which is ../config.cache relative to ERL_TOP. I discovered this because I didn't have write permission there. :) -Vance From richardc@REDACTED Tue Mar 29 22:45:53 2005 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 29 Mar 2005 22:45:53 +0200 Subject: Compiler crash with abstract modules... In-Reply-To: <41DEF27D.30203@cisco.com> References: <41DEF27D.30203@cisco.com> Message-ID: <4249BE81.1030908@csd.uu.se> Mark Scandariato wrote: > Interesting crash when compiling the following snippet: > > %%%---------------------- > -module(foo, [N]). > -compile(export_all). > > bug(<>) -> V. > %%%---------------------- > > This is equivalent to: > %%%---------------------- > -module(foo). > -compile(export_all). > > bug(<>, {foo, N}) -> V. > %%%---------------------- > > Which would normally just complain that "variable 'N' is unbound". Yes, this is a problem with the current implementation, which expands the parameterized code just as you show; this means that the variable N becomes bound too late to be used as an argument to the binary-pattern (but in the case of the parameterized code, we have already assured the compiler that N is bound, so it happily passes it on to the backend, which crashes). For various reasons (mainly efficiency), though, the THIS-variable needs to be the last passed argument. The best solution for now is to rewrite the code as nobug(B) -> case B of <> -> V end. (until we can get the compiler to do this by itself). Probably we should meanwhile complain about N being unbound. /Richard From mscandar@REDACTED Tue Mar 29 23:19:56 2005 From: mscandar@REDACTED (Mark Scandariato) Date: Tue, 29 Mar 2005 16:19:56 -0500 Subject: Compiler crash with abstract modules... In-Reply-To: <4249BE81.1030908@csd.uu.se> References: <41DEF27D.30203@cisco.com> <4249BE81.1030908@csd.uu.se> Message-ID: <4249C67C.8080703@cisco.com> But even foo(N, <>) -> V. is illegal. I assumed it had to do with the fact that order of paremeter evaluation isn't guaranteed. (Unless I'm mistaken.) Mark. Richard Carlsson wrote: > Mark Scandariato wrote: > >>Interesting crash when compiling the following snippet: >> >>%%%---------------------- >>-module(foo, [N]). >>-compile(export_all). >> >>bug(<>) -> V. >>%%%---------------------- >> >>This is equivalent to: >>%%%---------------------- >>-module(foo). >>-compile(export_all). >> >>bug(<>, {foo, N}) -> V. >>%%%---------------------- >> >>Which would normally just complain that "variable 'N' is unbound". > > > Yes, this is a problem with the current implementation, which > expands the parameterized code just as you show; this means that > the variable N becomes bound too late to be used as an argument > to the binary-pattern (but in the case of the parameterized code, > we have already assured the compiler that N is bound, so it > happily passes it on to the backend, which crashes). For various > reasons (mainly efficiency), though, the THIS-variable needs to > be the last passed argument. The best solution for now is to > rewrite the code as > > nobug(B) -> > case B of > <> -> V > end. > > (until we can get the compiler to do this by itself). Probably > we should meanwhile complain about N being unbound. > > /Richard > From richardc@REDACTED Wed Mar 30 00:25:54 2005 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 30 Mar 2005 00:25:54 +0200 Subject: Compiler crash with abstract modules... In-Reply-To: <4249C67C.8080703@cisco.com> References: <41DEF27D.30203@cisco.com> <4249BE81.1030908@csd.uu.se> <4249C67C.8080703@cisco.com> Message-ID: <4249D5F2.4040503@csd.uu.se> Mark Scandariato wrote: > But even > > foo(N, <>) -> V. > > is illegal. You're right - moving the this-argument first wouldn't work either. But the parameterized-module version *ought* to work (regardless of how it is done under the hood), since the scope of the variable is supposed to be the whole module. So it should be fixed, somehow. /Richard > Richard Carlsson wrote: > >> Mark Scandariato wrote: >> >>> Interesting crash when compiling the following snippet: >>> >>> %%%---------------------- >>> -module(foo, [N]). >>> -compile(export_all). >>> >>> bug(<>) -> V. >>> %%%---------------------- >>> >>> This is equivalent to: >>> %%%---------------------- >>> -module(foo). >>> -compile(export_all). >>> >>> bug(<>, {foo, N}) -> V. >>> %%%---------------------- >>> >>> Which would normally just complain that "variable 'N' is unbound". >> >> >> >> Yes, this is a problem with the current implementation, which >> expands the parameterized code just as you show; this means that >> the variable N becomes bound too late to be used as an argument >> to the binary-pattern (but in the case of the parameterized code, >> we have already assured the compiler that N is bound, so it >> happily passes it on to the backend, which crashes). For various >> reasons (mainly efficiency), though, the THIS-variable needs to >> be the last passed argument. The best solution for now is to >> rewrite the code as >> >> nobug(B) -> >> case B of >> <> -> V >> end. >> >> (until we can get the compiler to do this by itself). Probably >> we should meanwhile complain about N being unbound. >> >> /Richard >> >