From pguyot@REDACTED Fri Oct 3 16:05:53 2008 From: pguyot@REDACTED (Paul Guyot) Date: Fri, 3 Oct 2008 16:05:53 +0200 Subject: [erlang-bugs] Bug in ei_decode_big, implementation for ei_*encode_big Message-ID: <4E9E0ABD-DC37-442D-BC1A-4B48B5309777@kallisys.net> Hello, ei.h has the following FIXME notice before the prototype of the big functions: /* FIXME: is this really the best way to handle bignums? */ The thing is that ei_decode_big has a bug that makes it unusable, around line 54 of decode_big.c: for (i = 0; i < b->arity; ++i) { dt[i] = u[i*2]; dt[i] |= ((unsigned short) u[(i*2)+1]) << 8; <--- this is line 54 } The high order bits of the 16-bits digit (short) are read, even if the byte (at u[(i*2)+1]) doesn't belong to the big. In other words, big numbers such as 16#1234567890 with an odd number of bytes are decoded with a garbage byte (i.e. 16#XX1234567890). The following change fixes the problem: for (i = 0; i < b->arity; ++i) { dt[i] = u[i*2]; if ((i*2 + 1) < digit_bytes) { dt[i] |= ((unsigned short) u[(i*2)+1]) << 8; } } Also, ei_*encode_big is missing. Here is a sample implementation: int ei_encode_big(char *buf, int *index, erlang_big* big) { unsigned short* digits = big->digits; char *s = buf + *index; char *s0 = s; int arity = big->arity; long digit_bytes = (arity * 2); if (digit_bytes < 256) { if (buf != NULL) { put8(s, ERL_SMALL_BIG_EXT); put8(s, digit_bytes); } else { s += 2; } } else { if (buf != NULL) { put8(s, ERL_LARGE_BIG_EXT); put32be(s, digit_bytes); } else { s += 5; } } if (buf != NULL) { put8(s, big->is_neg); int i; for (i = 0; i < arity; ++i) { put16le(s, digits[i]); } } else { s += 1 + (arity * 2); } *index += s-s0; return 0; } int ei_x_encode_big(ei_x_buff* x, erlang_big* big) { int i = x->index; ei_encode_big(NULL, &i, big); if (!x_fix_buff(x, i)) return -1; return ei_encode_big(x->buff, &x->index, big); } Regards, Paul From pguyot@REDACTED Fri Oct 3 16:16:29 2008 From: pguyot@REDACTED (Paul Guyot) Date: Fri, 3 Oct 2008 16:16:29 +0200 Subject: [erlang-bugs] Bug in ei_decode_fun Message-ID: <8FC1BBCA-9968-43E0-8398-97392389BB32@kallisys.net> Hello, There is a bug in ei_decode_fun, decode_fun.c, line 106. n = n - (s - s0) + 1; if (p != NULL) { p->free_var_len = n; if (n > 0) { p->free_vars = malloc(n); /* FIXME check result */ memcpy(p->free_vars, s, n); } } *index += s-s0; <--- this is line 106 return 0; The buffer cursor is incremented by s0 (start) - s (cursor before the freevars). It should be incremented by n as well: *index += n + s-s0; Regards, Paul From egil@REDACTED Fri Oct 3 16:56:42 2008 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 03 Oct 2008 16:56:42 +0200 Subject: [erlang-bugs] Bug in ei_decode_big, implementation for ei_*encode_big In-Reply-To: <4E9E0ABD-DC37-442D-BC1A-4B48B5309777@kallisys.net> References: <4E9E0ABD-DC37-442D-BC1A-4B48B5309777@kallisys.net> Message-ID: <48E632AA.2090201@erix.ericsson.se> Hi Paul, Thank you for reporting this. I will look into it and try to make the appropriate corrections for this and the fun problems. Regards, Bj?rn-Egil Erlang/OTP Paul Guyot wrote: > Hello, > > ei.h has the following FIXME notice before the prototype of the big > functions: > > /* FIXME: is this really the best way to handle bignums? */ > > The thing is that ei_decode_big has a bug that makes it unusable, > around line 54 of decode_big.c: > > for (i = 0; i < b->arity; ++i) { > dt[i] = u[i*2]; > dt[i] |= ((unsigned short) u[(i*2)+1]) << 8; <--- this > is line 54 > } > > The high order bits of the 16-bits digit (short) are read, even if > the byte (at u[(i*2)+1]) doesn't belong to the big. In other words, > big numbers such as 16#1234567890 with an odd number of bytes are > decoded with a garbage byte (i.e. 16#XX1234567890). > > The following change fixes the problem: > > for (i = 0; i < b->arity; ++i) { > dt[i] = u[i*2]; > if ((i*2 + 1) < digit_bytes) > { > dt[i] |= ((unsigned short) u[(i*2)+1]) << 8; > } > } > > Also, ei_*encode_big is missing. Here is a sample implementation: > > int ei_encode_big(char *buf, int *index, erlang_big* big) > { > unsigned short* digits = big->digits; > char *s = buf + *index; > char *s0 = s; > int arity = big->arity; > long digit_bytes = (arity * 2); > > if (digit_bytes < 256) > { > if (buf != NULL) > { > put8(s, ERL_SMALL_BIG_EXT); > put8(s, digit_bytes); > } else { > s += 2; > } > } else { > if (buf != NULL) > { > put8(s, ERL_LARGE_BIG_EXT); > put32be(s, digit_bytes); > } else { > s += 5; > } > } > if (buf != NULL) > { > put8(s, big->is_neg); > int i; > for (i = 0; i < arity; ++i) > { > put16le(s, digits[i]); > } > } else { > s += 1 + (arity * 2); > } > > *index += s-s0; > > return 0; > } > > int ei_x_encode_big(ei_x_buff* x, erlang_big* big) > { > int i = x->index; > ei_encode_big(NULL, &i, big); > if (!x_fix_buff(x, i)) > return -1; > return ei_encode_big(x->buff, &x->index, big); > } > > Regards, > > Paul > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From erlang-questions_efine@REDACTED Sat Oct 4 00:05:58 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Fri, 3 Oct 2008 18:05:58 -0400 Subject: [erlang-bugs] Enhancement to compiler-4.5.4 documentation Message-ID: <6c2563b20810031505g41391fbeg5b029e58315b7375@mail.gmail.com> In the documentation for compiler-4.5.4, in the options it states export_all Causes all functions in the module to be exported.This does not explain that previously inlined functions become "uninlined" and are also exported. I suggest changing this to the following: export_all Causes all functions in the module to be exported*, including functions that are declared as inline.*I think it's rather important to know this. Regards, Edwin Fine -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Sun Oct 5 08:18:24 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Sun, 5 Oct 2008 08:18:24 +0200 Subject: [erlang-bugs] Enhancement to compiler-4.5.4 documentation In-Reply-To: <6c2563b20810031505g41391fbeg5b029e58315b7375@mail.gmail.com> References: <6c2563b20810031505g41391fbeg5b029e58315b7375@mail.gmail.com> Message-ID: <6672d0160810042318j4f658d2ao699b57746643ff16@mail.gmail.com> 2008/10/4 Edwin Fine > In the documentation for compiler-4.5.4, in the options it states > export_all Causes all functions in the module to be exported.This does not > explain that previously inlined functions become "uninlined" and are also > exported. I suggest changing this to the following: > Are you sure about "uninlined"? The expected behavior is that exported functions are still inlined, but still kept as a exported functions. Examining the assembly code for the following module -module(t). -compile(export_all). -export([t/0]). -compile({inline,[{foo,0}]}). t() -> foo(). foo() -> 42. it can be seen that the call to foo/0 has been replaced with 42 in t/0. export_all Causes all functions in the module to be exported*, including > functions that are declared as inline.*I think it's rather important to > know this. > Why? The functions are still being inlined as expected. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Sun Oct 5 10:49:34 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Sun, 5 Oct 2008 04:49:34 -0400 Subject: [erlang-bugs] Enhancement to compiler-4.5.4 documentation In-Reply-To: <6672d0160810042318j4f658d2ao699b57746643ff16@mail.gmail.com> References: <6c2563b20810031505g41391fbeg5b029e58315b7375@mail.gmail.com> <6672d0160810042318j4f658d2ao699b57746643ff16@mail.gmail.com> Message-ID: <6c2563b20810050149m41df6888u845cd62474c9deb3@mail.gmail.com> On Sun, Oct 5, 2008 at 2:18 AM, Bjorn Gustavsson wrote: > 2008/10/4 Edwin Fine > >> In the documentation for compiler-4.5.4, in the options it states >> export_all Causes all functions in the module to be exported.This does >> not explain that previously inlined functions become "uninlined" and are >> also exported. I suggest changing this to the following: >> > Are you sure about "uninlined"? > It was a bad explanation on my part to write "uninlined." What I meant there is that a separate, standalone function is also created. Before I wrote this email I had already looked at the assembler to check my facts and had seen that the function was still inlined, but also created as a separate function. Bad wording, sorry. > > The expected behavior is that exported functions are still inlined, but > still kept as a exported functions. Examining > the assembly code for the following module > > -module(t). > > -compile(export_all). > -export([t/0]). > -compile({inline,[{foo,0}]}). > > t() -> > foo(). > > foo() -> > 42. > > it can be seen that the call to foo/0 has been replaced with 42 in t/0. > Yes, agreed. > > export_all Causes all functions in the module to be exported*, including >> functions that are declared as inline.*I think it's rather important to >> know this. >> > > Why? The functions are still being inlined as expected. > My concern is that the extra separate function bodies take up unnecessary space, and if there are many functions included in many modules (as there are in my situation, where I have 5 inlined functions in an hrl file that gets included everywhere), it could create significant code bloat (say, 50 modules and 4 unused but exported functions per module). Granted, this is only likely to happen if export_all is applied in the compilation of all modules. And granted, the expansion of the inlined code is likely to cause much more bloat than the extra unused functions. If you tell me this is not an issue, I will accept that. In any case, it wouldn't hurt to put this is the documentation, would it? /Bjorn > Regards, Edwin Fin e > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Sun Oct 5 14:00:46 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Sun, 5 Oct 2008 14:00:46 +0200 Subject: [erlang-bugs] Enhancement to compiler-4.5.4 documentation In-Reply-To: <6c2563b20810050149m41df6888u845cd62474c9deb3@mail.gmail.com> References: <6c2563b20810031505g41391fbeg5b029e58315b7375@mail.gmail.com> <6672d0160810042318j4f658d2ao699b57746643ff16@mail.gmail.com> <6c2563b20810050149m41df6888u845cd62474c9deb3@mail.gmail.com> Message-ID: <6672d0160810050500w3d881591y74e07f95c37d09a4@mail.gmail.com> On Sun, Oct 5, 2008 at 10:49 AM, Edwin Fine wrote: > > > My concern is that the extra separate function bodies take up unnecessary > space, and if there are many functions included in many modules (as there > are in my situation, where I have 5 inlined functions in an hrl file that > gets included everywhere), it could create significant code bloat (say, 50 > modules and 4 unused but exported functions per module). Granted, this is > only likely to happen if export_all is applied in the compilation of all > modules. And granted, the expansion of the inlined code is likely to cause > much more bloat than the extra unused functions. > > If you tell me this is not an issue, I will accept that. In any case, it > wouldn't hurt to put this is the documentation, would it? > The section about inlining could be a little bit clearer. I'll change it to explicitly mention that any exported function will be kept. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Mon Oct 6 16:19:20 2008 From: nem@REDACTED (Geoff Cant) Date: Mon, 06 Oct 2008 16:19:20 +0200 Subject: [erlang-bugs] TXT record decoding bug in inet_dns Message-ID: Hi there, while sneakily using the private inet_res API to do interesting DNS queries, I discovered a long-standing bug in inet_dns. inet_dns incorrectly decodes the RData for TXT records as RData instead of [Length | Text] = RData, Text. (The RData for TXT records is encoded as <>). Attached is a patch against R12B-4 to correct this bug. It should apply with patch -p1 from the OTP sources root. -------------- next part -------------- A non-text attachment was scrubbed... Name: dns_txt_record_fix.diff Type: text/x-patch Size: 663 bytes Desc: not available URL: -------------- next part -------------- The second patch fixes the encoding of TXT records in the same way. -------------- next part -------------- A non-text attachment was scrubbed... Name: dns_txt_record_fix2.diff Type: text/x-patch Size: 668 bytes Desc: not available URL: -------------- next part -------------- On a related note, I've found the functionality in inet_res to be particularly useful and would like to know if the OTP team would consider exposing and this functionality. This could be done as a new 'dns' modules for queries, resolution, encoding and decoding or perhaps just exporting and documenting some of these private inet_res, inet_dns functions. Ideally I would like to be able to do: dns:lookup(Name, Type) -> {error, Error} | {ok, RR}. dns:lookup(Server, Name, Type) dns:lookup(Server, Name, Type, Timeout) For at least the SOA, NS, TXT, A, CName, PTR, SRV and MX resource record types. I'd be happy to write patches or a new dns module if the OTP team would look favourably on including it in OTP. Cheers, -- Geoff Cant From pguyot@REDACTED Mon Oct 6 17:10:54 2008 From: pguyot@REDACTED (Paul Guyot) Date: Mon, 6 Oct 2008 17:10:54 +0200 Subject: [erlang-bugs] Bug in ei_resolve.c/copy_hostent Message-ID: <8CD62780-89F2-435D-83CF-73453F1F34B7@kallisys.net> Hello, There is a very bad bug in ei_resolve.c's copy_hostent. The function modifies the source hostent structure provided by gethost* functions, and in particular h_aliases and h_addr_list, while it shouldn't. On MacOS X 10.4, this yields to a heap corruption. One can arguably blame MacOS X for this bug (which might be fixed on 10.5), but yet I believe the fields should be copied for safety. The attached patch fixes the problem and declares the source hostent const to enforce the check by the compiler. Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_ei_resolve.diff Type: application/octet-stream Size: 1531 bytes Desc: not available URL: From matthew.dempsky@REDACTED Mon Oct 6 17:26:07 2008 From: matthew.dempsky@REDACTED (Matthew Dempsky) Date: Mon, 6 Oct 2008 08:26:07 -0700 Subject: [erlang-bugs] TXT record decoding bug in inet_dns In-Reply-To: References: Message-ID: 2008/10/6 Geoff Cant : > inet_dns incorrectly decodes the RData for TXT records as RData instead > of [Length | Text] = RData, Text. (The RData for TXT records is encoded > as <>). RDATA for TXT records allows more than one character string. From geoff.cant@REDACTED Tue Oct 7 14:28:06 2008 From: geoff.cant@REDACTED (Geoff Cant) Date: Tue, 07 Oct 2008 14:28:06 +0200 Subject: [erlang-bugs] TXT record decoding bug in inet_dns In-Reply-To: (Matthew Dempsky's message of "Mon, 6 Oct 2008 08:26:07 -0700") References: Message-ID: "Matthew Dempsky" writes: > 2008/10/6 Geoff Cant : >> inet_dns incorrectly decodes the RData for TXT records as RData instead >> of [Length | Text] = RData, Text. (The RData for TXT records is encoded >> as <>). > > RDATA for TXT records allows more than one character string. Good point - in which case txt records should decode to a list of strings. Updated patch attached (encoding and decoding) against R12B-4 (supercedes previous patches). -------------- next part -------------- A non-text attachment was scrubbed... Name: dns_txt_record_fix3.diff Type: text/x-patch Size: 1445 bytes Desc: not available URL: -------------- next part -------------- Cheers, -- Geoff Cant From oscar@REDACTED Tue Oct 7 20:20:22 2008 From: oscar@REDACTED (=?utf-8?Q?Oscar_Hellstr=C3=B6m?=) Date: Tue, 7 Oct 2008 19:20:22 +0100 (BST) Subject: [erlang-bugs] Missing .app files in the OTP distribution In-Reply-To: <3258009.7041223403554622.JavaMail.root@zimbra> Message-ID: <19703915.7061223403621884.JavaMail.root@zimbra> Hi, I've noticed that the common_test and test_server are missing .app files, making it a bit complicated to include them in your own target system. Is there any reason for this? Best regards -- Oscar Hellstr?m, oscar@REDACTED Phone: +44 (0)798 45 44 773 Mobile: +44 (0)207 65 50 337 Web: http://www.erlang-consulting.com From kenneth.lundin@REDACTED Tue Oct 7 21:42:09 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 7 Oct 2008 21:42:09 +0200 Subject: [erlang-bugs] Missing .app files in the OTP distribution In-Reply-To: <19703915.7061223403621884.JavaMail.root@zimbra> References: <3258009.7041223403554622.JavaMail.root@zimbra> <19703915.7061223403621884.JavaMail.root@zimbra> Message-ID: Hi, The reason is that common_test and test_server is not intended to be included in a target system and we have never during the last +10 years seen any use-case for doing that. It is however no problem to include them in a target system using interactive mode it is only when running the target system in embedded mode it may be a problem that the .app files are missing. Even in a target system in embedded mode there is no problem to explicitly load the modules of common_test or test_server and start them. Note also that common_test mostly is intended to be run in another Erlang node than the system under test. It may still be a good idea to create .app files for those applications but I still think it would be strange to include them in a target system. /Kenneth Erlang/OTP team, Ericsson On Tue, Oct 7, 2008 at 8:20 PM, Oscar Hellstr?m wrote: > Hi, > > I've noticed that the common_test and test_server are missing .app files, making it a bit complicated to include them in your own target system. Is there any reason for this? > > Best regards > -- > Oscar Hellstr?m, oscar@REDACTED > Phone: +44 (0)798 45 44 773 > Mobile: +44 (0)207 65 50 337 > Web: http://www.erlang-consulting.com > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From rvirding@REDACTED Wed Oct 8 15:44:18 2008 From: rvirding@REDACTED (Robert Virding) Date: Wed, 8 Oct 2008 15:44:18 +0200 Subject: [erlang-bugs] Compiler bug in sys_core_fold.erl Message-ID: <3dbc6d1c0810080644p420c7680kd3a64594ecafcdc@mail.gmail.com> I am running R12B-4 and have generated code with Lisp Flavoured Erlang. There is a bug in eval_element/3 which is called from fold_call/4 which tries to safely evaluate calls at compile time. Eval_element tries to evaluate calls to element/2. It also tries to check if the call is guaranteed to fail in which case it replaces the original call with a call to erlang:error(badarg). It is this check which is causing the bug as it is so tuned to code generated by the vanilla erlang compiler that it does not accept a nested call in the element. This is the bug. I would also argue that such a substitution has very little noticeable effect as any evaluation of the arguments to element/2 have been broken out and will already be evaluated before the code ever reaches the erlang:error call. It, in fact, saves very little. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kjellin@REDACTED Wed Oct 8 17:06:10 2008 From: martin.kjellin@REDACTED (martin kjellin) Date: Wed, 08 Oct 2008 17:06:10 +0200 Subject: [erlang-bugs] calling module_info() on a R9C2 beam causes erlang R12B4 to segfault Message-ID: <48ECCC62.6060103@mobilearts.com> Hello I've attached segfault.beam, compiled with R9C2, that when loaded into a R12B4 system causes erlang to segfault when segfault:module_info() is called. Calling module_info() on the same beam works in R11B5 (and R9C2). Attached is also the source code (it's not a very complicated module...) but it's not a straighforward map between the erl- and beam-file as there's a parse transform involved. segfault.beam is compiled with debug info. I run ubuntu 8.04 on a pentium m. best regards Martin Kjellin -------------- next part -------------- A non-text attachment was scrubbed... Name: segfault.beam Type: application/octet-stream Size: 1680 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: segfault.erl URL: From raimo+erlang-bugs@REDACTED Thu Oct 9 10:27:53 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 9 Oct 2008 10:27:53 +0200 Subject: [erlang-bugs] : TXT record decoding bug in inet_dns In-Reply-To: References: Message-ID: <20081009082753.GA28156@erix.ericsson.se> Thank you for your patch. We will take a look at it and if it does not break anything it will most probably be accepted. On Tue, Oct 07, 2008 at 02:28:06PM +0200, Geoff Cant wrote: > "Matthew Dempsky" writes: > > > 2008/10/6 Geoff Cant : > >> inet_dns incorrectly decodes the RData for TXT records as RData instead > >> of [Length | Text] = RData, Text. (The RData for TXT records is encoded > >> as <>). > > > > RDATA for TXT records allows more than one character string. > > Good point - in which case txt records should decode to a list of > strings. Updated patch attached (encoding and decoding) against R12B-4 > (supercedes previous patches). > > diff --git a/lib/kernel/src/inet_dns.erl b/lib/kernel/src/inet_dns.erl > index b99b774..6bd7867 100644 > --- a/lib/kernel/src/inet_dns.erl > +++ b/lib/kernel/src/inet_dns.erl > @@ -400,11 +400,20 @@ decode_data(?S_MX, _, [P1,P0 | Dom], Buffer) -> > { ?i16(P1,P0), decode_domain(Dom, Buffer) }; > decode_data(?S_SRV, _, [P1,P0, W1,W0, Po1,Po0 | Dom], Buffer) -> > { ?i16(P1,P0), ?i16(W1,W0), ?i16(Po1,Po0), decode_domain(Dom, Buffer) }; > -decode_data(?S_TXT, _, Data, _Buffer) -> Data; > +decode_data(?S_TXT, _, Data, _Buffer) -> > + decode_txt(Data); > %% sofar unknown or non standard > decode_data(_, _, Data, _Buffer) -> > Data. > > +decode_txt_data(List) -> > + decode_txt_data(List, []). > + > +decode_txt_data([], Acc) -> Acc; > +decode_txt_data([Len | Data], Acc) -> > + {Str,Rest} = lists:split(Len, Data), > + decode_txt(Rest, Acc ++ [Str]). > + > decode_domain(Data, Buffer) -> > case dn_expand(Data, Buffer) of > error -> error; > @@ -498,7 +507,8 @@ encode_data(?S_MX, in, {Pref, Exch}, Ptrs, L) -> > encode_data(?S_SRV, in, {Prio, Weight, Port, Target}, Ptrs, L) -> > {EDom, NPtrs} = dn_compress(Target, Ptrs, [], L), > {?int16(Prio) ++ ?int16(Weight) ++ ?int16(Port) ++ EDom, NPtrs}; > -encode_data(?S_TXT, in, Data, Ptrs, _) -> {Data, Ptrs}; > +encode_data(?S_TXT, in, Data, Ptrs, _) -> > + {[[length(Str) | Str] || Str <- Data], Ptrs}; > %% sofar unknown or non standard > encode_data(_, _, Data, Ptrs, _) -> {Data, Ptrs}. > > > Cheers, > -- > Geoff Cant > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Fri Oct 10 11:33:47 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 10 Oct 2008 11:33:47 +0200 Subject: [erlang-bugs] calling module_info() on a R9C2 beam causes erlang R12B4 to segfault In-Reply-To: <48ECCC62.6060103@mobilearts.com> References: <48ECCC62.6060103@mobilearts.com> Message-ID: <6672d0160810100233yddd0955kfdbbc81b9156a3f9@mail.gmail.com> 2008/10/8 martin kjellin > Hello > > I've attached segfault.beam, compiled with R9C2, that when loaded into a > R12B4 system causes erlang to segfault when segfault:module_info() is > called. Calling module_info() on the same beam works in R11B5 (and R9C2). > Attached is also the source code (it's not a very complicated module...) but > it's not a straighforward map between the erl- and beam-file as there's a > parse transform involved. > Thanks! The problem is that the implementation of module_info/0,1 was implemented in a different way in R9C and earlier - using special instructions inserted by the loader. Those instructions no longer work reliably in R12B due to the new garbage-collection algorithm needed to support the constant pools. Since R12B can only load trivial R9C modules anyway, R12B-5 will refuse to load modules compiled by R9C or earlier. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Fri Oct 10 14:56:02 2008 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 10 Oct 2008 14:56:02 +0200 Subject: [erlang-bugs] Bug in ei_resolve.c/copy_hostent In-Reply-To: <8CD62780-89F2-435D-83CF-73453F1F34B7@kallisys.net> References: <8CD62780-89F2-435D-83CF-73453F1F34B7@kallisys.net> Message-ID: <48EF50E2.9060000@erix.ericsson.se> Hi Paul, Thank you for pointing this out. I have added this item to my ToDo-list and I have made a ticket of it. It is my intention to have this corrected in R12B-5. Regards, Bj?rn-Egil Erlang/OTP Paul Guyot wrote: > Hello, > > There is a very bad bug in ei_resolve.c's copy_hostent. The function > modifies the source hostent structure provided by gethost* functions, > and in particular h_aliases and h_addr_list, while it shouldn't. On > MacOS X 10.4, this yields to a heap corruption. One can arguably blame > MacOS X for this bug (which might be fixed on 10.5), but yet I believe > the fields should be copied for safety. The attached patch fixes the > problem and declares the source hostent const to enforce the check by > the compiler. > > Regards, > > Paul > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From bgustavsson@REDACTED Fri Oct 10 15:29:49 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 10 Oct 2008 15:29:49 +0200 Subject: [erlang-bugs] Compiler bug in sys_core_fold.erl In-Reply-To: <3dbc6d1c0810080644p420c7680kd3a64594ecafcdc@mail.gmail.com> References: <3dbc6d1c0810080644p420c7680kd3a64594ecafcdc@mail.gmail.com> Message-ID: <6672d0160810100629n5efce235s33d583249a8a18d8@mail.gmail.com> 2008/10/8 Robert Virding > I am running R12B-4 and have generated code with Lisp Flavoured Erlang. > > There is a bug in eval_element/3 which is called from fold_call/4 which > tries to safely evaluate calls at compile time. Eval_element tries to > evaluate calls to element/2. It also tries to check if the call is > guaranteed to fail in which case it replaces the original call with a call > to erlang:error(badarg). It is this check which is causing the bug as it is > so tuned to code generated by the vanilla erlang compiler that it does not > accept a nested call in the element. This is the bug. > > I would also argue that such a substitution has very little noticeable > effect as any evaluation of the arguments to element/2 have been broken out > and will already be evaluated before the code ever reaches the erlang:error > call. It, in fact, saves very little. > The optimization in itself may not be worthwhile (because the code being optimized is probably wrong), but there will also be a warning about a call to element/2 that will always fail. The warning could be useful. I have updated eval_element/2 to be more careful. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Mon Oct 13 06:31:09 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Mon, 13 Oct 2008 00:31:09 -0400 Subject: [erlang-bugs] [BUG] net_adm:world() crashes if node started without name Message-ID: <6c2563b20810122131w4715067ao1621a8c894934693@mail.gmail.com> This report pertains to R12B-4. If I call net_adm:world(), and a valid .erlang.hosts file exists in the current directory, and I did not start Erlang with a node name, it crashes with a case clause error. $ erl Erlang (BEAM) emulator version 5.6.4 [source] [64-bit] [smp:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.4 (abort with ^G) 1> net_adm:host_file(). [ender] 2> net_adm:world(). ** exception error: no case clause matching ignored in function net_adm:longshort/1 in call from net_adm:do_ping/3 in call from net_adm:collect_nodes/2 in call from net_adm:expand_hosts/2 The source of this is in net_adm:longshort/1, which follows: longshort(Host) -> case net_kernel:longnames() of false -> uptodot(Host); true -> Host end. net_kernel:longnames() returns 'ignored' if net_kernel is not running: %% If the net_kernel isn't running we ignore all requests to the %% kernel, thus basically accepting them :-) request(Req) -> case whereis(net_kernel) of P when is_pid(P) -> gen_server:call(net_kernel,Req,infinity); _ -> ignored end. longshort/1 should throw a meaningful (and documented) exception, e.g. longshort(Host) -> case net_kernel:longnames() of false -> uptodot(Host); true -> Host ignored -> throw({error, net_kernel_not_running}) end. Regards, Edwin Fine -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Mon Oct 13 06:39:19 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Mon, 13 Oct 2008 00:39:19 -0400 Subject: [erlang-bugs] [Doc/Code] Misspelled atom in pool:attach/1 Message-ID: <6c2563b20810122139i5c432808u8ba84845430ac0ee@mail.gmail.com> 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 :) Regards, Edwin Fine -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Tue Oct 14 10:40:04 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 14 Oct 2008 10:40:04 +0200 Subject: [erlang-bugs] R12B-4: http_chunk:encode(iolist()) produces invalid chunk In-Reply-To: References: Message-ID: <48F45AE4.4060107@erix.ericsson.se> Hi! Thank you for pointing this out it has been corrected for R1B-5. Regards Ingela Erlang/OTP - Ericsson Alexey Naidyonov wrote: > Hello; > > http_chunk:encode of inets application is defined as > > encode(Chunk) when is_list(Chunk)-> > > HEXSize = http_util:integer_to_hexlist(length(Chunk)), > > [HEXSize, ?CR, ?LF, Chunk, ?CR, ?LF]. > > > When mod_esi:deliver is called with iolist() containing binaries, > http_chink:encode produces an invalid chunk, e.g. > > mod_esi:deliver(SessionID, [<<"abcd">>, <<"abcd">>]). > > > yields: > > > 2 > > abcdabcd > > > I believe length/1 should be replaced with erlang:iolist_size/1, i.e. > > > encode(Chunk) when is_list(Chunk)-> > > HEXSize = http_util:integer_to_hexlist(erlang:iolist_size(Chunk)), > > [HEXSize, ?CR, ?LF, Chunk, ?CR, ?LF]. > > > this produces correct > > 8 > abcdabcd > > SY, > -- > Alexey Naidyonov > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From malcolm@REDACTED Tue Oct 14 13:22:12 2008 From: malcolm@REDACTED (Malcolm Dowse) Date: Tue, 14 Oct 2008 12:22:12 +0100 Subject: [erlang-bugs] Unclosed ports causing memory leak Message-ID: <707529930810140422v633ddedetf6386a8b6208a2b9@mail.gmail.com> Hello, We have been having some issues with Erlang ports not being closed properly. Instead, the ports remain in a strange "half closed" state. In this state, some aspects of the runtime system act as if the port exists (erlang:ports/1) but others act as if it does not (erlang:port_info/1, erlang:port_close/1). For example: 4> P. #Port<0.100> 5> is_port(P). true 6> node(P). nonode@REDACTED 7> erlang:port_info(P). undefined 8> erlang:port_close(P). ** exception error: bad argument in function port_close/1 called as port_close(#Port<0.100>) 9> exit(P, kill). true 10> lists:member(P, erlang:ports()). true On our busiest servers one of these ports is generated every few minutes. The result is that over months and months either the ERL_MAX_PORTS limit is hit, or the ERTS process slowly balloons consuming all system memory. And there appears to be no way to deallocate that memory without restarting Erlang. I've attached a short Erlang client & server which reproduces the problem. The server, upon receiving a connection, immediately sends the client 65Kb. When the client connects it immediately closes the socket before trying to receive anything. The outcome, almost 100% of the time, is that the erlang port on the server remains in this "half closed" state. test_server:start(4444) starts the server on port 4444, test_client:start(4444) starts the client (connecting to localhost), and port_utils:show_broken_loop() prints port information to stdout. This has been reproduced on: R12B-3, Ubuntu 6.06, i686 R11B-5, Ubuntu 7.04, x86_64 Enabling/disabling SMP support or kernelpoll had no effect, but reducing the 65Kb down to 30Kb seemed to make the problem go away, at least in the test case. Any help would be appreciated, Malcolm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_server.erl Type: application/octet-stream Size: 632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_client.erl Type: application/octet-stream Size: 203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: port_utils.erl Type: application/octet-stream Size: 814 bytes Desc: not available URL: From bgustavsson@REDACTED Thu Oct 16 10:12:46 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Thu, 16 Oct 2008 10:12:46 +0200 Subject: [erlang-bugs] [Doc/Code] Misspelled atom in pool:attach/1 In-Reply-To: <6c2563b20810122139i5c432808u8ba84845430ac0ee@mail.gmail.com> References: <6c2563b20810122139i5c432808u8ba84845430ac0ee@mail.gmail.com> Message-ID: <6672d0160810160112n1514f234u79e11058d61c854c@mail.gmail.com> 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. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Oct 16 15:32:27 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Thu, 16 Oct 2008 15:32:27 +0200 Subject: [erlang-bugs] EPMD protocol documentation In-Reply-To: <9b59d0270809120614l495a77b3ja0f5ac4057f280f0@mail.gmail.com> References: <9b59d0270809120614l495a77b3ja0f5ac4057f280f0@mail.gmail.com> Message-ID: <6672d0160810160632k58aa3249pc555b16f1ee2c0ea@mail.gmail.com> 2008/9/12 Michael Regen > Hi, > > I think there are a couple of problems with the documentation of the EPMD > protocol at http://erlang.org/doc/apps/erts/erl_dist_protocol.html#9.1 (in > R12B-3 and R12B-4) as well as erts/emulator/internal_doc/erl_ext_dist.txt > (in R12B-3): > Thanks! The document should need much more work, but for R12B-5 I have corrected the most glaring errors that you pointed out. > > * ALIVE2_REQ: > DistrvsnRange is 4 bytes, not 2. "Four bytes where MSB (2 bytes) = > Highestvsn and LSB (2 bytes) = Lowestvsn. For erts-4.6.x (OTP-R3)the vsn = 0 > For erts-4.7.x (OTP-R4) = ?????." > Corrected. > > * PORT2_RESP: > Elen is described as 2 byte field. But at least if during ALIVE2_REQ no > extra field was provided (as I think erts usually does) then PORT2_RESP just > returns Elen as one byte = 0. And erts does not seem to work correctly if we > send back a packet as specified. > The version number fields had the wrong size. Corrected. The Erlang system ignores the name field and everything following it. That Elen is shorter seems to be because of a bug in EPMD that has not been noticed (because it is harmless because the Erlang system doesn't care anyway). > > * NAMES_RESP: > In the documentation it looks like one packet should be sent back > containing the whole answer whereas in reality EPMDPortNo and each answer > are sent back in different packets. > TCP/IP is stream-oriented and has no packets, so the documentation is correct. > > * DUMP_RESP: > Same as for NAMES_RESP: different packets are expected. > Same answer as for NAMES_RESP. > > Furthermore the documentation speficies NodeInfo as expressed in Erlang: > io:format("active name ~s at port ~p, fd = ~p ~n", [NodeName, Port, > Fd]). > for registered nodes. Correct would be: > io:format("active name <~s> at port ~p, fd = ~p~n", [NodeName, Port, > Fd]). > Notice the <> characters! > The documentation should really document the binary format, so I see no point in changing this. > For unregistered nodes: > io:format("old/unused name ~s at port ~p, fd = ~p~n", [NodeName, Port, > Fd]). > io:format("old/unused name <~s>, port = ~p, fd = ~p ~n", [NodeName, Port, > Fd]). > Notice the <> characters as well as the last space before the new line! > > Furthermore it might be good to mention that all answers are followed by a > close of the socket except for ALIVE2_RESP. > I added a note about that to the description of PORT2_RESP. > Might also be good to mention that all integers are in big-endian format. > I have done that. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n39052@REDACTED Thu Oct 16 18:12:45 2008 From: n39052@REDACTED (Sergey A.) Date: Thu, 16 Oct 2008 09:12:45 -0700 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el Message-ID: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> Hello. The latest Emacs from CVS doesn't like the backuotes from erlang.el -- When I open any *.erl file in my emacs then the following warning message is shown: "Loading `erlang': old-style backquotes detected!" I know this bug is of little importance, but maybe there is an easy way to modify the erlang.el in such a way that all backquotes become correct. Unfortunately, I have not got working knowledge of Lisp and don't know what "backquotes" are :( I use erlang.el coming with Erlang R12B.3 and the latest emacs from CVS (v23.0.60.1). Thanks. -- Sergey From dmitriy.kargapolov@REDACTED Thu Oct 16 18:24:23 2008 From: dmitriy.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Thu, 16 Oct 2008 12:24:23 -0400 Subject: [erlang-bugs] erl_interface is not thread safe Message-ID: <63caf42f0810160924oa20741fw1f77a7383f6d0ef7@mail.gmail.com> Hi, I've found erl_interface / ei library to be not thread safe. This has been directly noticed in erl_format(), erl_match() behaviour, also I did manage to make my port program stable only when all erl_interface/ei calls from multiple threads were protected by mutex locks... For some reason this fact is not documented. Should be clearly mentioned in the documentation until fixed. My OTP version R11B-5, but same problem I'm sure still exists in R12B-* erl_interface compiled for thread support: lib/erl_interface-3.5.5.3/src/eidefs.mk: ... # Have the ei and erl_interface libs been compiled for threads? EI_THREADS=true # Threads flags THR_DEFS=-D_REENTRANT -D_THREAD_SAFE -DPOSIX_THREADS -isystem /usr/include/nptl # Threads libs THR_LIBS=-lpthread ... Thanks. From dmitriy.kargapolov@REDACTED Thu Oct 16 18:19:12 2008 From: dmitriy.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Thu, 16 Oct 2008 12:19:12 -0400 Subject: [erlang-bugs] erl_interface is not thread safe Message-ID: <48F76980.5070104@gmail.com> Hi, I've found erl_interface / ei library to be not thread safe. This has been directly noticed in erl_format(), erl_match() behaviour, also I did manage to make my port program stable only when all erl_interface/ei calls from multiple threads were protected by mutex locks... For some reason this fact is not documented. Should be clearly mentioned in the documentation until fixed. My OTP version R11B-5, but same problem I'm sure still exists in R12B-* erl_interface compiled for thread support: lib/erl_interface-3.5.5.3/src/eidefs.mk: ... # Have the ei and erl_interface libs been compiled for threads? EI_THREADS=true # Threads flags THR_DEFS=-D_REENTRANT -D_THREAD_SAFE -DPOSIX_THREADS -isystem /usr/include/nptl # Threads libs THR_LIBS=-lpthread ... Thanks. From Balint.Reczey@REDACTED Thu Oct 16 19:27:51 2008 From: Balint.Reczey@REDACTED (Balint Reczey) Date: Thu, 16 Oct 2008 19:27:51 +0200 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el In-Reply-To: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> References: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> Message-ID: <1224178071.19441.3.camel@localhost> Hi, I tried to submit the patch to erlang-bugs several times, but somehow it did not get through the spam filter/listadmin. :-( You can find the patch here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494823 Regards, Balint 2008. 10. 16, cs?t?rt?k keltez?ssel 09.12-kor Sergey A. ezt ?rta: > Hello. > > The latest Emacs from CVS doesn't like the backuotes from erlang.el > -- > > When I open any *.erl file in my emacs then the following warning > message is shown: > > "Loading `erlang': old-style backquotes detected!" > > I know this bug is of little importance, but maybe there is an easy > way to modify the erlang.el in such a way that all backquotes become > correct. > > Unfortunately, I have not got working knowledge of Lisp and don't know > what "backquotes" are :( > > I use erlang.el coming with Erlang R12B.3 and the latest emacs from > CVS (v23.0.60.1). > > Thanks. > > -- > Sergey > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From rvirding@REDACTED Thu Oct 16 22:01:29 2008 From: rvirding@REDACTED (Robert Virding) Date: Thu, 16 Oct 2008 22:01:29 +0200 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el In-Reply-To: <1224178071.19441.3.camel@localhost> References: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> <1224178071.19441.3.camel@localhost> Message-ID: <3dbc6d1c0810161301l44a198f5t534fcb483d4521de@mail.gmail.com> This fix just expands the backquote/unquote forms by hand. I have here a better fix (I think) which uses the "new" backquote style. This has been around a long while, and is compatible with Common Lisp backquote. We'll see if it makes it through, I have also included the file. Compiling erlang.el with Emacs 22.1 also gives some obsolete functions, but they seem to be for this version of Emacs. Robert *** erlang.el.orig Thu Oct 16 21:33:08 2008 --- erlang.el Thu Oct 16 21:36:45 2008 *************** *** 1891,1895 **** "(unless CONDITION BODY...): If CONDITION is false, do BODY, else return nil." ! (` (if (, condition) ! nil ! (,@ body))))) --- 1891,1895 ---- "(unless CONDITION BODY...): If CONDITION is false, do BODY, else return nil." ! `(if ,condition ! nil ! ,@REDACTED))) *************** *** 1898,1902 **** "(when CONDITION BODY...): If CONDITION is true, do BODY, else return nil." ! (` (if (, condition) ! (progn (,@ body)) ! nil)))) --- 1898,1902 ---- "(when CONDITION BODY...): If CONDITION is true, do BODY, else return nil." ! `(if ,condition ! (progn ,@REDACTED) ! nil))) *************** *** 1905,1907 **** "Return the character in the current buffer just before POS." ! (` (char-after (1- (or (, pos) (point))))))) --- 1905,1907 ---- "Return the character in the current buffer just before POS." ! `(char-after (1- (or ,pos (point)))))) 2008/10/16 Balint Reczey > Hi, > I tried to submit the patch to erlang-bugs several times, but somehow it > did not get through the spam filter/listadmin. :-( > > You can find the patch here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494823 > > Regards, > Balint > > 2008. 10. 16, cs?t?rt?k keltez?ssel 09.12-kor Sergey A. ezt ?rta: > > Hello. > > > > The latest Emacs from CVS doesn't like the backuotes from erlang.el > > -- > > > > When I open any *.erl file in my emacs then the following warning > > message is shown: > > > > "Loading `erlang': old-style backquotes detected!" > > > > I know this bug is of little importance, but maybe there is an easy > > way to modify the erlang.el in such a way that all backquotes become > > correct. > > > > Unfortunately, I have not got working knowledge of Lisp and don't know > > what "backquotes" are :( > > > > I use erlang.el coming with Erlang R12B.3 and the latest emacs from > > CVS (v23.0.60.1). > > > > Thanks. > > > > -- > > Sergey > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang.el-diff Type: application/octet-stream Size: 1084 bytes Desc: not available URL: From tty@REDACTED Thu Oct 16 23:51:13 2008 From: tty@REDACTED (tty@REDACTED) Date: Thu, 16 Oct 2008 17:51:13 -0400 Subject: [erlang-bugs] Dialyzer finds unexported / missing functions in re.erl Message-ID: The following are warnings from a dialyzer run: re.erl:64: Call to missing or unexported function re:run/3 re.erl:401: Call to missing or unexported function re:run/3 Using Erlang (BEAM) emulator version 5.6.4 [source] [smp:2] [async-threads:0] [kernel-poll:false] Thanks, tty From bgustavsson@REDACTED Fri Oct 17 09:24:49 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 17 Oct 2008 09:24:49 +0200 Subject: [erlang-bugs] Dialyzer finds unexported / missing functions in re.erl In-Reply-To: References: Message-ID: <6672d0160810170024yba28393o78423badcd519e54@mail.gmail.com> On Thu, Oct 16, 2008 at 11:51 PM, wrote: > The following are warnings from a dialyzer run: > > re.erl:64: Call to missing or unexported function re:run/3 > re.erl:401: Call to missing or unexported function re:run/3 > > It will be correct in R12B-5. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Oct 17 09:46:07 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 17 Oct 2008 09:46:07 +0200 Subject: [erlang-bugs] Unclosed ports causing memory leak In-Reply-To: <707529930810140422v633ddedetf6386a8b6208a2b9@mail.gmail.com> References: <707529930810140422v633ddedetf6386a8b6208a2b9@mail.gmail.com> Message-ID: <6672d0160810170046t1cad428cnc75dc38f35ab8722@mail.gmail.com> 2008/10/14 Malcolm Dowse > Hello, > > We have been having some issues with Erlang ports not being closed > properly. Instead, the ports remain in a strange "half closed" state. In > this state, some aspects of the runtime system act as if the port exists > (erlang:ports/1) but others act as if it does not (erlang:port_info/1, > erlang:port_close/1). For example: > Thanks! I was able to reproduce the problem. We will investigate. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Oct 17 10:15:23 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 17 Oct 2008 10:15:23 +0200 Subject: [erlang-bugs] erts_sys_ddll_call_init() anomaly In-Reply-To: <27849374.1218655921116.JavaMail.root@webmail2.groni1> References: <27849374.1218655921116.JavaMail.root@webmail2.groni1> Message-ID: <6672d0160810170115t65c017bdw6398a006fe5a0b5e@mail.gmail.com> On Wed, Aug 13, 2008 at 9:32 PM, wrote: > Hi, > > the win32 function > > void *erts_sys_ddll_call_init(void *function) { > void *(*initfn)(TWinDynDriverCallbacks *) = function; > return (*initfn)(&wddc); > } > > seems to be incorrect, it should have been: > On Windows, the DRIVER_INIT macro expands to a wrapper function which takes aTWinDynDriverCallbacks * argument (see erl_win_dyn_driver.h). Therefore the current code is correct. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From pguyot@REDACTED Fri Oct 17 10:41:59 2008 From: pguyot@REDACTED (Paul Guyot) Date: Fri, 17 Oct 2008 10:41:59 +0200 Subject: [erlang-bugs] ei_reg_send is destructive to the erlang node's pid Message-ID: <7BD2E391-F28C-495A-BCCA-D652CA8F68D9@kallisys.net> Hello, I noticed that ei_reg_send and ei_reg_send_tmo are destructive of the node's pid: erlang_pid *self = ei_self(ec); self->num = fd; (and so is ei_rpc_to) The same problem can be found in the code snipet in ei_send_reg_encoded's documentation: > A suitable erlang_pid can be constructed from the ei_cnode > structure by the following example code: > > ei_cnode ec; > erlang_pid *self; > int fd; /* the connection fd */ > ... > self = ei_self(&ec); > self->num = fd; This means that two calls to ei_self won't return the same value, and this might be a problem for pids sent to a node and then received back and compared, especially if several fds are passed to ei_reg_send to send messages to several distant nodes (and therefore several connection fds). I am actually confused by the comment. Why such a pid is suitable and the original node's pid () unsuitable? Paul From bgustavsson@REDACTED Fri Oct 17 10:54:00 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 17 Oct 2008 10:54:00 +0200 Subject: [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: <20080914014111.GA7026@k2r.org> References: <20080914014111.GA7026@k2r.org> Message-ID: <6672d0160810170154h4f74cc8do7a79828363112729@mail.gmail.com> On Sun, Sep 14, 2008 at 3:41 AM, Kenji Rikitake wrote: > A patch to correct erlang:universaltime_to_localtime/1 > for FreeBSD running leap-second-enabled timezone > by Kenji Rikitake > 14-SEP-2008 > > * Summary > > This patch fixes the time calculation problem of > FreeBSD 6.x and 7.x, which has the internal leap-second > correction enabled. > This patch is tested with Erlang/OTP R12B-4 source distribution. > We will probably add the patch to R12B-5 with slight modifications. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Balint.Reczey@REDACTED Fri Oct 17 12:38:14 2008 From: Balint.Reczey@REDACTED (Balint Reczey) Date: Fri, 17 Oct 2008 12:38:14 +0200 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el In-Reply-To: <3dbc6d1c0810161301l44a198f5t534fcb483d4521de@mail.gmail.com> References: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> <1224178071.19441.3.camel@localhost> <3dbc6d1c0810161301l44a198f5t534fcb483d4521de@mail.gmail.com> Message-ID: <1224239894.17004.13.camel@localhost> Hi, My original intention was the same, but the new style backqoutes was introduced in Emacs 19.29, ( http://www.gnu.org/software/emacs/elisp/html_node/Backquote.html ) and erlang.el contains compatibility workarounds for Emacs 18: ;;; Avoid errors while compiling this file. ;; `eval-when-compile' is not defined in Emacs 18. We define it as a ;; no-op. (or (fboundp 'eval-when-compile) (defmacro eval-when-compile (&rest rest) nil)) Replacing the old style backquotes whith new style ones would break compatibility with Emacs 18, so i just expanded them. Regards, Balint 2008. 10. 16, cs?t?rt?k keltez?ssel 22.01-kor Robert Virding ezt ?rta: > This fix just expands the backquote/unquote forms by hand. I have here > a better fix (I think) which uses the "new" backquote style. This has > been around a long while, and is compatible with Common Lisp > backquote. We'll see if it makes it through, I have also included the > file. > > Compiling erlang.el with Emacs 22.1 also gives some obsolete > functions, but they seem to be for this version of Emacs. > > Robert > > *** erlang.el.orig Thu Oct 16 21:33:08 2008 > --- erlang.el Thu Oct 16 21:36:45 2008 > *************** > *** 1891,1895 **** > "(unless CONDITION BODY...): If CONDITION is false, do BODY, > else return nil." > ! (` (if (, condition) > ! nil > ! (,@ body))))) > > --- 1891,1895 ---- > "(unless CONDITION BODY...): If CONDITION is false, do BODY, > else return nil." > ! `(if ,condition > ! nil > ! ,@REDACTED))) > > *************** > *** 1898,1902 **** > "(when CONDITION BODY...): If CONDITION is true, do BODY, else > return nil." > ! (` (if (, condition) > ! (progn (,@ body)) > ! nil)))) > > --- 1898,1902 ---- > "(when CONDITION BODY...): If CONDITION is true, do BODY, else > return nil." > ! `(if ,condition > ! (progn ,@REDACTED) > ! nil))) > > *************** > *** 1905,1907 **** > "Return the character in the current buffer just before POS." > ! (` (char-after (1- (or (, pos) (point))))))) > > --- 1905,1907 ---- > "Return the character in the current buffer just before POS." > ! `(char-after (1- (or ,pos (point)))))) > > > 2008/10/16 Balint Reczey > Hi, > I tried to submit the patch to erlang-bugs several times, but > somehow it > did not get through the spam filter/listadmin. :-( > > You can find the patch here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494823 > > Regards, > Balint > > 2008. 10. 16, cs?t?rt?k keltez?ssel 09.12-kor Sergey A. ezt > ?rta: > > > Hello. > > > > The latest Emacs from CVS doesn't like the backuotes from > erlang.el > > -- > > > > When I open any *.erl file in my emacs then the following > warning > > message is shown: > > > > "Loading `erlang': old-style backquotes detected!" > > > > I know this bug is of little importance, but maybe there is > an easy > > way to modify the erlang.el in such a way that all > backquotes become > > correct. > > > > Unfortunately, I have not got working knowledge of Lisp and > don't know > > what "backquotes" are :( > > > > I use erlang.el coming with Erlang R12B.3 and the latest > emacs from > > CVS (v23.0.60.1). > > > > Thanks. > > > > -- > > Sergey > > _______________________________________________ > > 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 rvirding@REDACTED Fri Oct 17 13:08:43 2008 From: rvirding@REDACTED (Robert Virding) Date: Fri, 17 Oct 2008 13:08:43 +0200 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el In-Reply-To: <1224239894.17004.13.camel@localhost> References: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> <1224178071.19441.3.camel@localhost> <3dbc6d1c0810161301l44a198f5t534fcb483d4521de@mail.gmail.com> <1224239894.17004.13.camel@localhost> Message-ID: <3dbc6d1c0810170408k62505886j7cc53595ce9fac48@mail.gmail.com> I reasoned that *sometime* people have to upgrade emacs and we can't support to many old versions, after all Emacs 19.29 is not new. :-) Of course there is no practical difference in doing the expansions "by hand" or leaving it to emacs as the macros are so simple. Robert 2008/10/17 Balint Reczey > Hi, > My original intention was the same, but the new style backqoutes was > introduced in Emacs 19.29, > ( http://www.gnu.org/software/emacs/elisp/html_node/Backquote.html ) > and erlang.el contains compatibility workarounds for Emacs 18: > > ;;; Avoid errors while compiling this file. > > ;; `eval-when-compile' is not defined in Emacs 18. We define it as a > ;; no-op. > (or (fboundp 'eval-when-compile) > (defmacro eval-when-compile (&rest rest) nil)) > > Replacing the old style backquotes whith new style ones would break > compatibility with Emacs 18, so i just expanded them. > > Regards, > Balint > > > 2008. 10. 16, cs?t?rt?k keltez?ssel 22.01-kor Robert Virding ezt ?rta: > > This fix just expands the backquote/unquote forms by hand. I have here > > a better fix (I think) which uses the "new" backquote style. This has > > been around a long while, and is compatible with Common Lisp > > backquote. We'll see if it makes it through, I have also included the > > file. > > > > Compiling erlang.el with Emacs 22.1 also gives some obsolete > > functions, but they seem to be for this version of Emacs. > > > > Robert > > > > *** erlang.el.orig Thu Oct 16 21:33:08 2008 > > --- erlang.el Thu Oct 16 21:36:45 2008 > > *************** > > *** 1891,1895 **** > > "(unless CONDITION BODY...): If CONDITION is false, do BODY, > > else return nil." > > ! (` (if (, condition) > > ! nil > > ! (,@ body))))) > > > > --- 1891,1895 ---- > > "(unless CONDITION BODY...): If CONDITION is false, do BODY, > > else return nil." > > ! `(if ,condition > > ! nil > > ! ,@REDACTED))) > > > > *************** > > *** 1898,1902 **** > > "(when CONDITION BODY...): If CONDITION is true, do BODY, else > > return nil." > > ! (` (if (, condition) > > ! (progn (,@ body)) > > ! nil)))) > > > > --- 1898,1902 ---- > > "(when CONDITION BODY...): If CONDITION is true, do BODY, else > > return nil." > > ! `(if ,condition > > ! (progn ,@REDACTED) > > ! nil))) > > > > *************** > > *** 1905,1907 **** > > "Return the character in the current buffer just before POS." > > ! (` (char-after (1- (or (, pos) (point))))))) > > > > --- 1905,1907 ---- > > "Return the character in the current buffer just before POS." > > ! `(char-after (1- (or ,pos (point)))))) > > > > > > 2008/10/16 Balint Reczey > > Hi, > > I tried to submit the patch to erlang-bugs several times, but > > somehow it > > did not get through the spam filter/listadmin. :-( > > > > You can find the patch here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494823 > > > > Regards, > > Balint > > > > 2008. 10. 16, cs?t?rt?k keltez?ssel 09.12-kor Sergey A. ezt > > ?rta: > > > > > Hello. > > > > > > The latest Emacs from CVS doesn't like the backuotes from > > erlang.el > > > -- > > > > > > When I open any *.erl file in my emacs then the following > > warning > > > message is shown: > > > > > > "Loading `erlang': old-style backquotes detected!" > > > > > > I know this bug is of little importance, but maybe there is > > an easy > > > way to modify the erlang.el in such a way that all > > backquotes become > > > correct. > > > > > > Unfortunately, I have not got working knowledge of Lisp and > > don't know > > > what "backquotes" are :( > > > > > > I use erlang.el coming with Erlang R12B.3 and the latest > > emacs from > > > CVS (v23.0.60.1). > > > > > > Thanks. > > > > > > -- > > > Sergey > > > _______________________________________________ > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n39052@REDACTED Fri Oct 17 17:41:46 2008 From: n39052@REDACTED (Sergey A.) Date: Fri, 17 Oct 2008 08:41:46 -0700 Subject: [erlang-bugs] The latest Emacs from CVS doesn't like the backuotes from erlang.el In-Reply-To: <3dbc6d1c0810170408k62505886j7cc53595ce9fac48@mail.gmail.com> References: <3bff71aa0810160912o77984a6fp3ddcddf9da498980@mail.gmail.com> <1224178071.19441.3.camel@localhost> <3dbc6d1c0810161301l44a198f5t534fcb483d4521de@mail.gmail.com> <1224239894.17004.13.camel@localhost> <3dbc6d1c0810170408k62505886j7cc53595ce9fac48@mail.gmail.com> Message-ID: <3bff71aa0810170841m683ec37duc143456a633893e1@mail.gmail.com> Hello. Thanks for your patches! I hope one of these will be included in the next release by maintainers. I think there is no need to maintain emacs 18, which is too old. And because the following is also of little importance I didn't make this into new bug report: I see that some templates (e.g. for supervisor) have the definition of ?SERVER macros, while some (gen_server, gen_event) don't. It looks a bit puzzling. Maybe it won't be so hard for that man, who will update erlang.el, to fix this too =) -- Sergey. From n.decker@REDACTED Sun Oct 19 17:11:27 2008 From: n.decker@REDACTED (Decker, Nils) Date: Sun, 19 Oct 2008 17:11:27 +0200 Subject: [erlang-bugs] Documentation for snmpm: def_user mod Message-ID: Hello, In the snmp application documentation are references to the snmp manager option "def_user_module" this should be "def_user_mod" as implemented in snmpm_config.erl Regards Nils Decker Nils Decker Software-Ingenieur Projektierung Studio Hamburg Media Consult International (MCI) GmbH Jenfelder Allee 80 | A8 2. OG / Raum 238 22039 Hamburg Telefon: +49 (0)40 6688-3437 n.decker@REDACTED www.mci-broadcast.com www.mci-systems.de www.mci-products.de www.mci-werkstaetten.de ................................................................................. Gesch?ftsf?hrung: Ralf Schimmel Goetz Hoefer Prokuristen: J?rn Denneborg J?rg Pankow Amtsgericht Hamburg: HRB 70454 From bgustavsson@REDACTED Tue Oct 21 16:24:05 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Tue, 21 Oct 2008 16:24:05 +0200 Subject: [erlang-bugs] [BUG] net_adm:world() crashes if node started without name In-Reply-To: <6c2563b20810122131w4715067ao1621a8c894934693@mail.gmail.com> References: <6c2563b20810122131w4715067ao1621a8c894934693@mail.gmail.com> Message-ID: <6672d0160810210724u20940174r5aa4dfbc9f6913a4@mail.gmail.com> 2008/10/13 Edwin Fine > This report pertains to R12B-4. > > If I call net_adm:world(), and a valid .erlang.hosts file exists in the > current directory, and I did not start Erlang with a node name, it crashes > with a case clause error. > Thanks for the bug report. I have changed net_adm:world/0,1 to return an empty list if the Erlang emulator is not started with a node name. This change will be included in R12B-5. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.newcombe@REDACTED Wed Oct 22 22:21:57 2008 From: chris.newcombe@REDACTED (Chris Newcombe) Date: Wed, 22 Oct 2008 13:21:57 -0700 Subject: [erlang-bugs] Regression in erlang:system_monitor long_gc ? Message-ID: <781dd98c0810221321j4422bdebg5454f7eaeb4428af@mail.gmail.com> Hi OTP team, I'm using R12B-2 (erts 5.6.2). I'm using erlang:system_monitor to detect long_gc times. I very often see long_gc times mis-reported as >4,200 seconds, e.g. system_monitor: {1224,701965,21022}: system_monitor: killing <0.149.0> as received {monitor,<0.149.0>,long_gc,[{timeout,4295002},{old_heap_block_size,0},{heap_block_size,6419485},{mbuf_size,0},{stack_size,32},{old_heap_size,0},{heap_size,2000144}]} I searched the mailing-list archives, and someone else reported this back in July http://www.erlang.org/pipermail/erlang-questions/2008-July/036388.html but I couldn't find any response. I found an entry in very old release notes an apparently identical bug was fixed in R9. http://www.erlang.org/documentation/doc-5.5/erts-5.5/doc/html/notes_history.html 1.9 ERTS 5.3.3 When using erlang:system_monitor(Pid,{long_gc,Time}), and the GC time exceeded 1 second, it sometimes erroneously showed up as about 4300 seconds. This bug has now been corrected. Own Id: OTP-4903 Aux Id: seq8379 Please could this be fixed? system_monitor is extremely useful in production systems :) many thanks, Chris Newcombe From sverker@REDACTED Thu Oct 23 11:54:13 2008 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 23 Oct 2008 11:54:13 +0200 Subject: [erlang-bugs] Unclosed ports causing memory leak In-Reply-To: <6672d0160810170046t1cad428cnc75dc38f35ab8722@mail.gmail.com> References: <707529930810140422v633ddedetf6386a8b6208a2b9@mail.gmail.com> <6672d0160810170046t1cad428cnc75dc38f35ab8722@mail.gmail.com> Message-ID: <490049C5.9050600@erix.ericsson.se> Bjorn Gustavsson wrote: > 2008/10/14 Malcolm Dowse > > >> Hello, >> >> We have been having some issues with Erlang ports not being closed >> properly. Instead, the ports remain in a strange "half closed" state. In >> this state, some aspects of the runtime system act as if the port exists >> (erlang:ports/1) but others act as if it does not (erlang:port_info/1, >> erlang:port_close/1). For example: >> > > Thanks! > > I was able to reproduce the problem. We will investigate. > > /Bjorn > Bug found in inet_drv.c. The output queue was not cleared causing the port to linger without being able to close properly. Fix done and scheduled for R12B-5. /Sverker, Erlang/OTP From malcolm@REDACTED Thu Oct 23 12:01:48 2008 From: malcolm@REDACTED (Malcolm Dowse) Date: Thu, 23 Oct 2008 11:01:48 +0100 Subject: [erlang-bugs] Unclosed ports causing memory leak In-Reply-To: <490049C5.9050600@erix.ericsson.se> References: <707529930810140422v633ddedetf6386a8b6208a2b9@mail.gmail.com> <6672d0160810170046t1cad428cnc75dc38f35ab8722@mail.gmail.com> <490049C5.9050600@erix.ericsson.se> Message-ID: <707529930810230301m151851eep687032c86c69b39@mail.gmail.com> > > >> > > Bug found in inet_drv.c. The output queue was not cleared causing the port > to linger without being able to close properly. > Fix done and scheduled for R12B-5. That's great - thank you very much :) Malcolm > > > /Sverker, Erlang/OTP > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wglozer@REDACTED Thu Oct 23 19:20:42 2008 From: wglozer@REDACTED (Will) Date: Thu, 23 Oct 2008 10:20:42 -0700 Subject: [erlang-bugs] base64:decode/1 fails on some inputs Message-ID: Hello, I've noticed that base64:decode/1 will fail on some inputs, although I don't know why or what triggers it. Here is a string that does however: "+tpm7jXi9ymsOflkw7ImYaa+oJrAC/E2fueZ4QYP+\\hfuAQ0MFPLSSqDMYO/ZohCVWJOh/KwKE2F9Ea5QZJGQ==" I've also attached a test case. Thanks! Will -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: base64_fail.erl Type: application/octet-stream Size: 298 bytes Desc: not available URL: From mog-lists@REDACTED Thu Oct 23 19:35:20 2008 From: mog-lists@REDACTED (mog) Date: Thu, 23 Oct 2008 12:35:20 -0500 Subject: [erlang-bugs] base64:decode/1 fails on some inputs In-Reply-To: References: Message-ID: <20081023173520.GA18062@metalman.digium.internal> On Thu, Oct 23, 2008 at 10:20:42AM -0700, Will wrote: > Hello, > > I've noticed that base64:decode/1 will fail on some inputs, although I don't > know why or what triggers it. > Here is a string that does however: > > "+tpm7jXi9ymsOflkw7ImYaa+oJrAC/E2fueZ4QYP+\\hfuAQ0MFPLSSqDMYO/ZohCVWJOh/KwKE2F9Ea5QZJGQ==" The string provided is not valid base64 encoded data, base64 is doing the right thing in crashing on it Mog -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From bgustavsson@REDACTED Fri Oct 24 09:45:20 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 24 Oct 2008 09:45:20 +0200 Subject: [erlang-bugs] Regression in erlang:system_monitor long_gc ? In-Reply-To: <781dd98c0810221321j4422bdebg5454f7eaeb4428af@mail.gmail.com> References: <781dd98c0810221321j4422bdebg5454f7eaeb4428af@mail.gmail.com> Message-ID: <6672d0160810240045j40bfb12l226e1e131bfce632@mail.gmail.com> On Wed, Oct 22, 2008 at 10:21 PM, Chris Newcombe wrote: > Hi OTP team, > > I'm using R12B-2 (erts 5.6.2). I'm using erlang:system_monitor to > detect long_gc times. > > I very often see long_gc times mis-reported as >4,200 seconds, e.g. > > system_monitor: {1224,701965,21022}: system_monitor: killing > <0.149.0> as received > > {monitor,<0.149.0>,long_gc,[{timeout,4295002},{old_heap_block_size,0},{heap_block_size,6419485},{mbuf_size,0},{stack_size,32},{old_heap_size,0},{heap_size,2000144}]} > Thanks! Unfortunately, the previous bug fix was not included in the garbage collector for R12B. We have now written a test case for our daily builds and fixed the bug. The correction will be included in R12B-5. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Oct 24 10:09:34 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 24 Oct 2008 10:09:34 +0200 Subject: [erlang-bugs] Erlang emulator crash, gen_tcp related (probably only under Windows) In-Reply-To: <9b59d0270809130930g260f8ca8wc19f4d20a5802655@mail.gmail.com> References: <9b59d0270809130930g260f8ca8wc19f4d20a5802655@mail.gmail.com> Message-ID: <6672d0160810240109w25451e3bwd8673a62f0b82107@mail.gmail.com> 2008/9/13 Michael Regen > Hi, > > I run into Erlang emulator crashes when I do basic gen_tcp operations. My > code crashes with the message: > Crash dump was written to: erl_crash.dump > Inconsistent, why isnt io reported? > Abnormal termination > without any significant error message before. > Thanks! We have investigated and found the bug. The correction will be included in R12B-5. /Bjorn > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliliang@REDACTED Fri Oct 24 22:56:31 2008 From: eliliang@REDACTED (Eli Liang) Date: Fri, 24 Oct 2008 13:56:31 -0700 (PDT) Subject: [erlang-bugs] minor inconsistency in the startup directory location for werl.exe Message-ID: <616619.98092.qm@web30408.mail.mud.yahoo.com> Playing with the ".erlang" file under Windows (Vista), I noticed a minor inconsistency I didn't find documented anywhere. erl.exe and werl.exe are both started by default in "{erlang-root}\bin" when clicking on their program icons in Windows Explorer. However, when running the version of the "Erlang" which is under the Windows Start menu, it is a shortcut which is set by default to start in "{erlang-root}\usr" instead. It's unclear why the Erlang launched via the Windows Start menu should have its default startup directory set differently during the?Erlang?Windows installation?than when launching werl.exe by clicking on the program icon.? (This might only be interesting if you have a different .erlang in "{erlang-root}\bin" vs. "{erlang-root}\usr".) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruzin82@REDACTED Mon Oct 27 10:17:25 2008 From: ruzin82@REDACTED (Yongbeom Pak) Date: Mon, 27 Oct 2008 11:17:25 +0200 Subject: [erlang-bugs] memory useage bug Message-ID: <72e228670810270217s866b612pd93297ae5588e4e8@mail.gmail.com> Hello, I think there is some bugs on handling memory. I was doing out-of-memory testing on erlang. I was thinking that when out of memory happens it should kill some processes and run again those processes with supervisor instead of killing the shell but in the test it kills erl shell. I have tested with R11B-5 and R12B-4 on 32bit xp and 32bit, 64bit linux. Another thing is that when erlang start to use swap memory erl shell dies before it is using most of swap memory. Usually, it dies when it uses more than 1/3 - 1/2 of swap memory. First test case was selecting huge amount of data from mnesia using guard. Second test case was recursive list that duplicates the data without releasing data infinitely. Addition, what is the reason that R12B-4 consumes more memory than R11B-5? It almost consumes 2times more than R11B-5. Best Regards, Yongbeom Pak -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji.rikitake@REDACTED Fri Oct 31 00:46:19 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 31 Oct 2008 08:46:19 +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: <20080918021602.GA6530@k2r.org> References: <20080914014111.GA7026@k2r.org> <20080914031210.GA9162@k2r.org> <20080914052418.GA10612@k2r.org> <20080918021602.GA6530@k2r.org> Message-ID: <20081030234619.GA31298@k2r.org> The previous patch I posted on September 18, 2008 had a bug in the new BIF erlang:now_utc/0 which I added. This patch is a revised one for R12B4, now also tested on a non-leap-second system (Ubuntu 8.04 LTS Desktop). Kenji Rikitake -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_now_utc.patch Type: text/x-diff Size: 6770 bytes Desc: not available URL: From pguyot@REDACTED Fri Oct 31 18:52:15 2008 From: pguyot@REDACTED (Paul Guyot) Date: Fri, 31 Oct 2008 18:52:15 +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: References: Message-ID: <9B23E0C2-40EB-4ED5-A8F4-578A332BD4D3@kallisys.net> Le 31 oct. 08 ? 12:00, erlang-bugs-request@REDACTED a ?crit : > Date: Fri, 31 Oct 2008 08:46:19 +0900 > From: Kenji Rikitake > 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 > To: erlang-patches@REDACTED, erlang-bugs@REDACTED > Message-ID: <20081030234619.GA31298@REDACTED> > Content-Type: text/plain; charset="us-ascii" > > The previous patch I posted on September 18, 2008 had a bug in the new > BIF erlang:now_utc/0 which I added. This patch is a revised one for > R12B4, now also tested on a non-leap-second system (Ubuntu 8.04 LTS > Desktop). 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